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

["Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>]

Keir Fraser <mailto:keir.fraser@xxxxxxxxxxxxx> wrote:
> On 27/3/08 07:00, "Shan, Haitao" <haitao.shan@xxxxxxxxx> wrote:
> 
>> This patch changes the pirq to be per-domain in xen tree.
>> 
>> Signed-off-by: Jiang Yunhong <yunhong.jiang@xxxxxxxxx>
>> Signed-off-by: Shan Haitao     <haitao.shan@xxxxxxxxx>
> 
> I'm not sure why this would be a prerequisite for the rest of the MSI
> support. Still I have a feeling that I may have asked for this
> a long time
> ago on a previous iteration of this patchset... :-) It looks pretty
> sensible, but PHYSDEVOP_map_irq shouldn't take an IRQ_TYPE_IRQ --
'IRQ' is a
> meaningless thing architecturally-speaking, and I think
> instead we should
> allow to specify a 'GSI' or an 'ISA IRQ'.
> 
> As for mapping pirq to MSI, I'm not sure about making real
> interrupt vectors
> visible to the guest. But maybe that's unavoidable. The way I
> could imagine
> this working is to teach Xen a bit about accessing PCI space,
> and then have
> the guest relinquish control of critical MSI control fields in
> the config
> space to Xen. The guest would tell Xen where the fields are,
> and then Xen
> can freely configure the target APIC, mask, etc. Seems neater
> to me, but is
> this a nuts idea?

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.

> 
> -- Keir

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