Save paused cpu ctx

Save paused cpu ctx

[Isaila Alexandru]

Hello, 

I want to restart the discussion on dropping the "if ( v->pause_flags &
VPF_down )" from hvm_save_cpu_ctxt() and be able to save context in a
vcup down state. The content of the ctx could be filled like it is
described in Intel SDM, "9.1.1 Processor State After Reset" (https://so
ftware.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-
2abcd-3abcd.pdf   page 2996).

Is this enough to be up streamed?


Regards, 
Isaila Alexandru

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

Re: Save paused cpu ctx

[Roger Pau Monné]

On Wed, Sep 19, 2018 at 11:21:32AM +0300, Isaila Alexandru wrote:
> Hello, 
> 
> I want to restart the discussion on dropping the "if ( v->pause_flags &
> VPF_down )" from hvm_save_cpu_ctxt() and be able to save context in a
> vcup down state. The content of the ctx could be filled like it is
> described in Intel SDM, "9.1.1 Processor State After Reset" (https://so
> ftware.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-
> 2abcd-3abcd.pdf   page 2996).

If the point is filling the context with the default reset state why
can't this be done by the tools if required?

It seems like saving the state of down vCPUs is quite pointless since
the state is always going to be the same, and will just increase the
size of the migration stream, but maybe I'm missing something.

Roger.

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

Re: Save paused cpu ctx

[Jan Beulich]

>>> On 19.09.18 at 10:21, <aisaila@bitdefender.com> wrote:
> I want to restart the discussion on dropping the "if ( v->pause_flags &
> VPF_down )" from hvm_save_cpu_ctxt() and be able to save context in a
> vcup down state. The content of the ctx could be filled like it is
> described in Intel SDM, "9.1.1 Processor State After Reset" (https://so 
> ftware.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-
> 2abcd-3abcd.pdf   page 2996).
> 
> Is this enough to be up streamed?

Along the lines of what Roger has said - without knowing _why_ you
want to do that, it's hard to tell. It's pretty clear I think that we don't
want to outright drop the condition, the question is just whether to
somewhat relax it for your purposes.

I'm afraid I also don't agree with your assertion that a down vCPU is
in "after reset" state: To me, such a vCPU could legitimately be
considered to be in that state, in the state it was in when it went
down, or in basically any other (perhaps random) state.

Finally (and I'm sorry for being picky here) - why was this inquiry
addressed _To_ me instead of the list?

Jan



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

Re: Save paused cpu ctx

[Isaila Alexandru]

On Wed, 2018-09-19 at 10:41 +0200, Roger Pau Monné wrote:
> On Wed, Sep 19, 2018 at 11:21:32AM +0300, Isaila Alexandru wrote:
> > Hello, 
> > 
> > I want to restart the discussion on dropping the "if ( v-
> > >pause_flags &
> > VPF_down )" from hvm_save_cpu_ctxt() and be able to save context in
> > a
> > vcup down state. The content of the ctx could be filled like it is
> > described in Intel SDM, "9.1.1 Processor State After Reset" (https:
> > //so
> > ftware.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-
> > 1-
> > 2abcd-3abcd.pdf   page 2996).
> 
> If the point is filling the context with the default reset state why
> can't this be done by the tools if required?
> 
> It seems like saving the state of down vCPUs is quite pointless since
> the state is always going to be the same, and will just increase the
> size of the migration stream, but maybe I'm missing something.
> 
The idea behind this is to be able to query a vcpu and have it's state
because right now xen does not return any info about a vcpu if it's
down. 

We do not want to save the context but just to get info about it as a
result of a query.

Alex

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

Re: Save paused cpu ctx

[Roger Pau Monné]

