Re: [Qemu-devel] [RFC] Next gen kvm api

[Anthony Liguori]

On 02/16/2012 02:57 AM, Gleb Natapov wrote:
> On Wed, Feb 15, 2012 at 03:59:33PM -0600, Anthony Liguori wrote:
> > On 02/15/2012 07:39 AM, Avi Kivity wrote:
> > > On 02/07/2012 08:12 PM, Rusty Russell wrote:
> > > > > I would really love to have this, but the problem is that we'd need a
> > > > > general purpose bytecode VM with binding to some kernel APIs.  The
> > > > > bytecode VM, if made general enough to host more complicated devices,
> > > > > would likely be much larger than the actual code we have in the kernel now.
> > > >
> > > > We have the ability to upload bytecode into the kernel already.  It's in
> > > > a great bytecode interpreted by the CPU itself.
> > >
> > > Unfortunately it's inflexible (has to come with the kernel) and open to
> > > security vulnerabilities.
> >
> > I wonder if there's any reasonable way to run device emulation
> > within the context of the guest.  Could we effectively do something
> > like SMM?
> >
> > For a given set of traps, reflect back into the guest quickly
> > changing the visibility of the VGA region. It may require installing
> > a new CR3 but maybe that wouldn't be so bad with VPIDs.
> What will it buy us? Surely not speed. Entering a guest is not much
> (if at all) faster than exiting to userspace and any non trivial
> operation will require exit to userspace anyway,

You can emulate the PIT/RTC entirely within the guest using kvmclock which 
doesn't require an additional exit to get the current time base.

So instead of:

1) guest -> host kernel
2) host kernel -> userspace
3) implement logic using rdtscp via VDSO
4) userspace -> host kernel
5) host kernel -> guest

You go:

1) guest -> host kernel
2) host kernel -> guest (with special CR3)
3) implement logic using rdtscp + kvmclock page
4) change CR3 within guest and RETI to VMEXIT source RIP

Same basic concept as PS/2 emulation with SMM.

Regards,

Anthony Liguori