From: Jan Beulich <jbeulich@suse.com>
To: Stewart Hildebrand <stewart.hildebrand@amd.com>
Cc: "Wei Liu" <wl@xen.org>,
"Anthony PERARD" <anthony.perard@citrix.com>,
"Juergen Gross" <jgross@suse.com>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"George Dunlap" <george.dunlap@citrix.com>,
"Julien Grall" <julien@xen.org>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Christian Lindig" <christian.lindig@citrix.com>,
"David Scott" <dave@recoil.org>,
"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>,
"Bertrand Marquis" <bertrand.marquis@arm.com>,
"Volodymyr Babchuk" <Volodymyr_Babchuk@epam.com>,
"Roger Pau Monné" <roger.pau@citrix.com>,
"Oleksandr Andrushchenko" <oleksandr_andrushchenko@epam.com>,
"Rahul Singh" <rahul.singh@arm.com>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4 2/5] xen/vpci: move xen_domctl_createdomain vPCI flag to common
Date: Tue, 31 Oct 2023 11:56:28 +0100 [thread overview]
Message-ID: <1c27d0a7-f04d-32ff-05df-4da4c32bebdf@suse.com> (raw)
In-Reply-To: <20231030235240.106998-3-stewart.hildebrand@amd.com>
On 31.10.2023 00:52, Stewart Hildebrand wrote:
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -607,7 +607,8 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
> {
> unsigned int max_vcpus;
> unsigned int flags_required = (XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap);
> - unsigned int flags_optional = (XEN_DOMCTL_CDF_iommu | XEN_DOMCTL_CDF_vpmu);
> + unsigned int flags_optional = (XEN_DOMCTL_CDF_iommu | XEN_DOMCTL_CDF_vpmu |
> + XEN_DOMCTL_CDF_vpci);
Is the flag (going to be, with the initial work) okay to have for Dom0
on Arm?
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -712,7 +712,8 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
> return 0;
> }
>
> -static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
> +static bool emulation_flags_ok(const struct domain *d, uint32_t emflags,
> + uint32_t cdf)
While apparently views differ, ./CODING_STYLE wants "unsigned int" to be
used for the latter two arguments.
> @@ -722,14 +723,17 @@ static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
> if ( is_hvm_domain(d) )
> {
> if ( is_hardware_domain(d) &&
> - emflags != (X86_EMU_VPCI | X86_EMU_LAPIC | X86_EMU_IOAPIC) )
> + (!( cdf & XEN_DOMCTL_CDF_vpci ) ||
Nit: Stray blanks inside the inner parentheses.
> + emflags != (X86_EMU_LAPIC | X86_EMU_IOAPIC)) )
> return false;
> if ( !is_hardware_domain(d) &&
> - emflags != (X86_EMU_ALL & ~X86_EMU_VPCI) &&
> - emflags != X86_EMU_LAPIC )
> + ((cdf & XEN_DOMCTL_CDF_vpci) ||
> + (emflags != X86_EMU_ALL &&
> + emflags != X86_EMU_LAPIC)) )
> return false;
> }
> - else if ( emflags != 0 && emflags != X86_EMU_PIT )
> + else if ( (cdf & XEN_DOMCTL_CDF_vpci) ||
Wouldn't this better be enforced in common code?
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -892,10 +892,11 @@ static struct domain *__init create_dom0(const module_t *image,
> {
> dom0_cfg.flags |= (XEN_DOMCTL_CDF_hvm |
> ((hvm_hap_supported() && !opt_dom0_shadow) ?
> - XEN_DOMCTL_CDF_hap : 0));
> + XEN_DOMCTL_CDF_hap : 0) |
> + XEN_DOMCTL_CDF_vpci);
Less of a change and imo slightly neater as a result would be to simply
put the addition on the same line where CDF_hvm already is. But as with
many style aspects, views may differ here of course ...
Jan
next prev parent reply other threads:[~2023-10-31 10:57 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-30 23:52 [PATCH v4 0/5] Kconfig for PCI passthrough on ARM Stewart Hildebrand
2023-10-30 23:52 ` [PATCH v4 1/5] xen/arm: pci: introduce PCI_PASSTHROUGH Kconfig option Stewart Hildebrand
2023-10-30 23:52 ` [PATCH v4 2/5] xen/vpci: move xen_domctl_createdomain vPCI flag to common Stewart Hildebrand
2023-10-31 10:56 ` Jan Beulich [this message]
2023-10-31 17:27 ` Stewart Hildebrand
2023-10-30 23:52 ` [PATCH v4 3/5] xen/arm: enable vPCI for dom0 Stewart Hildebrand
2023-10-30 23:52 ` [PATCH v4 4/5] [FUTURE] xen/arm: enable vPCI for domUs Stewart Hildebrand
2023-10-31 11:03 ` Jan Beulich
2023-10-31 13:17 ` Julien Grall
2023-10-31 14:15 ` Stewart Hildebrand
2023-10-31 16:17 ` Jan Beulich
2023-10-30 23:52 ` [PATCH v4 5/5] [FUTURE] tools/arm: " Stewart Hildebrand
2023-11-01 9:25 ` [PATCH v4 0/5] Kconfig for PCI passthrough on ARM Christian Lindig
2023-11-02 17:53 ` Stewart Hildebrand
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=1c27d0a7-f04d-32ff-05df-4da4c32bebdf@suse.com \
--to=jbeulich@suse.com \
--cc=Volodymyr_Babchuk@epam.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@citrix.com \
--cc=bertrand.marquis@arm.com \
--cc=christian.lindig@citrix.com \
--cc=dave@recoil.org \
--cc=george.dunlap@citrix.com \
--cc=jgross@suse.com \
--cc=julien@xen.org \
--cc=marmarek@invisiblethingslab.com \
--cc=oleksandr_andrushchenko@epam.com \
--cc=rahul.singh@arm.com \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=stewart.hildebrand@amd.com \
--cc=wl@xen.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.