All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
To: Anthony Liguori <aliguori-NZpS4cJIG2HvQtjrzfazuQ@public.gmane.org>
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [RFC] Porting KVM to QEMU CVS
Date: Thu, 21 Dec 2006 10:36:34 +0200	[thread overview]
Message-ID: <458A4792.1000309@qumranet.com> (raw)
In-Reply-To: <458A07C3.3080000-NZpS4cJIG2HvQtjrzfazuQ@public.gmane.org>

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


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

  parent reply	other threads:[~2006-12-21  8:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-18  4:57 [RFC] Porting KVM to QEMU CVS Anthony Liguori
     [not found] ` <45861F9D.7070006-NZpS4cJIG2HvQtjrzfazuQ@public.gmane.org>
2006-12-18  8:16   ` Avi Kivity
     [not found]     ` <45864E67.3050803-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2006-12-21  4:04       ` Anthony Liguori
     [not found]         ` <458A07C3.3080000-NZpS4cJIG2HvQtjrzfazuQ@public.gmane.org>
2006-12-21  8:36           ` Avi Kivity [this message]
     [not found]             ` <458A4792.1000309-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2006-12-21 16:11               ` Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=458A4792.1000309@qumranet.com \
    --to=avi-atkuwr5tajbwk0htik3j/w@public.gmane.org \
    --cc=aliguori-NZpS4cJIG2HvQtjrzfazuQ@public.gmane.org \
    --cc=kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.