[Xen-devel] /sys/hypervisor entries for Xen (Domain-0, PV, PVH and HVM)

[Xen-devel] /sys/hypervisor entries for Xen (Domain-0, PV, PVH and HVM)

[Steven Haigh]

Hi all,

I'm working on fixing up the grub packages for Fedora in deducing the 
new BLS logic in Fedora and disabling it in non-compatible environments.

BZ Report:
https://bugzilla.redhat.com/show_bug.cgi?id=1703700

Currently, it seems that we can deduce the following two scenarios:

in /sys/hypervisor:

1) type == xen && uuid == all zeros, then this is BLS safe (the 
Domain-0).
2) type == xen && uuid != all zeros, then this is BLS *unsafe* (covers 
PV, HVM and PVH guests).

Is there any other variables that come into effect that could cause a 
variation in the above checks as to enable or disable BLS?

Right now, I'm proposing that we try to disable the new BLS behaviour 
in Fedora for PV, HVM and PVH guests - as pygrub is not up to the task 
of booting them. We included HVM as it may be common for users to 
switch between HVM and PVH configurations for the same installed VM.

Any comments either here or via the BZ report above would be welcome.

Steven Haigh

📧 netwiz@crc.id.au     💻 https://www.crc.id.au
📞 +613 9001 6090       📱 +614 1293 5897




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] /sys/hypervisor entries for Xen (Domain-0, PV, PVH and HVM)

[M A Young]

On Wed, 9 Oct 2019, Steven Haigh wrote:

> Hi all,
> 
> I'm working on fixing up the grub packages for Fedora in deducing the new BLS
> logic in Fedora and disabling it in non-compatible environments.
> 
> BZ Report:
> https://bugzilla.redhat.com/show_bug.cgi?id=1703700
> 
> Currently, it seems that we can deduce the following two scenarios:
> 
> in /sys/hypervisor:
> 
> 1) type == xen && uuid == all zeros, then this is BLS safe (the Domain-0).
> 2) type == xen && uuid != all zeros, then this is BLS *unsafe* (covers PV, HVM
> and PVH guests).
> 
> Is there any other variables that come into effect that could cause a
> variation in the above checks as to enable or disable BLS?
> 
> Right now, I'm proposing that we try to disable the new BLS behaviour in
> Fedora for PV, HVM and PVH guests - as pygrub is not up to the task of booting
> them. We included HVM as it may be common for users to switch between HVM and
> PVH configurations for the same installed VM.

I do have a long term plan to try to get pygrub to handle BLS, though I 
don't expect to have it working soon.

	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] /sys/hypervisor entries for Xen (Domain-0, PV, PVH and HVM)

[Steven Haigh]

Thanks Michael,

In the meantime, we're looking at just disabling BLS by default in the 
grub packages within Fedora when its run on a Xen guest. This means we 
should at least be at a point where Fedora guests will work reliably 
again as Xen guests.

It seems to be agreed that this will stay in place until such point 
where pygrub understands BLS and this no longer becomes an issue - and 
likely there'd be some overlap to let the updated pygrub spread as far 
as possible before yanking out this workaround.

For now, the only big issue that remains is that the current pygrub 
will always boot the second image in the list due to pygrub incorrectly 
parsing the failover sections of the Fedora grub.cfg where the failover 
will set 'default=1' causing this behaviour.

Assuming that the Fedora side is resolved, and we always get a non-BLS 
grub.cfg in a Fedora guest, is there a simpler fix that could be 
included before Xen 4.13 gets launched (and hopefully backported)?

I'm not sure if the proposed changes to Fedora makes this a little 
simpler in fixing the entire issue.

(apologies for top posting, Geary doesn't seem to like letting me 
bottom post!)

Steven Haigh

📧 netwiz@crc.id.au     💻 https://www.crc.id.au
📞 +613 9001 6090       📱 +614 1293 5897


On Wed, Oct 9, 2019 at 09:00, M A Young <m.a.young@durham.ac.uk> wrote:
> On Wed, 9 Oct 2019, Steven Haigh wrote:
> 
>>  Hi all,
>> 
>>  I'm working on fixing up the grub packages for Fedora in deducing 
>> the new BLS
>>  logic in Fedora and disabling it in non-compatible environments.
>> 
>>  BZ Report:
>>  https://bugzilla.redhat.com/show_bug.cgi?id=1703700
>> 
>>  Currently, it seems that we can deduce the following two scenarios:
>> 
>>  in /sys/hypervisor:
>> 
>>  1) type == xen && uuid == all zeros, then this is BLS safe (the 
>> Domain-0).
>>  2) type == xen && uuid != all zeros, then this is BLS *unsafe* 
>> (covers PV, HVM
>>  and PVH guests).
>> 
>>  Is there any other variables that come into effect that could cause 
>> a
>>  variation in the above checks as to enable or disable BLS?
>> 
>>  Right now, I'm proposing that we try to disable the new BLS 
>> behaviour in
>>  Fedora for PV, HVM and PVH guests - as pygrub is not up to the task 
>> of booting
>>  them. We included HVM as it may be common for users to switch 
>> between HVM and
>>  PVH configurations for the same installed VM.
> 
> I do have a long term plan to try to get pygrub to handle BLS, though 
> I
> don't expect to have it working soon.
> 
> 	Michael Young
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] /sys/hypervisor entries for Xen (Domain-0, PV, PVH and HVM)

[M A Young]

On Wed, 9 Oct 2019, Steven Haigh wrote:

> For now, the only big issue that remains is that the current pygrub will
> always boot the second image in the list due to pygrub incorrectly parsing the
> failover sections of the Fedora grub.cfg where the failover will set
> 'default=1' causing this behaviour.

I did post a very hacky patch to improve this to xen-devel and should 
have a more acceptable set of patches for this soon.

	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel