[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Save paused cpu ctx



>>>> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.