From: Alejandro Vallejo <agarciav@amd.com>
To: Jason Andryuk <jason.andryuk@amd.com>,
"Daniel P. Smith" <dpsmith@apertussolutions.com>,
<xen-devel@lists.xenproject.org>
Cc: stefano.stabellini@amd.com, "Jan Beulich" <jbeulich@suse.com>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [RFC 03/38] x86/hyperlaunch: convert max vcpu determination to domain builder
Date: Fri, 25 Apr 2025 16:05:19 +0100 [thread overview]
Message-ID: <D9FT9CGX7VBK.1SKSWAY7UG6SV@amd.com> (raw)
In-Reply-To: <b3069950-ac03-4603-866c-27c6166bfecf@amd.com>
On Tue Apr 22, 2025 at 9:36 PM BST, Jason Andryuk wrote:
> On 2025-04-19 18:07, Daniel P. Smith wrote:
>> + limit = dom0_max_vcpus();
>
> dom0_max_vcpus() applies Xen's dom0_max_vcpus command line option. That
> is desirable for a traditional dom0. For a disaggregated, Hyperlaunch
> system, I'm not sure it's appropriate. Considering there can multiple
> control domains, it's more questionable.
>
> Might it be better to only apply Xen "dom0" command line options to
> non-hyperlaunch dom0? Or a domain with all of
> BUILD_CAPS_CONTROL/HARDWARE/XENSTORE?
Alternatively, why not apply it to the hardware domain instead? That's
guaranteed to be (at most) one, and will still function appropriately
when doing non-DTB based boots.
I'll make this adjustment while rebasing this rfc against my latest
hlaunch series.
>
> I guess it could stay as-is, but it seems unusual.
And would probably be particularly weird when it applies to all your
control domains and _not to your hardware domain, which incidentally is
the one domain with domid 0.
>
> Regards,
> Jason
Cheers,
Alejandro
next prev parent reply other threads:[~2025-04-25 15:05 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-19 22:07 [RFC 00/38] Hyperlaunch domain builder Daniel P. Smith
2025-04-19 22:07 ` [RFC 01/38] maintainers: add new section for hyperlaunch Daniel P. Smith
2025-04-19 22:07 ` [RFC 02/38] x86/hyperlaunch: correct the naming of domain ramdisk field Daniel P. Smith
2025-04-19 22:07 ` [RFC 03/38] x86/hyperlaunch: convert max vcpu determination to domain builder Daniel P. Smith
2025-04-22 20:36 ` Jason Andryuk
2025-04-25 15:05 ` Alejandro Vallejo [this message]
2025-04-25 22:03 ` Daniel P. Smith
2025-04-19 22:07 ` [RFC 04/38] x86/hyperlaunch: convert vcpu0 creation " Daniel P. Smith
2025-04-25 15:22 ` Alejandro Vallejo
2025-04-25 22:04 ` Daniel P. Smith
2025-04-28 10:33 ` Alejandro Vallejo
2025-04-28 11:01 ` Jan Beulich
2025-04-19 22:07 ` [RFC 05/38] x86/hyperlaunch: move dom0 cpuid policy behind capability check Daniel P. Smith
2025-04-19 22:07 ` [RFC 06/38] x86/hyperlaunch: add hardware domain capability support Daniel P. Smith
2025-04-19 22:07 ` [RFC 07/38] x86/hyperlaunch: introduce pvh domain builder Daniel P. Smith
2025-04-19 22:07 ` [RFC 08/38] x86/hyperlaunch: move initial hwdom setup to dom_construct_pvh Daniel P. Smith
2025-04-19 22:07 ` [RFC 09/38] x86/boot: convert dom0 page calculation to use boot domain Daniel P. Smith
2025-04-19 22:07 ` [RFC 10/38] x86/boot: refactor dom0 page calculation Daniel P. Smith
2025-04-19 22:07 ` [RFC 11/38] x86/boot: generalize paging pages calculation Daniel P. Smith
2025-04-19 22:07 ` [RFC 12/38] x86/boot: generalize compute number of domain pages Daniel P. Smith
2025-04-19 22:07 ` [RFC 13/38] x86/hyperlaunch: move page computation to domain builder Daniel P. Smith
2025-04-19 22:07 ` [RFC 14/38] x86/hyperlaunch: move pvh p2m init " Daniel P. Smith
2025-04-19 22:07 ` [RFC 15/38] x86/hyperlaunch: move iommu " Daniel P. Smith
2025-04-19 22:07 ` [RFC 16/38] x86/boot: move and rename sched_setup_dom0_vcpus Daniel P. Smith
2025-04-20 9:36 ` Jürgen Groß
2025-04-22 12:38 ` Daniel P. Smith
2025-04-25 22:05 ` Daniel P. Smith
2025-04-19 22:07 ` [RFC 17/38] x86/hyperlaunch: move pvh_setup_cpus to domain builder Daniel P. Smith
2025-04-19 22:08 ` [RFC 18/38] x86/boot: rename pvh acpi setup function Daniel P. Smith
2025-04-19 22:08 ` [RFC 19/38] x86/hyperlaunch: add domu memory map construction Daniel P. Smith
2025-04-19 22:08 ` [RFC 20/38] x86/hyperlaunch: move populating p2m under domain builder Daniel P. Smith
2025-04-19 22:08 ` [RFC 21/38] x86/hyperlaunch: move remaining pvh dom0 construction Daniel P. Smith
2025-04-19 22:08 ` [RFC 22/38] x86/hyperlaunch: relocate pvh_steal_ram to domain builder Daniel P. Smith
2025-04-19 22:08 ` [RFC 23/38] x86/hyperlaunch: add domu acpi construction Daniel P. Smith
2025-04-19 22:08 ` [RFC 24/38] x86/boot: export command line processing Daniel P. Smith
2025-04-19 22:08 ` [RFC 25/38] x86/hyperlaunch: convert create_dom0 to arch_create_dom Daniel P. Smith
2025-04-19 22:08 ` [RFC 26/38] x86/hyperlaunch: remove dom0-isms from arch_create_dom Daniel P. Smith
2025-04-19 22:08 ` [RFC 27/38] x86/hyperlaunch: introduce domain builder general dom creation Daniel P. Smith
2025-04-19 22:08 ` [RFC 28/38] x86/hyperlaunch: add xenstore boot capabilities flag Daniel P. Smith
2025-04-19 22:08 ` [RFC 29/38] x86/hyperlaunch: allocate console for domu Daniel P. Smith
2025-04-19 22:08 ` [RFC 30/38] x86/hyperlaunch: allocate xenstore " Daniel P. Smith
2025-04-19 22:08 ` [RFC 31/38] x86/hyperlaunch: move boot module discard to domain builder Daniel P. Smith
2025-04-19 22:08 ` [RFC 32/38] x86/hyperlaunch: introduce concept of core domains Daniel P. Smith
2025-04-23 19:50 ` Jason Andryuk
2025-04-25 22:06 ` Daniel P. Smith
2025-04-19 22:08 ` [RFC 33/38] x86/boot: refactor bzimage parser to be re-enterant Daniel P. Smith
2025-04-23 19:27 ` Jason Andryuk
2025-04-25 22:16 ` Daniel P. Smith
2025-04-26 1:53 ` Daniel P. Smith
2025-04-28 6:41 ` Jan Beulich
2025-04-28 14:16 ` Jason Andryuk
2025-04-19 22:08 ` [RFC 34/38] x86/hyperlaunch: introduce multidomain kconfig option Daniel P. Smith
2025-04-19 22:08 ` [RFC 35/38] x86/hyperlaunch: add multidomain construction logic Daniel P. Smith
2025-04-19 22:08 ` [RFC 36/38] x86/hyperlaunch: enable unpausing mulitple domains Daniel P. Smith
2025-04-19 22:08 ` [RFC 37/38] x86/hyperlaunch: generalize domid assignment Daniel P. Smith
2025-04-19 22:08 ` [RFC 38/38] tools: introduce hyperlaunch domain late init Daniel P. Smith
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=D9FT9CGX7VBK.1SKSWAY7UG6SV@amd.com \
--to=agarciav@amd.com \
--cc=andrew.cooper3@citrix.com \
--cc=dpsmith@apertussolutions.com \
--cc=jason.andryuk@amd.com \
--cc=jbeulich@suse.com \
--cc=roger.pau@citrix.com \
--cc=stefano.stabellini@amd.com \
--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.