RE: [PATCH, RFC, resend] Re: granting access to MSI-X table and pending bit array

["Jan Beulich" <JBeulich@novell.com>]

>>> On 27.08.10 at 03:48, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote:
>>From: Jan Beulich [mailto:JBeulich@novell.com] 
>>Because pciback does the actual enabling on behalf of the guest.
>>Any resource adjustments done when memory decoding gets
>>enabled won't be known at the time the guest starts.
> 
> Does this resource adjustment work in current pciback/hypervisor? At least 

pciback and hypervisor on its own presumably have no problem, but
the tools won't cope with it (as they read the resource settings when
assigning the device, before it gets enabled). I never liked that solution
anyway, as it basically takes away control from the hypervisor (which
could monitor config space changes if there wasn't the problem of
how to handle MMCONFIG accesses). Instead of passing resource
ownership information to Xen, all the tools should do is pass PCI
device ownership information. Any dynamic change to the device's
resources should be handled by the hypervisor. Individual resources
should be claimed for a guest only for non-PCI devices one wants
the guest to have access to.

> it means we need remove the old iomem permission/mapping and add the new 
> iomem permission, although not sure if any other impact. And if we want to 
> add this support to pciback/hypervisor, we can of course cover the MSI-x 
> read-only situation.
> 
>>Again - knowing about the PCI hierarchy doesn't mean knowing about
>>all resources. One option clearly is to require a (new) callout from Dom0
>>when any resources get adjusted. What I don't like about this is that
>>all existing Dom0 kernels would need fixing, i.e. I'd prefer a solution
>>that is contained to hypervisor+tools.
> 
> If we trust dom0, we don't need care dom0's writing access.

This is not just about Dom0's write access - I'm in particular talking
about resource adjustments done to passed through devices.

> If we don't trust dom0, and if hypervisor does not protect pci configuration 
> space access, this new callout, comparing with your patch, seems make no 
> difference IMHO. 
> 
> Anyway, your patch do make great improvement, these issues (global list, 
> guest's existing mapping and checking in _sh_propgate) is not important, or 
> can be enhanced later, I'm glad to verify your patch on my system. Do you 
> have any updated patch, or I can simply use the one you sent out on Aug, 13?

Yes, that one should be fine and up-to-date.

Jan