[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] RE: [PATCH] bind passthroug pci device interrupt pinsto INTA
>>> Just wonder if there is any need to expose multifunction devices (i.e. >>> have to use INTB, etc.) to the guest in the future. >>> >>> All comments and suggestions are welcomed. >> Keir, I just checked the documentation. It seems that USB device does need to be assigned to guest as a single multifunction device, since the interrupt pin actually used by a single function may not be the same as what shows in the configuration space. So I'm sorry but please ignore this patch at the moment. I'll have it reworked for multifunction device support. -Qing >>Could you set the INT line to the function number? FN0->INTA, FN1->INTB, >>...? This would then work for multi-fn devices, yet still most devices have >>only fn0 and hence would use INTA as you desire. > >The case that makes me want to change this is the USB assignment. If I assign all >USB stuff to a guest, that's already 8 functions within 2 devices using all the INTA to >INTD. Guest gsi sharing will be very likely to happen if I assign another one or two >device. > >There are other options I can think of, including >(a) support sharing of guest gsi. This may also be good for PIC guest where sharing >is more common. However, eoi and unmask of sharing guest gsi would be a pain, if >they have different machine irqs. The implementation is subjected to careful >considerations of corner cases. >(b) change the device model slot allocation policy, to ensure that guest gsi sharing >devices also have the same machine irq. This solution reduces the flexibility. >(c) dynamic routing table, which I assume is not desirable. > > >(a) may be the better way to go, but at the cost of additional complexity. Also, it does >not look very good to me that a guest gsi has to link to multiple machine irqs, >especially in EOI handling part. While simply pins interrupt pins to INTA works fine in >most cases and it's stupidly simple compared with other options. > >Thanks, >Qing >> >> -- Keir >> > > >_______________________________________________ >Xen-devel mailing list >Xen-devel@xxxxxxxxxxxxxxxxxxx >http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |