[Keir Fraser]
On 28/3/08 09:37, "Jiang, Yunhong" <yunh...@intel.com> 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
41 messages in com.xensource.lists.xen-develRe: [Xen-devel] [PATCH 1/5] Add MSI s...
.patch