* Foreign VCPU register change? @ 2012-08-23 17:25 Cutter 409 2012-08-23 17:34 ` Keir Fraser 0 siblings, 1 reply; 8+ messages in thread From: Cutter 409 @ 2012-08-23 17:25 UTC (permalink / raw) To: xen-devel [-- Attachment #1.1: Type: text/plain, Size: 687 bytes --] With Xen-4.1.2: I'm trying to change a register value in a paused vmx vcpu. The general process looks like this: 1. Some vmexit calls vcpu_sleep_nosync(v) on the vcpu 2. From dom0, I issue a domctl to change a register via v->arch.guest_context.user_reg, then vcpu_wake(v) However, the guest register does not seem to be changed when I do it this way. Is there something I need to do to mark the registers as "dirty" ? Is there a way to force the foreign vcpu to update the changed registers? Or maybe I just have to change the registers somewhere else? I've tried directly using vmcs_enter(v), __vmwrite(), vmcs_exit(v) also, but that doesn't seem to make a change either. Thanks! [-- Attachment #1.2: Type: text/html, Size: 759 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Foreign VCPU register change? 2012-08-23 17:25 Foreign VCPU register change? Cutter 409 @ 2012-08-23 17:34 ` Keir Fraser 2012-08-23 17:37 ` Cutter 409 0 siblings, 1 reply; 8+ messages in thread From: Keir Fraser @ 2012-08-23 17:34 UTC (permalink / raw) To: Cutter 409, xen-devel On 23/08/2012 18:25, "Cutter 409" <cutter409@gmail.com> wrote: > With Xen-4.1.2: > > I'm trying to change a register value in a paused vmx vcpu. The general > process looks like this: > > 1. Some vmexit calls vcpu_sleep_nosync(v) on the vcpu > 2. From dom0, I issue a domctl to change a register via > v->arch.guest_context.user_reg, then vcpu_wake(v) Which domctl? From dom0 userspace you can use the libxc functions xc_vcpu_getcontext() and xc_vcpu_setcontext() to read/modify register state. You can read the libxc sources to see what hypercall these map to, if you don't want to use libxc for any reason. -- Keir > However, the guest register does not seem to be changed when I do it this way. > Is there something I need to do to mark the registers as "dirty" ? Is there a > way to force the foreign vcpu to update the changed registers? Or maybe I just > have to change the registers somewhere else? > > I've tried directly using vmcs_enter(v), __vmwrite(), vmcs_exit(v) also, but > that doesn't seem to make a change either. > > Thanks! > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Foreign VCPU register change? 2012-08-23 17:34 ` Keir Fraser @ 2012-08-23 17:37 ` Cutter 409 2012-08-23 17:49 ` Keir Fraser 0 siblings, 1 reply; 8+ messages in thread From: Cutter 409 @ 2012-08-23 17:37 UTC (permalink / raw) To: xen-devel [-- Attachment #1.1: Type: text/plain, Size: 1568 bytes --] I'm making the register change directly from the hypervisor, inside of the domctl code. It's a custom domctl that I've added. I'll look into what setcontext does after it modifies the register values, though. Thank you! On Thu, Aug 23, 2012 at 1:34 PM, Keir Fraser <keir.xen@gmail.com> wrote: > On 23/08/2012 18:25, "Cutter 409" <cutter409@gmail.com> wrote: > > > With Xen-4.1.2: > > > > I'm trying to change a register value in a paused vmx vcpu. The general > > process looks like this: > > > > 1. Some vmexit calls vcpu_sleep_nosync(v) on the vcpu > > 2. From dom0, I issue a domctl to change a register via > > v->arch.guest_context.user_reg, then vcpu_wake(v) > > Which domctl? From dom0 userspace you can use the libxc functions > xc_vcpu_getcontext() and xc_vcpu_setcontext() to read/modify register > state. > > You can read the libxc sources to see what hypercall these map to, if you > don't want to use libxc for any reason. > > -- Keir > > > However, the guest register does not seem to be changed when I do it > this way. > > Is there something I need to do to mark the registers as "dirty" ? Is > there a > > way to force the foreign vcpu to update the changed registers? Or maybe > I just > > have to change the registers somewhere else? > > > > I've tried directly using vmcs_enter(v), __vmwrite(), vmcs_exit(v) also, > but > > that doesn't seem to make a change either. > > > > Thanks! > > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > > > [-- Attachment #1.2: Type: text/html, Size: 2264 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Foreign VCPU register change? 2012-08-23 17:37 ` Cutter 409 @ 2012-08-23 17:49 ` Keir Fraser 2012-08-23 17:54 ` Keir Fraser 0 siblings, 1 reply; 8+ messages in thread From: Keir Fraser @ 2012-08-23 17:49 UTC (permalink / raw) To: Cutter 409, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 2526 bytes --] FWIW I would expect your approach to basically work. Except... Does your domctl do a vcpu_pause()/vcpu_unpause() on the vcpu? This will ensure that the vcpu is both fully de-scheduled, and all of its register state is synced back into its vcpu structure. Otherwise you race the vcpu_sleep_nosync() -- and that¹s assuming you also have a reason for that vcpu to sleep (e.g., non-zero pause counter), else vcpu_sleep_*() operations do nothing! In short, your problems are almost certainly something to do with the subtleties of actually putting a vcpu properly to sleep. -- Keir On 23/08/2012 18:37, "Cutter 409" <cutter409@gmail.com> wrote: > I'm making the register change directly from the hypervisor, inside of the > domctl code. > > It's a custom domctl that I've added. I'll look into what setcontext does > after it modifies the register values, though. > > Thank you! > > On Thu, Aug 23, 2012 at 1:34 PM, Keir Fraser <keir.xen@gmail.com> wrote: >> On 23/08/2012 18:25, "Cutter 409" <cutter409@gmail.com> wrote: >> >>> > With Xen-4.1.2: >>> > >>> > I'm trying to change a register value in a paused vmx vcpu. The general >>> > process looks like this: >>> > >>> > 1. Some vmexit calls vcpu_sleep_nosync(v) on the vcpu >>> > 2. From dom0, I issue a domctl to change a register via >>> > v->arch.guest_context.user_reg, then vcpu_wake(v) >> >> Which domctl? From dom0 userspace you can use the libxc functions >> xc_vcpu_getcontext() and xc_vcpu_setcontext() to read/modify register state. >> >> You can read the libxc sources to see what hypercall these map to, if you >> don't want to use libxc for any reason. >> >> -- Keir >> >>> > However, the guest register does not seem to be changed when I do it this >>> way. >>> > Is there something I need to do to mark the registers as "dirty" ? Is >>> there a >>> > way to force the foreign vcpu to update the changed registers? Or maybe I >>> just >>> > have to change the registers somewhere else? >>> > >>> > I've tried directly using vmcs_enter(v), __vmwrite(), vmcs_exit(v) also, >>> but >>> > that doesn't seem to make a change either. >>> > >>> > Thanks! >>> > >>> > >>> > >>> > _______________________________________________ >>> > Xen-devel mailing list >>> > Xen-devel@lists.xen.org >>> > http://lists.xen.org/xen-devel >> >> > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel [-- Attachment #1.2: Type: text/html, Size: 3660 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Foreign VCPU register change? 2012-08-23 17:49 ` Keir Fraser @ 2012-08-23 17:54 ` Keir Fraser 2012-08-23 18:11 ` Cutter 409 0 siblings, 1 reply; 8+ messages in thread From: Keir Fraser @ 2012-08-23 17:54 UTC (permalink / raw) To: Cutter 409, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 2907 bytes --] So, for example, one possibly-valid scheme would be: - vcpu_pause_nosync() from the vmexit handler - vcpu_sleep_sync() at the start of the domctl - vcpu_unpause() at the end of the domctl HTH, Keir On 23/08/2012 18:49, "Keir Fraser" <keir.xen@gmail.com> wrote: > FWIW I would expect your approach to basically work. > > Except... Does your domctl do a vcpu_pause()/vcpu_unpause() on the vcpu? This > will ensure that the vcpu is both fully de-scheduled, and all of its register > state is synced back into its vcpu structure. > > Otherwise you race the vcpu_sleep_nosync() -- and that¹s assuming you also > have a reason for that vcpu to sleep (e.g., non-zero pause counter), else > vcpu_sleep_*() operations do nothing! > > In short, your problems are almost certainly something to do with the > subtleties of actually putting a vcpu properly to sleep. > > -- Keir > > > On 23/08/2012 18:37, "Cutter 409" <cutter409@gmail.com> wrote: > >> I'm making the register change directly from the hypervisor, inside of the >> domctl code. >> >> It's a custom domctl that I've added. I'll look into what setcontext does >> after it modifies the register values, though. >> >> Thank you! >> >> On Thu, Aug 23, 2012 at 1:34 PM, Keir Fraser <keir.xen@gmail.com> wrote: >>> On 23/08/2012 18:25, "Cutter 409" <cutter409@gmail.com> wrote: >>> >>>> > With Xen-4.1.2: >>>> > >>>> > I'm trying to change a register value in a paused vmx vcpu. The general >>>> > process looks like this: >>>> > >>>> > 1. Some vmexit calls vcpu_sleep_nosync(v) on the vcpu >>>> > 2. From dom0, I issue a domctl to change a register via >>>> > v->arch.guest_context.user_reg, then vcpu_wake(v) >>> >>> Which domctl? From dom0 userspace you can use the libxc functions >>> xc_vcpu_getcontext() and xc_vcpu_setcontext() to read/modify register state. >>> >>> You can read the libxc sources to see what hypercall these map to, if you >>> don't want to use libxc for any reason. >>> >>> -- Keir >>> >>>> > However, the guest register does not seem to be changed when I do it this >>>> way. >>>> > Is there something I need to do to mark the registers as "dirty" ? Is >>>> there a >>>> > way to force the foreign vcpu to update the changed registers? Or maybe I >>>> just >>>> > have to change the registers somewhere else? >>>> > >>>> > I've tried directly using vmcs_enter(v), __vmwrite(), vmcs_exit(v) also, >>>> but >>>> > that doesn't seem to make a change either. >>>> > >>>> > Thanks! >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > Xen-devel mailing list >>>> > Xen-devel@lists.xen.org >>>> > http://lists.xen.org/xen-devel >>> >>> >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > [-- Attachment #1.2: Type: text/html, Size: 4278 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Foreign VCPU register change? 2012-08-23 17:54 ` Keir Fraser @ 2012-08-23 18:11 ` Cutter 409 2012-08-23 18:55 ` Keir Fraser 0 siblings, 1 reply; 8+ messages in thread From: Cutter 409 @ 2012-08-23 18:11 UTC (permalink / raw) To: xen-devel [-- Attachment #1.1: Type: text/plain, Size: 3572 bytes --] Thanks, Keir! I've spent so much time trying to track down this problem, even before I realized the registers weren't actually changing. You have no idea how helpful that was. Before I tried your example, I just wrapped the code to change the register in vcpu_pause() and vcpu_unpause(), which worked. Everything seems fine at the moment, is there any reason I should still change the vcpu_sleep_nosync() to vcpu_pause_nosync()? It seems to actually work as is; I'm setting a bit in v->pause_flags before I call it, then clear the bit before I wake it. I also tried pause_nosync on vmexit, unpause after domctl, but that didn't work. Thanks again! On Thu, Aug 23, 2012 at 1:54 PM, Keir Fraser <keir.xen@gmail.com> wrote: > So, for example, one possibly-valid scheme would be: > > - vcpu_pause_nosync() from the vmexit handler > > - vcpu_sleep_sync() at the start of the domctl > - vcpu_unpause() at the end of the domctl > > HTH, > Keir > > > > On 23/08/2012 18:49, "Keir Fraser" <keir.xen@gmail.com> wrote: > > FWIW I would expect your approach to basically work. > > Except... Does your domctl do a vcpu_pause()/vcpu_unpause() on the vcpu? > This will ensure that the vcpu is both fully de-scheduled, and all of its > register state is synced back into its vcpu structure. > > Otherwise you race the vcpu_sleep_nosync() -- and that’s assuming you also > have a reason for that vcpu to sleep (e.g., non-zero pause counter), else > vcpu_sleep_*() operations do nothing! > > In short, your problems are almost certainly something to do with the > subtleties of actually putting a vcpu properly to sleep. > > -- Keir > > > On 23/08/2012 18:37, "Cutter 409" <cutter409@gmail.com> wrote: > > I'm making the register change directly from the hypervisor, inside of the > domctl code. > > It's a custom domctl that I've added. I'll look into what setcontext does > after it modifies the register values, though. > > Thank you! > > On Thu, Aug 23, 2012 at 1:34 PM, Keir Fraser <keir.xen@gmail.com> wrote: > > On 23/08/2012 18:25, "Cutter 409" <cutter409@gmail.com> wrote: > > > With Xen-4.1.2: > > > > I'm trying to change a register value in a paused vmx vcpu. The general > > process looks like this: > > > > 1. Some vmexit calls vcpu_sleep_nosync(v) on the vcpu > > 2. From dom0, I issue a domctl to change a register via > > v->arch.guest_context.user_reg, then vcpu_wake(v) > > Which domctl? From dom0 userspace you can use the libxc functions > xc_vcpu_getcontext() and xc_vcpu_setcontext() to read/modify register > state. > > You can read the libxc sources to see what hypercall these map to, if you > don't want to use libxc for any reason. > > -- Keir > > > However, the guest register does not seem to be changed when I do it > this way. > > Is there something I need to do to mark the registers as "dirty" ? Is > there a > > way to force the foreign vcpu to update the changed registers? Or maybe > I just > > have to change the registers somewhere else? > > > > I've tried directly using vmcs_enter(v), __vmwrite(), vmcs_exit(v) also, > but > > that doesn't seem to make a change either. > > > > Thanks! > > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > > > > > ------------------------------ > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > > > [-- Attachment #1.2: Type: text/html, Size: 5447 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Foreign VCPU register change? 2012-08-23 18:11 ` Cutter 409 @ 2012-08-23 18:55 ` Keir Fraser 2012-08-23 21:59 ` Cutter 409 0 siblings, 1 reply; 8+ messages in thread From: Keir Fraser @ 2012-08-23 18:55 UTC (permalink / raw) To: Cutter 409, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 5094 bytes --] If you have your own flag in v->pause_flags then indeed you do not need to vcpu_pause_nosync() in the vmexit handler. The best sequence would be: - vmexit handler: set flag in v->pause_flags, then vcpu_sleep_nosync() - domctl entry: vcpu_sleep_sync() - domctl exit: clear flag in v->pause_flags, then vcpu_wake() So that¹s pretty much what you had in the first place, except for the extra vcpu_sleep_sync() on domctl entry. That¹s absolutely critical, and why your pause_nosync on vmexit, unpause after domctl doesn¹t work something is needed on domctl entry to be sure that the vcpu is descheduled and its state is synchronised. Of course the extra machinery of vcpu_pause/unpause is harmless enough, but it¹s not actually necessary here. -- Keir On 23/08/2012 19:11, "Cutter 409" <cutter409@gmail.com> wrote: > Thanks, Keir! > > I've spent so much time trying to track down this problem, even before I > realized the registers weren't actually changing. You have no idea how helpful > that was. > > Before I tried your example, I just wrapped the code to change the register in > vcpu_pause() and vcpu_unpause(), which worked. > > Everything seems fine at the moment, is there any reason I should still change > the vcpu_sleep_nosync() to vcpu_pause_nosync()? It seems to actually work as > is; I'm setting a bit in v->pause_flags before I call it, then clear the bit > before I wake it. I also tried pause_nosync on vmexit, unpause after domctl, > but that didn't work. > > Thanks again! > > > On Thu, Aug 23, 2012 at 1:54 PM, Keir Fraser <keir.xen@gmail.com> wrote: >> So, for example, one possibly-valid scheme would be: >> >> - vcpu_pause_nosync() from the vmexit handler >> >> - vcpu_sleep_sync() at the start of the domctl >> - vcpu_unpause() at the end of the domctl >> >> HTH, >> Keir >> >> >> >> On 23/08/2012 18:49, "Keir Fraser" <keir.xen@gmail.com >> <http://keir.xen@gmail.com> > wrote: >> >>> FWIW I would expect your approach to basically work. >>> >>> Except... Does your domctl do a vcpu_pause()/vcpu_unpause() on the vcpu? >>> This will ensure that the vcpu is both fully de-scheduled, and all of its >>> register state is synced back into its vcpu structure. >>> >>> Otherwise you race the vcpu_sleep_nosync() -- and that¹s assuming you also >>> have a reason for that vcpu to sleep (e.g., non-zero pause counter), else >>> vcpu_sleep_*() operations do nothing! >>> >>> In short, your problems are almost certainly something to do with the >>> subtleties of actually putting a vcpu properly to sleep. >>> >>> -- Keir >>> >>> >>> On 23/08/2012 18:37, "Cutter 409" <cutter409@gmail.com >>> <http://cutter409@gmail.com> > wrote: >>> >>>> I'm making the register change directly from the hypervisor, inside of the >>>> domctl code. >>>> >>>> It's a custom domctl that I've added. I'll look into what setcontext does >>>> after it modifies the register values, though. >>>> >>>> Thank you! >>>> >>>> On Thu, Aug 23, 2012 at 1:34 PM, Keir Fraser <keir.xen@gmail.com >>>> <http://keir.xen@gmail.com> > wrote: >>>>> On 23/08/2012 18:25, "Cutter 409" <cutter409@gmail.com >>>>> <http://cutter409@gmail.com> > wrote: >>>>> >>>>>> > With Xen-4.1.2: >>>>>> > >>>>>> > I'm trying to change a register value in a paused vmx vcpu. The general >>>>>> > process looks like this: >>>>>> > >>>>>> > 1. Some vmexit calls vcpu_sleep_nosync(v) on the vcpu >>>>>> > 2. From dom0, I issue a domctl to change a register via >>>>>> > v->arch.guest_context.user_reg, then vcpu_wake(v) >>>>> >>>>> Which domctl? From dom0 userspace you can use the libxc functions >>>>> xc_vcpu_getcontext() and xc_vcpu_setcontext() to read/modify register >>>>> state. >>>>> >>>>> You can read the libxc sources to see what hypercall these map to, if you >>>>> don't want to use libxc for any reason. >>>>> >>>>> -- Keir >>>>> >>>>>> > However, the guest register does not seem to be changed when I do it >>>>>> this way. >>>>>> > Is there something I need to do to mark the registers as "dirty" ? Is >>>>>> there a >>>>>> > way to force the foreign vcpu to update the changed registers? Or maybe >>>>>> I just >>>>>> > have to change the registers somewhere else? >>>>>> > >>>>>> > I've tried directly using vmcs_enter(v), __vmwrite(), vmcs_exit(v) >>>>>> also, but >>>>>> > that doesn't seem to make a change either. >>>>>> > >>>>>> > Thanks! >>>>>> > >>>>>> > >>>>>> > >>>>>> > _______________________________________________ >>>>>> > Xen-devel mailing list >>>>>> > Xen-devel@lists.xen.org <http://Xen-devel@lists.xen.org> >>>>>> > http://lists.xen.org/xen-devel >>>>> >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Xen-devel mailing list >>>> Xen-devel@lists.xen.org <http://Xen-devel@lists.xen.org> >>>> http://lists.xen.org/xen-devel >>> > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel [-- Attachment #1.2: Type: text/html, Size: 7289 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Foreign VCPU register change? 2012-08-23 18:55 ` Keir Fraser @ 2012-08-23 21:59 ` Cutter 409 0 siblings, 0 replies; 8+ messages in thread From: Cutter 409 @ 2012-08-23 21:59 UTC (permalink / raw) To: xen-devel [-- Attachment #1.1: Type: text/plain, Size: 4995 bytes --] That works perfectly, thank you for the help. On Thu, Aug 23, 2012 at 2:55 PM, Keir Fraser <keir.xen@gmail.com> wrote: > If you have your own flag in v->pause_flags then indeed you do not need > to vcpu_pause_nosync() in the vmexit handler. > > The best sequence would be: > - vmexit handler: set flag in v->pause_flags, then vcpu_sleep_nosync() > - domctl entry: vcpu_sleep_sync() > - domctl exit: clear flag in v->pause_flags, then vcpu_wake() > > So that’s pretty much what you had in the first place, except for the > extra vcpu_sleep_sync() on domctl entry. That’s absolutely critical, and > why your pause_nosync on vmexit, unpause after domctl doesn’t work — * > something* is needed on domctl entry to be sure that the vcpu is > descheduled and its state is synchronised. Of course the extra machinery of > vcpu_pause/unpause is harmless enough, but it’s not actually necessary here. > > -- Keir > > > > On 23/08/2012 19:11, "Cutter 409" <cutter409@gmail.com> wrote: > > Thanks, Keir! > > I've spent so much time trying to track down this problem, even before I > realized the registers weren't actually changing. You have no idea how > helpful that was. > > Before I tried your example, I just wrapped the code to change the > register in vcpu_pause() and vcpu_unpause(), which worked. > > Everything seems fine at the moment, is there any reason I should still > change the vcpu_sleep_nosync() to vcpu_pause_nosync()? It seems to actually > work as is; I'm setting a bit in v->pause_flags before I call it, then > clear the bit before I wake it. I also tried pause_nosync on vmexit, > unpause after domctl, but that didn't work. > > Thanks again! > > > On Thu, Aug 23, 2012 at 1:54 PM, Keir Fraser <keir.xen@gmail.com> wrote: > > So, for example, one possibly-valid scheme would be: > > - vcpu_pause_nosync() from the vmexit handler > > - vcpu_sleep_sync() at the start of the domctl > - vcpu_unpause() at the end of the domctl > > HTH, > Keir > > > > On 23/08/2012 18:49, "Keir Fraser" <keir.xen@gmail.com < > http://keir.xen@gmail.com> > wrote: > > FWIW I would expect your approach to basically work. > > Except... Does your domctl do a vcpu_pause()/vcpu_unpause() on the vcpu? > This will ensure that the vcpu is both fully de-scheduled, and all of its > register state is synced back into its vcpu structure. > > Otherwise you race the vcpu_sleep_nosync() -- and that’s assuming you also > have a reason for that vcpu to sleep (e.g., non-zero pause counter), else > vcpu_sleep_*() operations do nothing! > > In short, your problems are almost certainly something to do with the > subtleties of actually putting a vcpu properly to sleep. > > -- Keir > > > On 23/08/2012 18:37, "Cutter 409" <cutter409@gmail.com < > http://cutter409@gmail.com> > wrote: > > I'm making the register change directly from the hypervisor, inside of the > domctl code. > > It's a custom domctl that I've added. I'll look into what setcontext does > after it modifies the register values, though. > > Thank you! > > On Thu, Aug 23, 2012 at 1:34 PM, Keir Fraser <keir.xen@gmail.com < > http://keir.xen@gmail.com> > wrote: > > On 23/08/2012 18:25, "Cutter 409" <cutter409@gmail.com < > http://cutter409@gmail.com> > wrote: > > > With Xen-4.1.2: > > > > I'm trying to change a register value in a paused vmx vcpu. The general > > process looks like this: > > > > 1. Some vmexit calls vcpu_sleep_nosync(v) on the vcpu > > 2. From dom0, I issue a domctl to change a register via > > v->arch.guest_context.user_reg, then vcpu_wake(v) > > Which domctl? From dom0 userspace you can use the libxc functions > xc_vcpu_getcontext() and xc_vcpu_setcontext() to read/modify register > state. > > You can read the libxc sources to see what hypercall these map to, if you > don't want to use libxc for any reason. > > -- Keir > > > However, the guest register does not seem to be changed when I do it > this way. > > Is there something I need to do to mark the registers as "dirty" ? Is > there a > > way to force the foreign vcpu to update the changed registers? Or maybe > I just > > have to change the registers somewhere else? > > > > I've tried directly using vmcs_enter(v), __vmwrite(), vmcs_exit(v) also, > but > > that doesn't seem to make a change either. > > > > Thanks! > > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org <http://Xen-devel@lists.xen.org> > > http://lists.xen.org/xen-devel > > > > > ------------------------------ > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org <http://Xen-devel@lists.xen.org> > http://lists.xen.org/xen-devel > > > > > ------------------------------ > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > > [-- Attachment #1.2: Type: text/html, Size: 8105 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-08-23 21:59 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-08-23 17:25 Foreign VCPU register change? Cutter 409 2012-08-23 17:34 ` Keir Fraser 2012-08-23 17:37 ` Cutter 409 2012-08-23 17:49 ` Keir Fraser 2012-08-23 17:54 ` Keir Fraser 2012-08-23 18:11 ` Cutter 409 2012-08-23 18:55 ` Keir Fraser 2012-08-23 21:59 ` Cutter 409
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.