WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

>>> On 11.02.11 at 07:00, Haitao Shan <maillists.shan@xxxxxxxxx> wrote:
>> 
>> > 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?

I think trusting Dom0 is the right thing to do - it's being trusted in
other places too.

> 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).

I think we can leave aside 32-bit Xen, as it'll go away soon anyway.
There's other code requiring extended cfg space accesses, so
no reason not to add this instance.

As to "unnecessary checking and warning" I can only repeat that
we know by now that the checking and warning *is* appropriate,
as we currently don't calculate the PBA address correctly. Once
we're sure this is done right for all cases, the warning certainly
can go away (there's no question of checking here, as the value
doesn't get passed from Dom0).

Jan


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

<Prev in Thread] Current Thread [Next in Thread>