* Save paused cpu ctx @ 2018-09-19 8:21 Isaila Alexandru 2018-09-19 8:41 ` Roger Pau Monné 2018-09-19 9:01 ` Jan Beulich 0 siblings, 2 replies; 13+ messages in thread From: Isaila Alexandru @ 2018-09-19 8:21 UTC (permalink / raw) To: jbeulich; +Cc: andrew.cooper3, xen-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Save paused cpu ctx 2018-09-19 8:21 Save paused cpu ctx Isaila Alexandru @ 2018-09-19 8:41 ` Roger Pau Monné 2018-09-19 9:02 ` Isaila Alexandru 2018-09-19 9:01 ` Jan Beulich 1 sibling, 1 reply; 13+ messages in thread From: Roger Pau Monné @ 2018-09-19 8:41 UTC (permalink / raw) To: Isaila Alexandru; +Cc: andrew.cooper3, jbeulich, xen-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Save paused cpu ctx 2018-09-19 8:41 ` Roger Pau Monné @ 2018-09-19 9:02 ` Isaila Alexandru 2018-09-19 9:10 ` Roger Pau Monné 0 siblings, 1 reply; 13+ messages in thread From: Isaila Alexandru @ 2018-09-19 9:02 UTC (permalink / raw) To: Roger Pau Monné; +Cc: andrew.cooper3, jbeulich, xen-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Save paused cpu ctx 2018-09-19 9:02 ` Isaila Alexandru @ 2018-09-19 9:10 ` Roger Pau Monné 0 siblings, 0 replies; 13+ messages in thread From: Roger Pau Monné @ 2018-09-19 9:10 UTC (permalink / raw) To: Isaila Alexandru; +Cc: andrew.cooper3, jbeulich, xen-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Save paused cpu ctx 2018-09-19 8:21 Save paused cpu ctx Isaila Alexandru 2018-09-19 8:41 ` Roger Pau Monné @ 2018-09-19 9:01 ` Jan Beulich 2018-09-19 9:19 ` Isaila Alexandru 1 sibling, 1 reply; 13+ messages in thread From: Jan Beulich @ 2018-09-19 9:01 UTC (permalink / raw) To: aisaila; +Cc: Andrew Cooper, xen-devel >>> 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Save paused cpu ctx 2018-09-19 9:01 ` Jan Beulich @ 2018-09-19 9:19 ` Isaila Alexandru 2018-09-19 9:39 ` Jan Beulich 0 siblings, 1 reply; 13+ messages in thread From: Isaila Alexandru @ 2018-09-19 9:19 UTC (permalink / raw) To: Jan Beulich; +Cc: Andrew Cooper, xen-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Save paused cpu ctx 2018-09-19 9:19 ` Isaila Alexandru @ 2018-09-19 9:39 ` Jan Beulich 2018-09-19 11:11 ` Razvan Cojocaru 0 siblings, 1 reply; 13+ messages in thread From: Jan Beulich @ 2018-09-19 9:39 UTC (permalink / raw) To: aisaila; +Cc: Andrew Cooper, xen-devel >>> 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Save paused cpu ctx 2018-09-19 9:39 ` Jan Beulich @ 2018-09-19 11:11 ` Razvan Cojocaru 2018-09-19 12:13 ` Jan Beulich 0 siblings, 1 reply; 13+ messages in thread From: Razvan Cojocaru @ 2018-09-19 11:11 UTC (permalink / raw) To: Jan Beulich, aisaila; +Cc: Andrew Cooper, xen-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Save paused cpu ctx 2018-09-19 11:11 ` Razvan Cojocaru @ 2018-09-19 12:13 ` Jan Beulich 2018-09-19 12:37 ` Razvan Cojocaru 0 siblings, 1 reply; 13+ messages in thread From: Jan Beulich @ 2018-09-19 12:13 UTC (permalink / raw) To: aisaila, Razvan Cojocaru; +Cc: Andrew Cooper, xen-devel >>> 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Save paused cpu ctx 2018-09-19 12:13 ` Jan Beulich @ 2018-09-19 12:37 ` Razvan Cojocaru 2018-09-19 14:19 ` Jan Beulich 0 siblings, 1 reply; 13+ messages in thread From: Razvan Cojocaru @ 2018-09-19 12:37 UTC (permalink / raw) To: Jan Beulich, aisaila; +Cc: Andrew Cooper, xen-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Save paused cpu ctx 2018-09-19 12:37 ` Razvan Cojocaru @ 2018-09-19 14:19 ` Jan Beulich 2018-09-19 14:38 ` Razvan Cojocaru 0 siblings, 1 reply; 13+ messages in thread From: Jan Beulich @ 2018-09-19 14:19 UTC (permalink / raw) To: Razvan Cojocaru; +Cc: aisaila, Andrew Cooper, xen-devel >>> 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Save paused cpu ctx 2018-09-19 14:19 ` Jan Beulich @ 2018-09-19 14:38 ` Razvan Cojocaru 2018-09-19 14:44 ` Jan Beulich 0 siblings, 1 reply; 13+ messages in thread From: Razvan Cojocaru @ 2018-09-19 14:38 UTC (permalink / raw) To: Jan Beulich; +Cc: aisaila, Andrew Cooper, xen-devel >>>> 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Save paused cpu ctx 2018-09-19 14:38 ` Razvan Cojocaru @ 2018-09-19 14:44 ` Jan Beulich 0 siblings, 0 replies; 13+ messages in thread From: Jan Beulich @ 2018-09-19 14:44 UTC (permalink / raw) To: Razvan Cojocaru; +Cc: aisaila, Andrew Cooper, xen-devel >>> 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2018-09-19 14:44 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-09-19 8:21 Save paused cpu ctx Isaila Alexandru 2018-09-19 8:41 ` Roger Pau Monné 2018-09-19 9:02 ` Isaila Alexandru 2018-09-19 9:10 ` Roger Pau Monné 2018-09-19 9:01 ` Jan Beulich 2018-09-19 9:19 ` Isaila Alexandru 2018-09-19 9:39 ` Jan Beulich 2018-09-19 11:11 ` Razvan Cojocaru 2018-09-19 12:13 ` Jan Beulich 2018-09-19 12:37 ` Razvan Cojocaru 2018-09-19 14:19 ` Jan Beulich 2018-09-19 14:38 ` Razvan Cojocaru 2018-09-19 14:44 ` Jan Beulich
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.