| |
|
 |
|
 |
|
|
|
| |
|
|
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
|
|
|
| |
|
Home