Keir Fraser <mailto:Keir.Fraser@xxxxxxxxxxxx> scribbled on Sunday, June
10, 2007 2:31 AM:
> On 10/6/07 06:42, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx> wrote:
>
>> Keir Fraser <mailto:Keir.Fraser@xxxxxxxxxxxx> scribbled on Saturday,
>> June 09, 2007 3:01 AM:
>>> On 9/6/07 01:39, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx> wrote:
>>>
>> I'd prefer not to consume the low 1M region unnecessarily, but most
>> importantly, this region can't be hidden from dom0. We'd really
>> like to protect the sboot code as though it were part of the
>> hypervisor, since it will be needed on shutdown/S3. However, dom0
>> requires access to al sub-1M addresses or it faults.
>
> Xen could be moved to 2MB easily enough. But even Xen now has a
> permanent real-mode mapping at 0x90000. We could protect it by copying
the
> bottom megabyte somewhere else in the physical address space, and
translating
> mapping requests into the copy. This would also protect the BIOS and
> other stuff which may not get refreshed across a soft reboot.
In order to transition to real mode we will need to stay below 1M, so I
think your suggestion of copying it and translating to the copy will
turn out to be the best solution to the problem. Plus, if the
trampoline code is used after initial boot then it really should be
protected from dom0 as well. Will you be making this change?
>> Actually, we've already started work on using the real mode
>> trampoline entry point. It was just easier to add the protected
>> mode entry point to get the patch out sooner.
>
> So the AP entry point in the shared page will go away?
Yes, the AP entry point would no longer be needed.
>> The VMX container is only used for the APs, so it would not help the
>> BSP to detect that it was launched from sboot. There is a Intel(r)
>> TXT -specific way to detect this, by reading the chipset registers
>> (though that only detects that a measured launch happened, not that
>> sboot was used). Since the TXT chipset regions will not have to be
>> fixmap'ed once we have the code working to exit into sboot for the
>> shutdown, the shared page seemed the most reasonable way to
>> communicate. It will also be needed to convey the shutdown entry
>> point to Xen.
>
> Another issue is that Xen now calls the BIOS to get the e820 map
> itself, since GRUB was messing it up on some systems. Hence your
modified
> e820 map will, by default, be ignored.
As Linux also reads the memory map directly, I expected that we would
end up having to modify BIOS's copy eventually. Looks like perhaps
sooner than later. When will this change go into the tree?
> Perhaps we could take a multiboot_info feature bit, or add an extra
> multiboot module, to indicate sboot and to provide shared info?
This would also work. One advantage of the modified e820 table is that
I expect that most software that parses it will treat the new types as
reserved and so will not use the regions that it marks, even if that
software was not specifically modified to recognize the types.
>
> -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home