| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: Improving hvm IO performance by using self IO emulat
> > Perhaps the network device ought to be the first to move?
>
> I think I will start with the most simple device :-)
Good plan :-)
> > > IMHO it should come with hvmload. No needs to make it unreachable.
> >
> > Mmmm. It's not like the guest can break security if it tampers with the
> > device models in its own memory space.
>
> [Maybe I don't catch all the english here]
> How can the guest break security WRT an usual PV domain ?
It can't - I just meant that it's no worse having the emulators in the domain
itself than having a paravirtualised domain. It doesn't imply an increase in
trust, so there's no particular reason not to put emulators in the guest.
> > Question: how does this compare with using a "stub domain" to run the
> > device models? The previous proposed approach was to automatically
> > switch to the stub domain on trapping an IO by the HVM guest, and have
> > that stub domain run the device models, etc.
>
> Is there a partial/full implementation of stub domain ?
> The pro of firmware approach compared to stub domain is the easy way to do
> it: it doesn't requires of lot of modification in the HV.
I believe some folks are working on this, but I'm not sure there's a "proper"
stub domain with emulators linked to mini-os (as per the original plan) yet.
It's nice that modification isn't required - I suspect it also means less
changes in the tools, etc, are necessary.
> > A cool little trick that this strategy could enable is to run a full Qemu
> > instruction emulator within the device model - I'd imagine this could be
> > useful on IA64, for instance, in order to provide support for running
> > legacy OSes (e.g. for x86, or *cough* PPC ;-))
>
> That's something I'd like to have too.
This is probably another discussion, but there's some interesting design
questions here regarding how the CPU emulation would fit in. For instance,
whether it would need to be done in such a way that the guest could be
save/restored (or even live migrated!) between x86 and IA64 machines...
Being able to do this would be cool, but I'm not sure how useful it would be
in the real world! This also has implications for whether the PV drivers
would use the host architecture protocol or the guest architecture
protocol... This stuff could get fun :-)
In any case, getting it working in any form would be an advance.
Cheers,
Mark
--
Dave: Just a question. What use is a unicyle with no seat? And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home