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

Re: [Xen-devel] Move some of the PCI device manage/control into pciback?

[Keir Fraser]
> On 16/01/2009 06:18, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:
>>> I'd rather have all accesses mediated through pciback. I don't
>>> think PCI config accesses should be on any data path anyway, and
>>> you've already taken the hit of trapping to qemu in that case.
>> 
>> There is one exception: The mask bit for MSI/MSI-X. Maybe we need
>> add some mechanism for HVM domain to mask/unmask the virtual
>> interrupt directly, like what DomU did for evtchn. But that will be
>> tricky.

> Yes, that did occur to me. We already have plenty of special
> emulation code for MSI/MSI-x. I guess we may explicitly
> paravirtualise that aspect in a different way which would allow
> ioemu to interact direct with Xen. Actually if mask/unmask happens
> on every IRQ, we may need to push support for the PCI MSI registers
> right down into Xen itself to get decent speed? Because going to
> qemu with any great frequency is not very high performance.

Last time I checked, current Linux code does not update the MSI/MSI-X
mask bits frequently (as in on every IRQ).  Doing so would require
device interaction and could result in quite some overhead.  I don't
know how other systems (e.g., Windows) handles the mask bits.

I don't think we need to optimize for frequent mask bit updates.
Updates due to enabling/disabling interrupts, or masking due to
interrupt storms would be ok to channel through a slower code path.

Please do tell if the above assumption is wrong.

        eSk



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