qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 6/6] [wip] tseg, part2, not (yet) tested


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 6/6] [wip] tseg, part2, not (yet) tested
Date: Tue, 21 Apr 2015 16:38:36 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0


On 21/04/2015 16:30, Laszlo Ersek wrote:
>> > -    MemoryRegion tseg_blackhole;
>> > +    MemoryRegion tseg_blackhole, tseg_window;
>> >      PcPciInfo pci_info;
>> >      ram_addr_t below_4g_mem_size;
>> >      ram_addr_t above_4g_mem_size;
>> > 
> Why is this necessary? If you disable the black hole overlay, the access
> will go to the RAM. (Or can't that be done per-CPU?)

The reason to have two separate MemoryRegions is exactly to allow
per-CPU access.

tseg_blackhole is added on top of address_space_memory to hide TSEG;
tseg_window is included in /machine/smram and TCG adds it to the private
per-CPU address space when it enters system management mode.

> I'm thinking, the last 1 / 2 / 8 megabytes should behave as RAM in all
> of the following cases:
> - no SMRAM programmed (tseg size = 0)
> - SMRAM programmed (tseg size > 0), and it is open
> - SMRAM programmed (tseg size > 0) and closed, but CPU in SMM

Correct.  However, you can have one CPU in SMM and another executing
"normal" code.  It would be a hole to allow that CPU to read (or worse,
write) the TSEG or legacy SMRAM areas.

> ... Another question, related to SMM (but not related to SMRAM): Paolo,
> am I right to think that we'll be keying off at least two independent
> things of SMM-or-not: one is access to SMRAM (tseg), for LockBox and SMM
> driver purposes, the other is pflash access (with the MemTxAttrs thing),
> for the varstore?

Yes.

Paolo



reply via email to

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