Re: [Xen-ia64-devel] [1/9] fix GET_THIS_PADDR
Hi, Tristan Le Vendredi 23 Juin 2006 13:15, Akio Takebe a 馗rit : Hi, Tristan GET_THIS_PADDR translate from only per_cpu virtual address to per_cpu physcal address. Yes. per_cpu address is in TLB. Is it true even within MCA handler ? Yes, TR is unchanged by SAL/PAL when INIT is occerred. Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] xencons interrupt problem
I was hoping to enable xencons as the default console, but I've run into a problem. I have a system that has the console UART and core I/O NIC sharing the same interrupt (both are PCI devices). The ia64_xen_vector bit array does not prevent the guest from writing the IOSAPIC RTE value because it's only checking the vector value programmed into the RTE, not the existing value (ie. Xen programs it to vector 49, the guest wants to program it to vector 50, Xen allows the guest write). That much seems fairly easily fixable, but how do we allow Xen and dom0 to share an RTE? We not only need to forward on the interrupt to the domain, but we may need to translate it to the vector the guest tried to program. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] xencons interrupt problem
Hi Kevin, On Mon, 2006-06-26 at 10:25 +0800, Tian, Kevin wrote: Hi, Alex, Currently xen irq subsystem doesn't support PCI device to be shared between xen and dom0. For example, easy to find some check against this scenario like in pirq_guest_bind. 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? 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. 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, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] xencons interrupt problem
From: Alex Williamson [mailto:[EMAIL PROTECTED] 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@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] xencons interrupt problem
On Mon, 2006-06-26 at 11:27 +0800, Tian, Kevin wrote: 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? Hi Kevin, Yes, the PCDP firmware table tells us all the details of the console UART, base address, GSI, interrupt polarity/trigger, etc... So we don't need any additional ACPI/PCI knowledge to get the UART running in interrupt mode. 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 Great, this is what I was thinking too. I'll try to look into adding this. 3. Do we need to hide such console from dom0, since the latter only uses para-virtualized xenconsole? This is a little tricky. I think for now we'll likely use the same CONFIG_XEN_DISABLE_SERIAL option that x86 uses to hide all the UARTs from dom0. Ideally we could hide them dynamically to allow a transparent VP kernel to still use a serial console. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
