RE: [Xen-ia64-devel] Paravirt_ops/hybrid directions and next steps
Tristan: We are talking about pv_ops interface calling convention, not hypervisor API convention. It should not violate each other because we still have hypervisor wrapper which can do the convertion. One thing in my mind is that when we do pv_ops, we stand in hypervisor neutral position. Only when we implement xen hypervisor wrapper of pv_ops, we stand on Xen. But yes, since we use single source, dual compile to generate code in place. Actually those pv_cpu_asm_ops won't be used frequently, most of them are not used. So even we use this policy, it is very few place which may use a formal pv_ops for ASM code which imply the calling convention. All IVT/gate table/page doesn't have this issue. Thanks, eddie -Original Message- From: Tristan Gingold [mailto:[EMAIL PROTECTED] Sent: 2008年3月11日 17:24 To: Dong, Eddie Cc: Alex Williamson; xen-ia64-devel Subject: Re: [Xen-ia64-devel] Paravirt_ops/hybrid directions and next steps Hi, just a point about call convention: I don't think switching to PAL static convention is a good idea as it doesn't work well with xen hyperprivop because of banked registers. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Paravirt_ops/hybrid directions and next steps
Hi, just a point about call convention: I don't think switching to PAL static convention is a good idea as it doesn't work well with xen hyperprivop because of banked registers. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Paravirt_ops/hybrid directions and next steps
On Mon, 2008-03-10 at 13:56 +0800, Dong, Eddie wrote: Alex all: I exchanged some ideas with Isaku to discuss the gap and status of pv_ops support in IA64, Isaku did a lot of work toward pv_ops since his previous forward backport patch. Great thanks to Isaku. The attached doc is a draft for some of the key gaps and current status. I think it is time for another cross major company meeting to discuss how we cooperate and how effectively go with pv_ops. Mostly Isaku and I are in same page for what IA64 pv_ops should look like now, though some details may have different understanding. Any ideas? Hi Eddie, Much thanks to you and Isaku for leading this effort. I'm open to another conference call, but maybe we can discuss some items here on the mailing list too. I saw that Isaku has created a wiki page on the Xen wiki and started a new git project on Gitorious.org. The wiki page seems like a good place to keep track of who is working on which chunk and the status. For the git side, I would suggest that the model might be that each developer has a project on gitorious.org and sends out patches or pull requests to have a single upstream reference. Isaku's tree seems to be a good focal point for now if he's willing to take on the task of accepting code from others. The 2.6.26 merge window will likely open before too long, so we also need to do some coordination with Tony Luck and the other upstream developers. Are they going to be interested in putting in pieces at each upstream merge window, or should we build up a complete solution for domU support in Isaku's tree or Tony's testing branch first? We also need to be careful about submitting patch sets that stand on their own and are bisect-able. It's likely going to take several kernel merge windows before we get full domU support, let alone dom0. In your slide set, you mention removing running_on_xen since it conflicts with pv_ops. I think this is a really good goal, but I have doubts about whether it's achievable. We're not likely to make a pv_ops to fit every corner case, and we may have to resort to an ugly direct test for xen. Let's try to avoid them, but we already have a few cases of checking machine vector names for this type of thing in other parts of the ia64 code. 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] Paravirt_ops/hybrid directions and next steps
Alex Williamson wrote: On Mon, 2008-03-10 at 13:56 +0800, Dong, Eddie wrote: Alex all: I exchanged some ideas with Isaku to discuss the gap and status of pv_ops support in IA64, Isaku did a lot of work toward pv_ops since his previous forward backport patch. Great thanks to Isaku. The attached doc is a draft for some of the key gaps and current status. I think it is time for another cross major company meeting to discuss how we cooperate and how effectively go with pv_ops. Mostly Isaku and I are in same page for what IA64 pv_ops should look like now, though some details may have different understanding. Any ideas? Hi Eddie, Much thanks to you and Isaku for leading this effort. I'm open to another conference call, but maybe we can discuss some items here on the mailing list too. I saw that Isaku has created a wiki page on the Xen wiki and started a new git project on Gitorious.org. The wiki page seems like a good place to keep track of who is working on which chunk and the status. For the git side, I would suggest that the model might be that each developer has a project on gitorious.org and sends out patches or pull requests to have a single upstream reference. Isaku's tree seems to be a good focal point for now if he's willing to take on the task of accepting code from others. The 2.6.26 merge window will likely open before too long, so we also need to do some coordination with Tony Luck and the other Since we are unable to get whole solution (dom0) to upstream in near future since X86 didn't complete it yet. OSV are unable to build single image for all, so I think they may stay with current solution a little bit longer till X86 get solved. I am not that care about which version IA64 pv_ops will be in. As if Tony starts to take the patch, the rest will be easy. upstream developers. Are they going to be interested in putting in pieces at each upstream merge window, or should we build up a complete solution for domU support in Isaku's tree or Tony's testing Yes, we need to get clear message firstly. In the doc, I was assuming maintainer need to see whole patch, though he takes one slowly at beginning especially. branch first? We also need to be careful about submitting patch sets that stand on their own and are bisect-able. It's likely going to Agree, so at least we get xen-ia64/kvm-ia64 people buy in the patch first so that we can push together. take several kernel merge windows before we get full domU support, let alone dom0. In your slide set, you mention removing running_on_xen since it conflicts with pv_ops. I think this is a really good goal, but I have doubts about whether it's achievable. We're not likely to make a My assumption is that Linux maintainer won't expect to see running_on_xen, running_on_kvm, running_on_lguest, running_on_hybrid_xen, running_on_hybrid_kvm etc. It is too ugly. But if you mean we keep it temporary for now, I am fine. pv_ops to fit every corner case, and we may have to resort to an ugly direct test for xen. Let's try to avoid them, but we already have a few cases of checking machine vector names for this type of thing in other parts of the ia64 code. Thanks, Could you point me to the code that you feel pv_ops may be hard here? Alex Thanks, eddie ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Paravirt_ops/hybrid directions and next steps
Hi Eddie, On Tue, 2008-03-11 at 06:43 +0800, Dong, Eddie wrote: Alex Williamson wrote: In your slide set, you mention removing running_on_xen since it conflicts with pv_ops. I think this is a really good goal, but I have doubts about whether it's achievable. We're not likely to make a My assumption is that Linux maintainer won't expect to see running_on_xen, running_on_kvm, running_on_lguest, running_on_hybrid_xen, running_on_hybrid_kvm etc. It is too ugly. But if you mean we keep it temporary for now, I am fine. Right, it's a pretty lightweight test to keep around for now, and maybe we can eventually remove it completely. However, we might end up with something that only one VMM cares about and need to keep it around. If all the VMMs are tripping on the same issue, then we can upgrade it or integrate it into a pv_op. pv_ops to fit every corner case, and we may have to resort to an ugly direct test for xen. Let's try to avoid them, but we already have a few cases of checking machine vector names for this type of thing in other parts of the ia64 code. Thanks, Could you point me to the code that you feel pv_ops may be hard here? I don't have any architecture specific examples off the top of my head, but how about skipping serial port detection on dom0? It's rather Xen specific and we haven't yet come up with a way to hide Xen's UART (ioport mmio) from dom0. KVM/Lguest wouldn't care about this, so it may not be worthy of a pv_op. 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] Paravirt_ops/hybrid directions and next steps
I don't have any architecture specific examples off the top of my head, but how about skipping serial port detection on dom0? It's rather Xen specific and we haven't yet come up with a way to hide Xen's UART (ioport mmio) from dom0. KVM/Lguest wouldn't care about this, so it may not be worthy of a pv_op. Thanks, Hi, Alex. We can keep this detail in pv_ops enabling time to see if we can get a right abstract. I assume we will need 1-2 month to make it full pv_ops. Thanks, Eddie ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
