[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] Re: APIC rework



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): 
> 
> +               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.

Could you detail the concern ?  This hypercall is only related to GSI, not MSI, 
why it has side-effect about pci passthrough ? 

Xiantao


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.