On Wed, Sep 19, 2018 at 12:02:05PM +0300, Isaila Alexandru wrote:
> On Wed, 2018-09-19 at 10:41 +0200, Roger Pau Monné wrote:
> > On Wed, Sep 19, 2018 at 11:21:32AM +0300, Isaila Alexandru wrote:
> > > Hello, 
> > > 
> > > I want to restart the discussion on dropping the "if ( v-
> > > >pause_flags &
> > > VPF_down )" from hvm_save_cpu_ctxt() and be able to save context in
> > > a
> > > vcup down state. The content of the ctx could be filled like it is
> > > described in Intel SDM, "9.1.1 Processor State After Reset" (https:
> > > //so
> > > ftware.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-
> > > 1-
> > > 2abcd-3abcd.pdf   page 2996).
> > 
> > If the point is filling the context with the default reset state why
> > can't this be done by the tools if required?
> > 
> > It seems like saving the state of down vCPUs is quite pointless since
> > the state is always going to be the same, and will just increase the
> > size of the migration stream, but maybe I'm missing something.
> > 
> The idea behind this is to be able to query a vcpu and have it's state
> because right now xen does not return any info about a vcpu if it's
> down. 
> 
> We do not want to save the context but just to get info about it as a
> result of a query.

Can you infer that vCPUs that don't have a context are down?

Roger.

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

Re: Save paused cpu ctx

[Isaila Alexandru]

On Wed, 2018-09-19 at 03:01 -0600, Jan Beulich wrote:
> > > > On 19.09.18 at 10:21, <aisaila@bitdefender.com> wrote:
> > 
> > I want to restart the discussion on dropping the "if ( v-
> > >pause_flags &
> > VPF_down )" from hvm_save_cpu_ctxt() and be able to save context in
> > a
> > vcup down state. The content of the ctx could be filled like it is
> > described in Intel SDM, "9.1.1 Processor State After Reset" (https:
> > //so 
> > ftware.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-
> > 1-
> > 2abcd-3abcd.pdf   page 2996).
> > 
> > Is this enough to be up streamed?
> 
> Along the lines of what Roger has said - without knowing _why_ you
> want to do that, it's hard to tell. It's pretty clear I think that we
> don't
> want to outright drop the condition, the question is just whether to
> somewhat relax it for your purposes.
> 
> I'm afraid I also don't agree with your assertion that a down vCPU is
> in "after reset" state: To me, such a vCPU could legitimately be
> considered to be in that state, in the state it was in when it went
> down, or in basically any other (perhaps random) state.

Processor State After Reset is just the name of the table in the
manual. Having a default state to return on a query was the start point
of the discussion. You are right, we can return whatever state the cpu
was in before it went down. The code works fine like that, further
more, this will make us have a smaller patch plus a legitimate ctx at
the end of the query.

> Finally (and I'm sorry for being picky here) - why was this inquiry
> addressed _To_ me instead of the list?

It was addressed to you because in v17 of the save_one series you said
that we have to continue the discussion in a different thread. 

Thanks, 
Alex

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

Re: Save paused cpu ctx

[Jan Beulich]

>>> On 19.09.18 at 11:19, <aisaila@bitdefender.com> wrote:
> On Wed, 2018-09-19 at 03:01 -0600, Jan Beulich wrote:
>> > > > On 19.09.18 at 10:21, <aisaila@bitdefender.com> wrote:
>> > 
>> > I want to restart the discussion on dropping the "if ( v-
>> > >pause_flags &
>> > VPF_down )" from hvm_save_cpu_ctxt() and be able to save context in
>> > a
>> > vcup down state. The content of the ctx could be filled like it is
>> > described in Intel SDM, "9.1.1 Processor State After Reset" (https:
>> > //so 
>> > ftware.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-
>> > 1-
>> > 2abcd-3abcd.pdf   page 2996).
>> > 
>> > Is this enough to be up streamed?
>> 
>> Along the lines of what Roger has said - without knowing _why_ you
>> want to do that, it's hard to tell. It's pretty clear I think that we
>> don't
>> want to outright drop the condition, the question is just whether to
>> somewhat relax it for your purposes.
>> 
>> I'm afraid I also don't agree with your assertion that a down vCPU is
>> in "after reset" state: To me, such a vCPU could legitimately be
>> considered to be in that state, in the state it was in when it went
>> down, or in basically any other (perhaps random) state.
> 
> Processor State After Reset is just the name of the table in the
> manual. Having a default state to return on a query was the start point
> of the discussion. You are right, we can return whatever state the cpu
> was in before it went down. The code works fine like that, further
> more, this will make us have a smaller patch plus a legitimate ctx at
> the end of the query.

You didn't understand my response then: There is no "the state" for
a vCPU which is down. Therefore we shouldn't arbitrarily pick one of
the almost infinite number of options.

Also in your reply to Roger you didn't respond at all to the size
growth your proposed change would have for the migration stream,
as pointed out by him.

In any event - for now I continue to think that the code should
remain as is, and the caller should know whether (and _how_) to
deal with down vCPU-s.

>> Finally (and I'm sorry for being picky here) - why was this inquiry
>> addressed _To_ me instead of the list?
> 
> It was addressed to you because in v17 of the save_one series you said
> that we have to continue the discussion in a different thread. 

"We" is the community here, not just you and me.

Jan



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

Re: Save paused cpu ctx

[Razvan Cojocaru]

On 9/19/18 12:39 PM, Jan Beulich wrote:
>>>> On 19.09.18 at 11:19, <aisaila@bitdefender.com> wrote:
>> On Wed, 2018-09-19 at 03:01 -0600, Jan Beulich wrote:
>>>>>> On 19.09.18 at 10:21, <aisaila@bitdefender.com> wrote:
>>>>
>>>> I want to restart the discussion on dropping the "if ( v-
>>>>> pause_flags &
>>>> VPF_down )" from hvm_save_cpu_ctxt() and be able to save context in
>>>> a
>>>> vcup down state. The content of the ctx could be filled like it is
>>>> described in Intel SDM, "9.1.1 Processor State After Reset" (https:
>>>> //so 
>>>> ftware.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-
>>>> 1-
>>>> 2abcd-3abcd.pdf   page 2996).
>>>>
>>>> Is this enough to be up streamed?
>>>
>>> Along the lines of what Roger has said - without knowing _why_ you
>>> want to do that, it's hard to tell. It's pretty clear I think that we
>>> don't
>>> want to outright drop the condition, the question is just whether to
>>> somewhat relax it for your purposes.
>>>
>>> I'm afraid I also don't agree with your assertion that a down vCPU is
>>> in "after reset" state: To me, such a vCPU could legitimately be
>>> considered to be in that state, in the state it was in when it went
>>> down, or in basically any other (perhaps random) state.
>>
>> Processor State After Reset is just the name of the table in the
>> manual. Having a default state to return on a query was the start point
>> of the discussion. You are right, we can return whatever state the cpu
>> was in before it went down. The code works fine like that, further
>> more, this will make us have a smaller patch plus a legitimate ctx at
>> the end of the query.
> 
> You didn't understand my response then: There is no "the state" for
> a vCPU which is down. Therefore we shouldn't arbitrarily pick one of
> the almost infinite number of options.
> 
> Also in your reply to Roger you didn't respond at all to the size
> growth your proposed change would have for the migration stream,
> as pointed out by him.
> 
> In any event - for now I continue to think that the code should
> remain as is, and the caller should know whether (and _how_) to
> deal with down vCPU-s.

The scenario is that we are trying to query the state of a VCPU (please
note: just query). That means that we're only interested in getting some
coherent VCPU state via the XEN_DOMCTL_gethvmcontext_partial domctl.

We don't care if said state ends up being saved for the migration stream
or not, so in that respect the answer to Roger's question is: no size
increase or difference whatsoever.

All we want to do is to be able to query the state of any VCPU in the
valid range of VCPUs assigned to the domain, online or not. We believe
being able to query them is reasonable, and the SDM states that they do
have a state (whatever it happens to be: the init state, after reset, etc.).

For example, please look at this XenServer-only patch:

https://github.com/xenserver/xen.pg/blob/XS-7.1.x/master/x86-domctl-Don-t-pause-the-whole-domain-if-only-gett.patch

It just calls hvm_save_one_cpu_ctxt(v, &ctx); directly, then copies the
result to guest. and that's it. It's neither involving hvm_save_one(),
not does it affect the migration stream whatsoever. Also, whether by
accident or just a fluke, it seems to work with introspection just fine
(which is why Alexandru was asking if maybe it's enough to just let
hvm_save_one_cpu_ctxt() do its thing for correct VCPU state).

Now about the "the agent should do something else if the VCPU is down"
objection, that's not possible with the current Xen code: -ENOENT is
returned both when the VCPU is down _and_ when the VCPU index is out of
bounds (so if I query the state of VCPU 10 on a 2-VCPUs guest).


Thanks,
Razvan

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

Re: Save paused cpu ctx

[Jan Beulich]

>>> On 19.09.18 at 13:11, <rcojocaru@bitdefender.com> wrote:
> The scenario is that we are trying to query the state of a VCPU (please
> note: just query). That means that we're only interested in getting some
> coherent VCPU state via the XEN_DOMCTL_gethvmcontext_partial domctl.
> 
> We don't care if said state ends up being saved for the migration stream
> or not, so in that respect the answer to Roger's question is: no size
> increase or difference whatsoever.

"We don't care" is too little. _We_ care that state for offline vCPU-s does
not make it into the migration stream. And at this point I think you mean
"no size increase or difference whatsoever _intended_", since removing
the check in question would result in a size increase afaict.

> All we want to do is to be able to query the state of any VCPU in the
> valid range of VCPUs assigned to the domain, online or not. We believe
> being able to query them is reasonable, and the SDM states that they do
> have a state (whatever it happens to be: the init state, after reset, etc.).

I didn't know the SDM stated anything about offline vCPU-s. There's
(according to my way of looking at things) no bare hardware equivalent
to this state, which means whatever the SDM says is not applicable.

> For example, please look at this XenServer-only patch:
> 
> https://github.com/xenserver/xen.pg/blob/XS-7.1.x/master/x86-domctl-Don-t-pa 
> use-the-whole-domain-if-only-gett.patch

That's what iirc Alexandru's series started from.

> Now about the "the agent should do something else if the VCPU is down"
> objection, that's not possible with the current Xen code: -ENOENT is
> returned both when the VCPU is down _and_ when the VCPU index is out of
> bounds (so if I query the state of VCPU 10 on a 2-VCPUs guest).

If there are no other ways to inquire vCPU state, I'm sure we can
provide some. I also don't view disambiguating the error code as
an impossible thing to do.

Jan



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

Re: Save paused cpu ctx

[Razvan Cojocaru]

On 9/19/18 3:13 PM, Jan Beulich wrote:
>>>> On 19.09.18 at 13:11, <rcojocaru@bitdefender.com> wrote:
>> The scenario is that we are trying to query the state of a VCPU (please
>> note: just query). That means that we're only interested in getting some
>> coherent VCPU state via the XEN_DOMCTL_gethvmcontext_partial domctl.
>>
>> We don't care if said state ends up being saved for the migration stream
>> or not, so in that respect the answer to Roger's question is: no size
>> increase or difference whatsoever.
> 
> "We don't care" is too little. _We_ care that state for offline vCPU-s does
> not make it into the migration stream. And at this point I think you mean
> "no size increase or difference whatsoever _intended_", since removing
> the check in question would result in a size increase afaict.

Yes, of course. We don't intend any size increase or difference in the
code, nor do we want to unconditionally remove the check. We were
thinking of adding an extra bool parameter to hvm_save_one() to
differentiate between the query case and everything else.

Sorry for not making that clear sooner.

>> All we want to do is to be able to query the state of any VCPU in the
>> valid range of VCPUs assigned to the domain, online or not. We believe
>> being able to query them is reasonable, and the SDM states that they do
>> have a state (whatever it happens to be: the init state, after reset, etc.).
> 
> I didn't know the SDM stated anything about offline vCPU-s. There's
> (according to my way of looking at things) no bare hardware equivalent
> to this state, which means whatever the SDM says is not applicable.

Please see page 311:

https://software.intel.com/sites/default/files/managed/a4/60/325384-sdm-vol-3abcd.pdf

The section is indeed called "Processor State After Reset" which is
clearly not great for the purposes of this discussion, but the important
part is "Table 9-1. IA-32 and Intel 64 Processor States Following
Power-up, Reset, or INIT", which I believe illustrates the processor
states we were talking about.

>> For example, please look at this XenServer-only patch:
>>
>> https://github.com/xenserver/xen.pg/blob/XS-7.1.x/master/x86-domctl-Don-t-pa 
>> use-the-whole-domain-if-only-gett.patch
> 
> That's what iirc Alexandru's series started from.

Indeed. What we've missed initially is that there were two parts to it:
the one that got in with the series (the not pausing the whole domain if
not strictly necessary) and the query part.

>> Now about the "the agent should do something else if the VCPU is down"
>> objection, that's not possible with the current Xen code: -ENOENT is
>> returned both when the VCPU is down _and_ when the VCPU index is out of
>> bounds (so if I query the state of VCPU 10 on a 2-VCPUs guest).
> 
> If there are no other ways to inquire vCPU state, I'm sure we can
> provide some. I also don't view disambiguating the error code as
> an impossible thing to do.

Of course, and if it's inacceptable to upstream the possibility of
querying the state of an offline VCPU we'll do that.


Thanks,
Razvan

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

Re: Save paused cpu ctx

[Jan Beulich]

>>> On 19.09.18 at 14:37, <rcojocaru@bitdefender.com> wrote:
> On 9/19/18 3:13 PM, Jan Beulich wrote:
>>>>> On 19.09.18 at 13:11, <rcojocaru@bitdefender.com> wrote:
>>> The scenario is that we are trying to query the state of a VCPU (please
>>> note: just query). That means that we're only interested in getting some
>>> coherent VCPU state via the XEN_DOMCTL_gethvmcontext_partial domctl.
>>>
>>> We don't care if said state ends up being saved for the migration stream
>>> or not, so in that respect the answer to Roger's question is: no size
>>> increase or difference whatsoever.
>> 
>> "We don't care" is too little. _We_ care that state for offline vCPU-s does
>> not make it into the migration stream. And at this point I think you mean
>> "no size increase or difference whatsoever _intended_", since removing
>> the check in question would result in a size increase afaict.
> 
> Yes, of course. We don't intend any size increase or difference in the
> code, nor do we want to unconditionally remove the check. We were
> thinking of adding an extra bool parameter to hvm_save_one() to
> differentiate between the query case and everything else.

Okay, but we'll have to settle on the "makes sense" part (below) first.

>>> All we want to do is to be able to query the state of any VCPU in the
>>> valid range of VCPUs assigned to the domain, online or not. We believe
>>> being able to query them is reasonable, and the SDM states that they do
>>> have a state (whatever it happens to be: the init state, after reset, etc.).
>> 
>> I didn't know the SDM stated anything about offline vCPU-s. There's
>> (according to my way of looking at things) no bare hardware equivalent
>> to this state, which means whatever the SDM says is not applicable.
> 
> Please see page 311:
> 
> https://software.intel.com/sites/default/files/managed/a4/60/325384-sdm-vol- 
> 3abcd.pdf
> 
> The section is indeed called "Processor State After Reset" which is
> clearly not great for the purposes of this discussion, but the important
> part is "Table 9-1. IA-32 and Intel 64 Processor States Following
> Power-up, Reset, or INIT", which I believe illustrates the processor
> states we were talking about.

I did not question the existence of this description in the manual. What
I continue to question is the presence of something talking about
_virtual_ CPU state. You pointing me to hardware state descriptions
won't change my view that the state of an offline vCPU (note the v!)
is simply undefined, and hence querying it makes no sense.

>>> For example, please look at this XenServer-only patch:
>>>
>>> https://github.com/xenserver/xen.pg/blob/XS-7.1.x/master/x86-domctl-Don-t-pa 
> 
>>> use-the-whole-domain-if-only-gett.patch
>> 
>> That's what iirc Alexandru's series started from.
> 
> Indeed. What we've missed initially is that there were two parts to it:
> the one that got in with the series (the not pausing the whole domain if
> not strictly necessary) and the query part.

Which is a good sign that from (almost) the very beginning this should
have been separate patches.

Jan



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

