Re: [RFC] Porting KVM to QEMU CVS

Avi Kivity
2006-12-21T08:36:34Z

Anthony Liguori wrote:
> Avi Kivity wrote:
>> Anthony Liguori wrote:
>>> Any thoughts?
>>
>> SMM continues the tradition of making each x86 generation hackier
>> than before.
>>
>> What happens (probably) is that the virtual hardware unmaps the vga
>> memory when SMM is entered, and uses the physical memory at these
>> addresses (which is not normally accessible) to store the SMI handler
>> code.
>
> Doh! SMM uses the VGA memory doesn't it. Now it all makes sense :-)

That last sentence is rarely heard in the context of PC architecture.

>
> If I disable SMM in the Bochs BIOS, the patch works quite happily with
> the latest CVS. I've attached the patch for reference.
>
>> The way to fix this (again, probably) is to:
>>
>> 1. Revert the 0-640K/1MB-end-of-memory slot thing and create just one
>> memory slot for all physical RAM.
>
> We lose the VGA optimization here right?

No. The vga optimization is that access to the pci framebuffer (which
is at a runtime-determined address, but not the vga hole) is through
direct access rather than mmio. The code in cirrus.c that creates the
framebuffer as a kvm memory slot is thy key to that optimization.

>
>> 2. Add hacks in the memory slot code to not return a memory slot if
>> the physical address is in the forbidden range.
>
> I'm not sure I understand what you mean by this. I guess I have to
> spend some time and understand how the whole memory slot thing works.

Memory slots are just like the DIMM (or, since the qemu model is rather
old, SIMM) slots in a PC.

A PC memory controller has circuitry to route memory access to a DIMM or
to the PCI bus. The logic is something like this (first match wins):

- if the access is to the VGA hole, and we're not in SMM, route the
access to PCI (the vga controller will route it further to somewhere in
the framebuffer)
- if the access is to the VGA hole, and we are in SMM mode, route to the
DIMM that contains the address
- if the access is to the ROM areas (0xf0000-0xfffff), route to the ROM
- if the access is to an area mapped by a DIMM, do that
- otherwise it's an mmio access

My proposal is to implement the special runtime routing table. This way
we can have a DIMM that covers all of memory including the forbidden hole.

Entry into SMM will issue an ioctl() to remove the vga routing; exit
from SMM will reinstall it.

>
>> 3. Add another hack to disable the first hack when SMM is entered and
>> re-enabled it when SMM is exited (e.g. some ioctl).
>
> I'll have to read a little more into SMM. It can be entered at any
> moment right?

yes.

> I seem to recall that either the VT or SVM spec has special handling
> for SMIs?

At least VT. It's horribly complex. It's meant more for the host
rather than the guest.

>
> Another option to consider would simply be to have the BIOS detect
> whether or not the emulated hardware supports SMM dynamically (right
> now, it's a compile time switch). This would let us turn it off in
> QEMU when KVM is enabled.
>

That may be best. What does SMM buy us anyway?

>>
>>> Is anyone else working on this?
>>
>> I intended to merge qemu once a release is made. However, if you get
>> this working and it is stable, it may make sense to merge sooner as I
>> very much like qemu cvs.
>
> I would rather just submit this patch (with the BIOS hack) to QEMU and
> try and get it picked up in CVS. There are some regressions at the
> moment in CVS so it may be nice for users to have an 0.8.2 based
> version available. What do you think?
>
> Would be nice to have KVM support in QEMU CVS by the time 2.6.20 rolls
> out.

I'll reply to this in the next email, this one's too long already.

--
error compiling committee.c: too many arguments to function