qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] Memory API


From: Jan Kiszka
Subject: Re: [Qemu-devel] [RFC] Memory API
Date: Thu, 19 May 2011 20:50:59 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2011-05-19 20:18, Anthony Liguori wrote:
> On 05/19/2011 09:11 AM, Avi Kivity wrote:
>> On 05/19/2011 05:04 PM, Anthony Liguori wrote:
>>>
>>> Right, the chipset register is mainly used to program the contents of
>>> SMM.
>>>
>>> There is a single access pin that has effectively the same semantics
>>> as setting the chipset register.
>>>
>>> It's not a per-CPU setting--that's the point. You can't have one CPU
>>> reading SMM memory at the exactly same time as accessing VGA.
>>>
>>> But I guess you can never have two simultaneous accesses anyway so
>>> perhaps it's splitting hairs :-)
>>
>> Exactly - it just works.
> 
> Well, not really.
> 
> kvm.ko has a global mapping of RAM regions and currently only allows
> code execution from RAM.
> 
> This means the only way for QEMU to enable SMM support is to program the
> global RAM regions table to enable allow RAM access for the VGA region.
> 
> The problem with this is that it's perfectly conceivable to have CPU 0
> in SMM mode while CPU 1 is doing MMIO to the VGA planar.
> 
> The same problem exists with PAM.  It would be much easier to implement
> PAM correctly in QEMU if it were possible to execute code via MMIO as we
> could just mark the BIOS memory as non-RAM and deal with the dispatch
> ourselves.

If we already have to change KVM (I guess we have to), let's better add
per-CPU memory slot support. That will allow to switch between VGA and
SMRAM without costly dispatching. At this chance, I think we also need
some support for half-MMIO (MMIO on write, RAM on read) for proper flash
support.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]