On Wed, 2006-07-26 at 23:37 -0700, Jeremy Fitzhardinge wrote: > Rusty Russell wrote: > > I want to make three changes to this over time: > > > > 1) Copy the ops structure in the asm, based on value of %ebx (0 == xen, > > etc). Only copy the non-NULL entries, to make implementing ops simple > > (eg. Xen doesn't want to override all ops). Xen wants %esi, so I might > > have to move that to %eax: I'll see how it works out. > > > > I'm coming to the conclusion that having separate entrypoints for each > hypervisor is really the right way to go. Assuming that all hypervisors > have some way to set the entrypoint, then its reasonable to also assume > they're each going to have a different method for doing do (ideally > orthogonal to each other). That means that if Xen does it with its > __xen_guest string section and VMI does it some other (possibly similar) > way, they can all get along. Hi Jeremy, I completely disagree with this. While it's great that Xen has a way of encapsulating this information, there's no good reason not to have a (Linux) standard way of doing so. Of course, it should work with Xen, too, which is why it's written the way it is... Remember, my goal differs substantially from yours and Zachs: it is to make writing a new hypervisor interface as simple as possible. > It isn't clear to me who sets %ebx in your proposal. If you're > suggesting that the hypervisors do it, it seems like a bit presumptuous > to have a specific mechanism just for us. If you're saying that a > common PV startup function needs to try to sniff what hypervisor its > under, that seems very tricky, particularly since we can't take any > faults at that point. Naah, the hypervisor sets %ebx. That's 0 for you, so it's all fine. > Its also possible that a hypervisor is fully virtualizing, so that boot > proceeds via the normal startup_32 path, but at some later point the > guest can register some pv_ops for better performance. (Similar to your > idea for an in-kernel modular hypervisor.) Indeed, and that in no way conflicts with this entry point. > At some future point, it would be nice to be able to load replacement > paravirt ops implementations via multiboot/grub modules (or some similar > mechanism), so that a the interface to the hypervisor can be updated for > old guests. I envision that it would steal control away from the > in-kernel paravirt code by redirecting the entrypoint, install a new > pv_ops structure and then boot as normal (I haven't investigated this at > all; this is just the most plausible-sounding mechanism I thought of). > This would be the moral equivalent of compiling a new scsi driver for an > old kernel in order to support new hardware. It's similar to the idea > that VMI can replace the ROM from boot to boot, but at a source-level > API level rather than a fixed long-term ABI. Um, Jeremy, so exactly what are you smoking? 8) Since this requires a reboot anyway, just put it in the new kernel. Or, if you want to do this without a reboot, use a module to mug paravirt_ops (not yet possible, but not too hard to add later). Either way, it's not today's problem AFAICT. > I also considered the idea of having NULL pointers in the pv_ops > structure and only copying non-NULL pointers, but I decided against it. > It seems cleaner to me to explicitly set the pointer to the nopara_ > function, so that you can easily look at the structure and see which > functions have been implemented and which have been forgotten. But far messier to have to de-static and declare those internal functions. Given how many Xen wants as the default, the NULL solution works well. In my startup_paravirt scheme, you don't have to use it; it's up to your init function. > > 3) Rename from xen-head.S to paravirt-head.S. > > > > My plan was that there would be a paravirt-foo directory for each > hypervisor, and a corresponding foo-specific entrypoint in head.S, which > would be included from foo-head.S. Seems fair: if we end up with only a couple of files in those dirs we can always collapse them back. > > Yep, and I thought about set_tss_desc, rather than lower-level ops, > > because Xen doesn't want it at all. But see how you go.. > > Yeah. I was just looking at load_idt, which is pretty strange. The Xen > version of it ignores the argument and always loads its own exception table. > > I'm thinking that if we need it at all, it should be called something > like load_exceptions(void). Perhaps it should take the argument, but > only do something if it == &idt_descr... This is one of those things I think we'd have to see what the patches turn out like... Cheers! Rusty. -- Help! Save Australia from the worst of the DMCA: http://linux.org.au/law
