Re: [RFC] Porting KVM to QEMU CVS

Anthony Liguori
2006-12-21T16:11:17Z

Avi Kivity wrote:
>>
>>> 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.

Okay, that makes sense.

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

Right.

>> 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?

I was hoping to be able to do this with something like CPUID but there
isn't a bit. Right now I'm using PIO but I'd have to ask on the bochs
mailing list whether or not this is a reasonable thing to do.

The current bochs bios doesn't really do anything with SMM. It merely
enables or disables ACPI.

Regards,

Anthony Liguori

>
>>>
>>>> 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.