>>> On 09.02.18 at 13:35, <jgr...@suse.com> wrote:
> On 30/01/18 16:40, Jan Beulich wrote:
>>>>> On 22.01.18 at 13:32, <jgr...@suse.com> wrote:
>>> @@ -37,10 +52,24 @@ struct vcpu;
>>>  
>>>  struct cpu_info {
>>>      struct cpu_user_regs guest_cpu_user_regs;
>>> -    unsigned int processor_id;
>>> -    struct vcpu *current_vcpu;
>>> -    unsigned long per_cpu_offset;
>>> -    unsigned long cr4;
>>> +    union {
>>> +        /* per physical cpu mapping */
>>> +        struct {
>>> +            struct vcpu *current_vcpu;
>>> +            unsigned long per_cpu_offset;
>>> +            unsigned long cr4;
>>> +        };
>>> +        /* per vcpu mapping (xpti) */
>>> +        struct {
>>> +            unsigned long pad1;
>>> +            unsigned long pad2;
>>> +            unsigned long stack_bottom_cpu;
>>> +        };
>> 
>> In order to avoid accidental use in the wrong context as much as
>> possible, I think you want to name both structures.
> 
> I'd like to leave it as is in order to make a possible backport much
> more easier.

Well, I can see why you would want the pre-existing fields left
without structure field name, but the new (vcpu) ones? And
even the pre-existing (pcpu) ones should gain a name, just
perhaps in a patch late in the series, which then wouldn't be
backported.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Reply via email to