[Xen-devel] Re: Comments on Xen bug 1732

[Haitao Shan <maillists.shan@xxxxxxxxx>]

> Another question: What would the purpose of your patch be? I mean, you are
> trying to remove MSIX table access right for DomUs, or you are also aiming
> at removing msi->table_base from the trust chain so that guests cannot pass
> arbitrary address down to Xen?

No, passing down the address from Dom0 is fine, but given that
we have to use an alternative approach (reading config space) to
determine the PBA address, it seemed rather reasonable (proven
by what we now see) to verify the value as passed up by Dom0
matches what we would calculate on our own (to provide a hint
at whether the PBA address determination needs any fixing,
which we now know it does).

It would be nice that the value passed by dom0 could be verified, I agree. But the reality is that it is quite complex to calculate this value if the function is a VF.

Per my investigation, the process should be:

1. Determine the corresponding PF of an given VF.

    This is already in Xen. But such kind of information is passed to Xen by dom0. Again, do we trust dom0 for this?

2. Look through SRIOV capability in PF to find the actual MEM Bar for this VF.

    This would require Xen access extended PCI configuration space. The mechanism is not available for 32bit Xen. Is this justified to add this to 32bit Xen? I see this as something overkilling. At minimum, I don't see any value of adding so many code to Xen 4.1 instead of removing the unnecessary checking and warning (or necessary but not implementation friendly).

Shan Haitao 

 

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel