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: Avi Kivity
Subject: Re: [Qemu-devel] [RFC] Memory API
Date: Fri, 20 May 2011 12:15:16 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Thunderbird/3.1.10

On 05/19/2011 09:18 PM, 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.

kvm needs updates to support SMM; I already outlined them several months ago.


The same problem exists with PAM.

PAM is a completely different problem. The changes are global and fit kvm slot management.

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.

Would it be fundamentally hard to support this in KVM? I guess you would need to put the VCPU in single step mode and maintain a page to copy the results into.

You need to emulate everything. We're probably not far from that. However there may be a significant performance loss.


--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.




reply via email to

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