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] [PATCH 1/5] Add MSI support to XEN

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 1/5] Add MSI support to XEN
From: Espen Skoglund <espen.skoglund@xxxxxxxxxxxxx>
Date: Fri, 28 Mar 2008 12:01:12 +0000
Cc: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>, "Shan, Haitao" <haitao.shan@xxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>, "Li, Xin B" <xin.b.li@xxxxxxxxx>
Delivery-date: Fri, 28 Mar 2008 05:02:19 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C4126EB7.1E74B%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C4126EB7.1E74B%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
[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