[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Jan Beulich <JBeulich@xxxxxxxxxx>
  • From: Haitao Shan <maillists.shan@xxxxxxxxx>
  • Date: Fri, 11 Feb 2011 14:00:42 +0800
  • Cc: Yunhong Jiang <yunhong.jiang@xxxxxxxxx>, Keir Fraser <keir@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 10 Feb 2011 22:01:48 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=f83U1NQ0f0ebiKLvri9h5C4+v+uGYyU40P/hHBWK4FJY8T5p5yFGndcG+ELqJaPECD o15NHvvBTl2kcMYkK9/VUKhlP45mCP51xfAGniA1QAK7RHnjkDvnLI43mMdt8zr67tnS wk4vl/hT9qaR1Z7y7G3LmtveK0uJHvecjtxC0=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

> 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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.