[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
- Re: [Qemu-devel] [PATCH 5/6] [wip] tseg, part1, not (yet) tested, (continued)
- Re: [Qemu-devel] [PATCH 5/6] [wip] tseg, part1, not (yet) tested, Laszlo Ersek, 2015/04/22
- Re: [Qemu-devel] [PATCH 5/6] [wip] tseg, part1, not (yet) tested, Laszlo Ersek, 2015/04/22
- Re: [Qemu-devel] [PATCH 5/6] [wip] tseg, part1, not (yet) tested, Gerd Hoffmann, 2015/04/23
- Re: [Qemu-devel] [PATCH 5/6] [wip] tseg, part1, not (yet) tested, Laszlo Ersek, 2015/04/23
- Re: [Qemu-devel] [PATCH 5/6] [wip] tseg, part1, not (yet) tested, Laszlo Ersek, 2015/04/23
- Re: [Qemu-devel] [PATCH 5/6] [wip] tseg, part1, not (yet) tested, Gerd Hoffmann, 2015/04/23
- Re: [Qemu-devel] [PATCH 5/6] [wip] tseg, part1, not (yet) tested, Laszlo Ersek, 2015/04/23
- Re: [Qemu-devel] [PATCH 5/6] [wip] tseg, part1, not (yet) tested, Paolo Bonzini, 2015/04/23
[Qemu-devel] [PATCH 6/6] [wip] tseg, part2, not (yet) tested, Gerd Hoffmann, 2015/04/20
- Re: [Qemu-devel] [PATCH 6/6] [wip] tseg, part2, not (yet) tested, Laszlo Ersek, 2015/04/21
- Re: [Qemu-devel] [PATCH 6/6] [wip] tseg, part2, not (yet) tested,
Paolo Bonzini <=
- Re: [Qemu-devel] [PATCH 6/6] [wip] tseg, part2, not (yet) tested, Laszlo Ersek, 2015/04/21
- Re: [Qemu-devel] [PATCH 6/6] [wip] tseg, part2, not (yet) tested, Gerd Hoffmann, 2015/04/21
- Re: [Qemu-devel] [PATCH 6/6] [wip] tseg, part2, not (yet) tested, Paolo Bonzini, 2015/04/21
- [Qemu-devel] implementing EFI_SMM_CONTROL2_PROTOCOL.Trigger() (was: [PATCH 6/6] [wip] tseg, part2, not (yet) tested), Laszlo Ersek, 2015/04/21
- Re: [Qemu-devel] implementing EFI_SMM_CONTROL2_PROTOCOL.Trigger(), Paolo Bonzini, 2015/04/21
- Re: [Qemu-devel] [edk2] implementing EFI_SMM_CONTROL2_PROTOCOL.Trigger() (was: [PATCH 6/6] [wip] tseg, part2, not (yet) tested), Yao, Jiewen, 2015/04/24
- Re: [Qemu-devel] [edk2] implementing EFI_SMM_CONTROL2_PROTOCOL.Trigger(), Paolo Bonzini, 2015/04/24
- Re: [Qemu-devel] [edk2] implementing EFI_SMM_CONTROL2_PROTOCOL.Trigger(), Yao, Jiewen, 2015/04/24
- Re: [Qemu-devel] [edk2] implementing EFI_SMM_CONTROL2_PROTOCOL.Trigger() (was: [PATCH 6/6] [wip] tseg, part2, not (yet) tested), Yao, Jiewen, 2015/04/24
- Re: [Qemu-devel] [edk2] implementing EFI_SMM_CONTROL2_PROTOCOL.Trigger(), Laszlo Ersek, 2015/04/24