[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: APIC rework
On 11/24/09 11:44, Konrad Rzeszutek Wilk wrote: >> At least dom0 parses this info from DSDT, so we can't have the assuption >> whether it is used or not, I think. And I also agree to add a new physdev_op >> to handle this case, and it should be better way to go. >> Based on this idea, I worked out the patch, attached! In this patch, we >> introduced a new physdev_op PHYSDEVOP_setup_gsi for each GSI setup, and each >> domain can require to map each GSI in this case. >> In addition, I believe it is very safe to port the hypervisor patch to >> xen-3.4-x tree and keeps pv_ops dom0 running on it, since no logic is >> changed. BTW, I also tested apic and non-apic cases, they works fine after >> applying the patches. >> > But I don't think you tested PCI front and PCI back. > > Mainly these lines worry me (can you inline the patch next time too, please): > (Inline+attach, or an inline attachment rather than plain inline, is best. Plain inline with quoted-printable encoding is awkward to deal with.) > + map_irq.domid = DOMID_SELF; > > + map_irq.type = MAP_PIRQ_TYPE_GSI; > > + map_irq.index = gsi; > > + map_irq.pirq = irq; > > + rc = HYPERVISOR_physdev_op(PHYSDEVOP_map_pirq, &map_irq); > > > For PCI passthrough to work, the domid needs to be for the guest domain, while > in this case it is set to Dom0. > > There is already a method of extracting the domain id for PCI devices passed > to > the guest. Look in the 'xen_create_msi_irq' function. > Hm, I'm not very keen on having xen_create_msi_irq do its own traversal of xenstore; it should take the domid as a parameter and its caller can do the walk if necessary. The direct call makes too much of a direct dependency between two otherwise unrelated subsystems. J _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |