Re: [PATCH RFC 0/1] Introduce VCPUOP_reset_vcpu_info

[Vitaly Kuznetsov <vkuznets@redhat.com>]

"Jan Beulich" <JBeulich@suse.com> writes:

>>>> On 06.08.14 at 17:03, <vkuznets@redhat.com> wrote:
>> "Jan Beulich" <JBeulich@suse.com> writes:
>>> And why not for CPU 0?
>>>
>> 
>> Because the suggested op will fail for already running CPU0..
>
> Sure, but how do you deal with that?
>

Now pvhvm guests don't call VCPUOP_register_vcpu_info for CPU0 on boot
so it always points to shared_info and there is no need in doing
VCPUOP_reset_vcpu_info.

>>> Furthermore, what is the state of vCPU-s beyond 31 going to be after
>>> they got their vCPU info reset? They won't have any other area as
>>> fallback.
>> 
>> In xen their vcpu_info will point to dummy_vcpu_info (that's what we
>> have there before VCPUOP_register_vcpu_info I guess).
>
> Right, but such a vCPU can't be brought up. Did you verify that
> this holds with your additions?

That's fine as new kernel will call VCPUOP_register_vcpu_info on
bootup. 

>
>> I tested kexec with 64 vcpus case, no issues noticed.
>
> That's purely observation based then, in an environment where
> (for the specific operation here) not much can go wrong. But I guess
> we'll see how things are once you properly document all limitations.

Actually my intention is to bring the state of affairs to the point it
was before first kernel booted (so newly booted kernel will
succeed). VCPUs >= XEN_LEGACY_MAX_VCPUS have their vcpu_info pointing to
dummy_vcpu_info before first VCPUOP_register_vcpu_info call so let's
that is the desired state when doing kexec.

>
> Jan

-- 
  Vitaly