Mailing List Archive

[PATCH v3 00/13] viridian: add support for ExProcessorMasks...
From: Paul Durrant <pdurrant@amazon.com>

... plus one miscellaneous cleanup patch after introducing sizeof_field().

Paul Durrant (13):
viridian: don't blindly write to 32-bit registers is 'mode' is invalid
viridian: move flush hypercall implementation into separate function
viridian: move IPI hypercall implementation into separate function
viridian: introduce a per-cpu hypercall_vpmask and accessor
functions...
viridian: use hypercall_vpmask in hvcall_ipi()
viridian: use softirq batching in hvcall_ipi()
xen/include: import sizeof_field() macro from Linux stddef.h
viridian: add ExProcessorMasks variants of the flush hypercalls
viridian: add ExProcessorMasks variant of the IPI hypercall
viridian: log initial invocation of each type of hypercall
viridian: add a new '_HVMPV_ex_processor_masks' bit into
HVM_PARAM_VIRIDIAN...
xl / libxl: add 'ex_processor_mask' into
'libxl_viridian_enlightenment'
x86: replace open-coded occurrences of sizeof_field()...

docs/man/xl.cfg.5.pod.in | 8 +
tools/include/libxl.h | 7 +
tools/libs/light/libxl_types.idl | 1 +
tools/libs/light/libxl_x86.c | 3 +
xen/arch/x86/cpu/vpmu_intel.c | 4 +-
xen/arch/x86/hvm/viridian/viridian.c | 601 +++++++++++++++++++++------
xen/arch/x86/setup.c | 16 +-
xen/include/asm-x86/hvm/viridian.h | 10 +
xen/include/public/hvm/params.h | 7 +-
xen/include/xen/compiler.h | 8 +
10 files changed, 532 insertions(+), 133 deletions(-)

--
2.20.1
RE: [EXTERNAL] [PATCH v3 00/13] viridian: add support for ExProcessorMasks... [ In reply to ]
Wei,

I'll likely send a v4 to address the style nit Jan picked up in patch #1 but the rest should be stable now. Could you have a look over it?

Thanks,

Paul

> -----Original Message-----
> From: Paul Durrant <paul@xen.org>
> Sent: 24 November 2020 19:08
> To: xen-devel@lists.xenproject.org
> Cc: Durrant, Paul <pdurrant@amazon.co.uk>
> Subject: [EXTERNAL] [PATCH v3 00/13] viridian: add support for ExProcessorMasks...
>
> CAUTION: This email originated from outside of the organization. Do not click links or open
> attachments unless you can confirm the sender and know the content is safe.
>
>
>
> From: Paul Durrant <pdurrant@amazon.com>
>
> ... plus one miscellaneous cleanup patch after introducing sizeof_field().
>
> Paul Durrant (13):
> viridian: don't blindly write to 32-bit registers is 'mode' is invalid
> viridian: move flush hypercall implementation into separate function
> viridian: move IPI hypercall implementation into separate function
> viridian: introduce a per-cpu hypercall_vpmask and accessor
> functions...
> viridian: use hypercall_vpmask in hvcall_ipi()
> viridian: use softirq batching in hvcall_ipi()
> xen/include: import sizeof_field() macro from Linux stddef.h
> viridian: add ExProcessorMasks variants of the flush hypercalls
> viridian: add ExProcessorMasks variant of the IPI hypercall
> viridian: log initial invocation of each type of hypercall
> viridian: add a new '_HVMPV_ex_processor_masks' bit into
> HVM_PARAM_VIRIDIAN...
> xl / libxl: add 'ex_processor_mask' into
> 'libxl_viridian_enlightenment'
> x86: replace open-coded occurrences of sizeof_field()...
>
> docs/man/xl.cfg.5.pod.in | 8 +
> tools/include/libxl.h | 7 +
> tools/libs/light/libxl_types.idl | 1 +
> tools/libs/light/libxl_x86.c | 3 +
> xen/arch/x86/cpu/vpmu_intel.c | 4 +-
> xen/arch/x86/hvm/viridian/viridian.c | 601 +++++++++++++++++++++------
> xen/arch/x86/setup.c | 16 +-
> xen/include/asm-x86/hvm/viridian.h | 10 +
> xen/include/public/hvm/params.h | 7 +-
> xen/include/xen/compiler.h | 8 +
> 10 files changed, 532 insertions(+), 133 deletions(-)
>
> --
> 2.20.1
Re: [EXTERNAL] [PATCH v3 00/13] viridian: add support for ExProcessorMasks... [ In reply to ]
On Tue, Dec 01, 2020 at 02:09:40PM -0000, Paul Durrant wrote:
> Wei,
>
> I'll likely send a v4 to address the style nit Jan picked up in patch #1 but the rest should be stable now. Could you have a look over it?

I've only been able to skim-read this patch set, but I agree in general
that adding ExProcessorMasks support is a good idea. It is needed to
cope with more than 64 cpus as far as I can tell.

With Jan's comments addressed.

Acked-by: Wei Liu <wl@xen.org>

Wei.