mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Jürgen Groß" <jgross@suse.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
	Jason Andryuk <jason.andryuk@amd.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH 0/2] xen: Fix PV-only build
Date: Thu, 6 Aug 2026 14:00:22 +0200	[thread overview]
Message-ID: <967208c9-8d51-4380-8cb4-298f5c313d35@suse.com> (raw)
In-Reply-To: <62b5117f-928d-4908-9217-cc16d9cf15f9@suse.com>


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

On 06.08.26 13:31, Jan Beulich wrote:
> On 06.08.2026 12:55, Juergen Gross wrote:
>> On 06.08.26 03:52, Jason Andryuk wrote:
>>> Allow disabling XEN_PVHVM for a PV-only.  A stub in the event channel
>>> code needs to be fixed first.
>>>
>>> Jason Andryuk (2):
>>>     xen/events: Fix xen_set_upcall_vector stub
>>>     xen/Kconfig: select XEN_PVHVM
>>>
>>>    arch/x86/xen/Kconfig             | 8 +++++---
>>>    drivers/xen/events/events_base.c | 2 +-
>>>    2 files changed, 6 insertions(+), 4 deletions(-)
>>>
>>
>> I did a comparison of a kernel built with your patches disabling XEN_PVHVM
>> and my patches with XEN_PVHVM_GUEST disabled.
>>
>> The kernel built with my patches is 6 bytes smaller than the one with your
>> patches.
> 
> Isn't this a sign of something else needing tweaking, somewhere?

This is a sign that there are probably only very few really HVM specific paths
(in the sense of: explicitly not marked as irrelevant for PV) in the kernel.
Yes, I'm sure you can find some more, but I'm really not sure this is relevant
for more than a handful of users.

>> So I don't see any reason to take your patches, which conflict with mine,
>> especially as my patches have a negative diffstat on source level, too.
> 
> Hmm, Jason's patches look to move things into a more adequate direction,
> though. In which case I think a negative diffstat becomes an irrelevant
> argument?

Depends on what you are looking for.

My take from this is that a PV-only kernel with Jason's patches is not really
adding any value, while my simplification is at least making things simpler
in terms of code volume and number of Xen related config options.

Of course it would be possible to have a smaller PV-only kernel, but as I said
already, there has been no public demand for that in the last years and the
downsides IMHO far outweigh the potential gain.

IMO the "adequate direction" regarding Xen specific kernel code is towards PVH
and not towards more PV specific tweaking. And I'm very sure the kernel
community outside of the Xen community is agreeing with me here.


Juergen

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

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

  reply	other threads:[~2026-08-06 12:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-06  1:52 Jason Andryuk
2026-08-06  1:52 ` [PATCH 1/2] xen/events: Fix xen_set_upcall_vector stub Jason Andryuk
2026-08-06  1:52 ` [PATCH 2/2] xen/Kconfig: select XEN_PVHVM Jason Andryuk
2026-08-06  6:20   ` Jan Beulich
2026-08-06 10:55 ` [PATCH 0/2] xen: Fix PV-only build Juergen Gross
2026-08-06 11:31   ` Jan Beulich
2026-08-06 12:00     ` Jürgen Groß [this message]
2026-08-06 13:24       ` Jason Andryuk
2026-08-06 13:31         ` Juergen Gross
2026-08-06 13:58           ` Jason Andryuk

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=967208c9-8d51-4380-8cb4-298f5c313d35@suse.com \
    --to=jgross@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jason.andryuk@amd.com \
    --cc=jbeulich@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=oleksandr_tyshchenko@epam.com \
    --cc=sstabellini@kernel.org \
    --cc=tglx@kernel.org \
    --cc=x86@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®