All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: Stefano Stabellini <sstabellini@kernel.org>, boris.ostrovsky@oracle.com
Cc: julien@xen.org, bertrand.marquis@arm.com,
	Volodymyr_Babchuk@epam.com, xen-devel@lists.xenproject.org
Subject: Re: request for feedback on a Xen/Linux compatibility issue
Date: Thu, 6 Jan 2022 08:13:29 +0100	[thread overview]
Message-ID: <4ea34f61-e72e-76c3-5c20-879fefe4c7f7@suse.com> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2112131729100.3376@ubuntu-linux-20-04-desktop>


[-- Attachment #1.1.1: Type: text/plain, Size: 3161 bytes --]

On 06.01.22 01:40, Stefano Stabellini wrote:
> Hi all,
> 
> Today Xen dom0less guests are not "Xen aware": the hypervisor node
> (compatible = "xen,xen") is missing from dom0less domUs device trees and
> as a consequence Linux initializes as if Xen is not present. The reason
> is that interfaces like grant table and xenstore (xenbus in Linux) don't
> work correctly in a dom0less environment at the moment.
> 
> The good news is that I have patches for Xen to implement PV drivers
> support for dom0less guests. They also add the hypervisor node to device
> tree for dom0less guests so that Linux can discover the presence of Xen
> and related interfaces.
> 
> When the Linux kernel is booting as dom0less kernel, it needs to delay
> the xenbus initialization until the interface becomes ready. Attempts to
> initialize xenbus straight away lead to failure, which is fine because
> xenbus has never worked in Linux when running as dom0less guest up until
> now. It is reasonable that a user needs a newer Linux to take advantage
> of dom0less with PV drivers. So:
> 
> - old Xen + old/new Linux -> Xen not detected in Linux
> - new Xen + old Linux     -> xenbus fails to initialize in Linux
> - new Xen + new Linux     -> dom0less PV drivers working in Linux
> 
> 
> The problem is that Linux until recently couldn't deal with any errors
> in xenbus initialization. Instead of returning error and continuing
> without xenbus, Linux would crash at boot.
> 
> I upstreamed two patches for Linux xenbus_probe to be able to deal with
> initialization errors. With those two fixes, Linux can boot as a
> dom0less kernel with the hypervisor node in device tree. The two fixes
> got applied to master and were already backported to all the supported
> Linux stable trees, so as of today:
> 
> - dom0less with hypervisor node + Linux 5.16+           -> works
> - dom0less with hypervisor node + stable Linux 5.10     -> works
> - dom0less with hypervisor node + unpatched Linux 5.10  -> crashes
> 
> 
> Is this good enough? Or for Xen/Linux compatibility we want to also be
> able to boot vanilla unpatched Linux 5.10 as dom0less kernel? If so,
> the simplest solution is to change compatible string for the hypervisor
> node, so that old Linux wouldn't recognize Xen presence and wouldn't try
> to initialize xenbus (so it wouldn't crash on failure). New Linux can of
> course learn to recognize both the old and the new compatible strings.
> (For instance it could be compatible = "xen,xen-v2".) I have prototyped
> and tested this solution successfully but I am not convinced it is the
> right way to go.
> 
> Do you have any suggestion or feedback?
> 
> The Linux crash on xenbus initialization failure is a Linux bug, not a
> Xen issue. For this reason, I am tempted to say that we shouldn't change
> compatible string to work-around a Linux bug, especially given that the
> Linux stable trees are already all fixed.

What about adding an option to your Xen patches to omit the hypervisor
node in the device tree? This would enable the user to have a mode
compatible to today's behavior.


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3135 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

  reply	other threads:[~2022-01-06  7:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-06  0:40 request for feedback on a Xen/Linux compatibility issue Stefano Stabellini
2022-01-06  7:13 ` Juergen Gross [this message]
2022-01-06 14:03   ` Jan Beulich
2022-01-06 14:24     ` Julien Grall
2022-01-07  0:02       ` Stefano Stabellini
2022-01-07  9:54         ` Julien Grall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ea34f61-e72e-76c3-5c20-879fefe4c7f7@suse.com \
    --to=jgross@suse.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=bertrand.marquis@arm.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=julien@xen.org \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.