Re: [Xen-devel] [PATCH][v2] xen: Pass the location of the ACPI RSDP to DOM0.

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.01.14 at 22:19, Philip Wernersbach <philip.wernersbach@xxxxxxxxx> 
>>> wrote:
> On Tue, Jan 21, 2014 at 4:51 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>> On 20.01.14 at 23:08, Philip Wernersbach <philip.wernersbach@xxxxxxxxx> 
>>>>> wrote:
>>> xen: [v2] Pass the location of the ACPI RSDP to DOM0.
>>>
>>> Some machines, such as recent IBM servers, only allow the OS to get the
>>> ACPI RSDP from EFI. Since Xen nukes DOM0's ability to access EFI, DOM0
>>
>> This reads as if this was a bug in Xen, which it isn't. Dom0's
>> lack of EFI support when running on top of Xen is the issue.
> 
> It all depends on how you look at it, as there's two ways to fix this.
> Linux currently supports EFI just fine. Xen nukes DOM0's ability to
> access EFI using the current methods, which causes Linux's existing
> EFI support to fail. This would be Xen's fault. If Xen currently
> exposes EFI to DOM0 in some other way that Linux is not aware of, then
> this would be Linux's fault. Either way, we can either choose to fix
> Xen or fix Linux.

Which implies you don't understand the fundamental concepts of
Xen PV guests and/or EFI and/or the implications thereof on the
interaction of the two: PV guests (including Dom0) aren't fully
privileged (they don't run in ring 0), and hence _can't_ be allowed
direct access to EFI services and data. Such accesses _have to_
go through the hypervisor.

>> I think I had indicated my opposition to this sort of hack on v1
>> already; I'm not sure I asked which OSes usable as Dom0 but
>> other than Linux recognize this option. Or which versions of
>> Linux actually do (I'm pretty sure older ones don't).
>>
>> Bottom line - I continue to think that the issue should be fixed
>> in Linux.
> 
> The method that this patch uses is a valid way to fix this. In the
> best case, the DOM0 OS recognizes this option and uses it. In the
> worst case, the DOM0 OS won't recognize the option and will ignore it,
> so we're no worse off.

OSes may also choose to not ignore but choke on unknown options
passed to them.

> I agree with you that this is more of a stop gap than a long term fix.
> The final solution is to fully expose EFI services to the DOM0 in some
> way. However, getting there will take some time. The reason this patch
> came about is that the company I work for bought new IBM servers in
> the hope of migrating our existing Xen server farm to the new IBM
> servers. But we soon found out that DOM0 couldn't find the ACPI RSDP
> pointer on the new IBM servers, which means that Xen is dead in the
> water on these machines for now. The final solution of exposing EFI to
> the DOM0 is the ultimate goal, but for now businesses need an
> immediate solution. This provides an acceptable solution until DOM0
> EFI services are implemented at a later date. There is no reason why
> this can't be merged now and then removed when DOM0 EFI service
> support arrives.

One of the reasons I'm not in agreement with this view is that this
change papers over one of the issues but completely ignores others
(like the DMI tables likely also not being found on such systems by
the Dom0 OS, or like there not necessarily being an RTC available;
there are more things here - just go check what data can be
retrieved from Xen, and think about how the OS would get at that
data without proper EFI support implemented). I hope you agree
that it's unreasonable to work around all of these via command line
options. And I hope you understand that by not working around
them, you may end up with an apparently working system that in
the end breaks long after boot rather than right at boot (likely
leading to data loss, which I personally view as much worse than
not being able to boot on a certain system).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel