> -----Original Message-----
> From: Jan Beulich <jbeul...@suse.com>
> Sent: 19 November 2020 16:45
> To: p...@xen.org
> Cc: 'Paul Durrant' <pdurr...@amazon.com>; 'Wei Liu' <w...@xen.org>; 'Andrew
> Cooper'
> <andrew.coop...@citrix.com>; 'Roger Pau Monné' <roger....@citrix.com>;
> xen-devel@lists.xenproject.org
> Subject: Re: [PATCH 06/10] viridian: add ExProcessorMasks variants of the
> flush hypercalls
>
> On 19.11.2020 17:11, Paul Durrant wrote:
> >> From: Jan Beulich <jbeul...@suse.com>
> >> Sent: 12 November 2020 09:19
> >>
> >> On 11.11.2020 21:07, Paul Durrant wrote:
> >>> --- a/xen/arch/x86/hvm/viridian/viridian.c
> >>> +++ b/xen/arch/x86/hvm/viridian/viridian.c
> >>> @@ -553,6 +553,83 @@ static unsigned int vpmask_next(struct
> >>> hypercall_vpmask *vpmask, unsigned int
> >> vp
> >>> (vp) < HVM_MAX_VCPUS; \
> >>> (vp) = vpmask_next(vpmask, vp))
> >>>
> >>> +struct hypercall_vpset {
> >>> + struct hv_vpset set;
> >>> + uint64_t __bank_contents[64];
> >>
> >> gcc documents this to be supported as an extension; did you check
> >> clang supports this, too?
> >
> > By 'this', do you mean the assumption that that memory layout is
> > consecutive?
>
> No, rather the basic language aspect that in standard C a struct
> member which is a struct ending in a flexible array member may
> not be followed by any other field.
>
Ah, ok, now I understand what you mean. I'll union it to reserve the space
instead.
Paul
> Jan
