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

Re: [Xen-devel] Xen 4.3 development update, and stock-taking

>>> On 17.01.13 at 17:49, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
> On 17/01/13 16:14, Jan Beulich wrote:
>> And to be clear - unless someone manages to eliminate the 
>> "conceptually wrong" argument above, I'm intending to veto any changes 
>> that violate the model set by the specification. Jan 
> Just for my information, could you describe what you think is 
> "conceptually wrong" about leaving boot services for dom0?  I would 
> consider Xen+dom0 to be two halves of the "Xen system", and so leaving 
> boot services on until dom0 gets a chance to fix up quirks doesn't seem 
> to me any different than leaving it on when booting to Linux directly.  
> If the spec doesn't explicitly say "hypervisor", then I would think 
> "kernel" in a Xen system would conceptually include both Xen and dom0.

But the spec says "OS loader", and that can only be interpreted
as far as up into the very first things a kernel might do. Which in
the Xen case is the hypervisor (much like in Linux'es EFI_STUB
case, the OS loader here really is bundled into the main binary).

- Linux without EFI_STUB has no provisions to call boot services
  (it doesn't even get passed the respective table pointer afaict)
- Linux with EFI_STUB calls boot services only from the stub code,
  and the stub code is what exists boot services

Consequently, with Xen basically replacing the stub code in Linux,
there is no reason to think of other alternative models.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.