Re: Save paused cpu ctx

[Razvan Cojocaru]

>>>> All we want to do is to be able to query the state of any VCPU in the
>>>> valid range of VCPUs assigned to the domain, online or not. We believe
>>>> being able to query them is reasonable, and the SDM states that they do
>>>> have a state (whatever it happens to be: the init state, after reset, etc.).
>>>
>>> I didn't know the SDM stated anything about offline vCPU-s. There's
>>> (according to my way of looking at things) no bare hardware equivalent
>>> to this state, which means whatever the SDM says is not applicable.
>>
>> Please see page 311:
>>
>> https://software.intel.com/sites/default/files/managed/a4/60/325384-sdm-vol- 
>> 3abcd.pdf
>>
>> The section is indeed called "Processor State After Reset" which is
>> clearly not great for the purposes of this discussion, but the important
>> part is "Table 9-1. IA-32 and Intel 64 Processor States Following
>> Power-up, Reset, or INIT", which I believe illustrates the processor
>> states we were talking about.
> 
> I did not question the existence of this description in the manual. What
> I continue to question is the presence of something talking about
> _virtual_ CPU state. You pointing me to hardware state descriptions
> won't change my view that the state of an offline vCPU (note the v!)
> is simply undefined, and hence querying it makes no sense.

Fair enough, if we're making this ontological distrinction between
physical and virtual CPUs, and further state that what applies to one
does not necessarily apply to the other I can't argue otherwise. Our
perspective on this was that the latter would be modelled after the former.

In that case, we'll try to set errno to something specific for the
caller for the "VCPU offline" case, to at least be able to know for sure
that we're dealing with that case and not some other error condition
(such as being out of bounds with the VCPU index).

Would maybe EBUSY be appropriate?

>> Indeed. What we've missed initially is that there were two parts to it:
>> the one that got in with the series (the not pausing the whole domain if
>> not strictly necessary) and the query part.
> 
> Which is a good sign that from (almost) the very beginning this should
> have been separate patches.

Never argued otherwise, agreed.


Thanks,
Razvan

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

Re: Save paused cpu ctx

[Jan Beulich]

>>> On 19.09.18 at 16:38, <rcojocaru@bitdefender.com> wrote:
>>>>> All we want to do is to be able to query the state of any VCPU in the
>>>>> valid range of VCPUs assigned to the domain, online or not. We believe
>>>>> being able to query them is reasonable, and the SDM states that they do
>>>>> have a state (whatever it happens to be: the init state, after reset, etc.).
>>>>
>>>> I didn't know the SDM stated anything about offline vCPU-s. There's
>>>> (according to my way of looking at things) no bare hardware equivalent
>>>> to this state, which means whatever the SDM says is not applicable.
>>>
>>> Please see page 311:
>>>
>>> https://software.intel.com/sites/default/files/managed/a4/60/325384-sdm-vol- 
> 
>>> 3abcd.pdf
>>>
>>> The section is indeed called "Processor State After Reset" which is
>>> clearly not great for the purposes of this discussion, but the important
>>> part is "Table 9-1. IA-32 and Intel 64 Processor States Following
>>> Power-up, Reset, or INIT", which I believe illustrates the processor
>>> states we were talking about.
>> 
>> I did not question the existence of this description in the manual. What
>> I continue to question is the presence of something talking about
>> _virtual_ CPU state. You pointing me to hardware state descriptions
>> won't change my view that the state of an offline vCPU (note the v!)
>> is simply undefined, and hence querying it makes no sense.
> 
> Fair enough, if we're making this ontological distrinction between
> physical and virtual CPUs, and further state that what applies to one
> does not necessarily apply to the other I can't argue otherwise. Our
> perspective on this was that the latter would be modelled after the former.
> 
> In that case, we'll try to set errno to something specific for the
> caller for the "VCPU offline" case, to at least be able to know for sure
> that we're dealing with that case and not some other error condition
> (such as being out of bounds with the VCPU index).
> 
> Would maybe EBUSY be appropriate?

I'd keep ENOENT for "no such vCPU" and use ENODATA for "vCPU offline".

Jan



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