Re: [Xen-devel] [PATCH 1/5] Add MSI support to XEN

[Espen Skoglund <espen.skoglund@xxxxxxxxxxxxx>]

[Keir Fraser]

> On 28/3/08 09:37, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:

>> DomainU (PV and hvm) should have no idea of vector. Do you think it
>> will matter if domain0 have such idea?  one thing missed here is,
>> if domainU want to access the MSI config spafce, pci backend should
>> return 0xff. Then it should be secure if domain0 can have idea of
>> vector.

> No, it's not a security risk for dom0 kernel to know about real
> vectors.  It's already part of the TCB.

> It's just a question of which is the cleanest design. And letting
> Xen get some access to PCI config space (just a little -- not a lot
> -- and under direction of dom0 kernel) will let it properly mask
> MSIs, which would be a nicer and deadlock-free alternative to the
> 'ACK-NEW' masking method.


With the introduction of VT-d interrupt remapping you might want to
relinquish some more control of the PCI config space to Xen anyway.
More precisely, the interrupt address and message data written into
the MSI capability structure or MSI-X Table will no longer be the
destination APIC id, interrupt type, vector, etc., for delivering the
interrupt.  Instead, the information goes into the interrupt remapping
table, and a special remappable message type goes into the capabilty
structure/MSI-X table.  This already happens for IOAPIC entries.  The
alternative is to put the interrupt remapping table under the control
of dom0.

        eSk


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