I seem to understand your proposal now. Do you mean that some early
table will report the irq line information for the console device out of the
ACPI table? If that's the case, I think changes required to achieve this
purpose is:
1. Modify assign_irq_vector hypercall to allow passing into GSI for
check sharing with PCI serial
If it's sharing, return existing vector instead of a new
allocation
2. Add a new flag to indicate such sharing between xen and dom0,
and remove checks against this style in all places.
When assertion on this irq line happens, pass to xen first and
then to dom0
3. Do we need to hide such console from dom0, since the latter
only uses para-virtualized xenconsole?
En... above should be enough if I understand your requirement correctly.
Thanks,
Kevin
>From: Tian, Kevin
>Sent: 2006年6月26日 11:17
>
>>From: Alex Williamson [mailto:alex.williamson@xxxxxx]
>>Sent: 2006年6月26日 10:54
>>> It easy to fix above checks, like to add an IRQ_BOTH flag on top
>>> of IRQ_GUEST to allow such a case. However the real issue is that
>full
>>> PCI knowledge is owned by dom0 instead of xen. To let xen allocate
>>> resources for PCI serial and check whether specific irq line is shared
>>> between, ACPI namespace enumeration and PCI initialization are
>>> required to be brought back to xen. A big effort and whether worthy of
>>> doing that? Or some special workaround to bypass that for this
>special
>>> serial case?
>>
>> I don't think we have to go to that much trouble, Xen doesn't need to
>>be aware of PCI and ACPI. Xen should be able to note that the
>>interrupt
>>is shareable by it's trigger/polarity, right?
>
>However how does xen know which interrupt line is shared between xen
>and dom0? Shareable doesn't mean actual share, right?
>
>>
>>> For the interrupt name space, currently xen and dom0 share the
>>> same space, meant that vector allocation always happens in xen and
>>> dom0 issues hypercall to retrieve allocated vector back as the one
>>used
>>> in dom0 context directly. Based on this point, xen can ensure same
>>> vector returned to dom0 as the one owned by xen itself if irq sharing
>>> happens. But xen needs PCI knowledge as said above.
>>
>> Xen wouldn't need PCI knowledge to accomplish this. Shouldn't it
>>just need the GSI to determine it's sharing the interrupt w/ the guest?
>>In any case, this seems broken as my dom0 is reprogramming the
>>IOSAPIC
>>RTE w/ a different vector.
>
>That's because current irq allocation doesn't support this share style,
>and thus each assign_irq_vector from dom0 will get a new vector. If
>you have hint to know which irq line is shared with PCI serial port, you
>can change to return same vector when dom0 is requesting for device
>on the same line. Be careful, current difference you observed doesn't
>mean from different vector spaces. Instead they're two vectors
>allocated for same line from same vector space. That's incorrect.
>
>>
>>> Final question is, do we really need support such a PCI serial port
>>> owned by xen? :-)
>>
>> IMHO, yes. This is the core I/O on an HP Superdome, and I don't
>>think a PCI console UART sharing an interrupt with another non-UART
>>device is all that unusual. Thanks,
>
>Definitely it's usual for PCI device sharing. I should say "... support a
>PCI serial port with irq line enabled for xen?" I still doubt the effort and
>flexibility to support such a model, and maybe some check against it
>to fallback to poll mode is the better choice.
>
>Thanks,
>Kevin
>
>_______________________________________________
>Xen-ia64-devel mailing list
>Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-ia64-devel
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home