[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: |
Laszlo Ersek |
Subject: |
Re: [Qemu-devel] [PATCH 6/6] [wip] tseg, part2, not (yet) tested |
Date: |
Tue, 21 Apr 2015 17:05:14 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 |
On 04/21/15 16:38, Paolo Bonzini wrote:
>
>
> 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.
Hm, I must have missed this (or not seen it at all) -- should I have
noticed it in Gerd's series somewhere (or in yours)? Or is that by
virtue of mapping mch->tseg_window as a subregion of mch->smram?
(These overlays are pretty confusing, without a graphical visualization :))
>> 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.
Great, thank you.
Yet another question -- as far as I understand, I should have enough
info (with my pending questions of course) for EFI_SMM_ACCESS2_PROTOCOL.
I've now reviewed EFI_SMM_CONTROL2_PROTOCOL too, and AFAICS the only
thing I need to know for it is "how to raise an SMI, synchronously".
What are the plans for that? An ioport write perhaps? (I skimmed the
ICH9 spec, but whatever I found seemed to be quite inappropriate.)
Thanks
Laszlo
- 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, 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, 2015/04/21
- Re: [Qemu-devel] [PATCH 6/6] [wip] tseg, part2, not (yet) tested,
Laszlo Ersek <=
- 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
Re: [Qemu-devel] [PATCH 6/6] [wip] tseg, part2, not (yet) tested, Gerd Hoffmann, 2015/04/21