Message ID | 1493888417-20803-2-git-send-email-rcojocaru@bitdefender.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
>>> On 04.05.17 at 11:00, <rcojocaru@bitdefender.com> wrote: > Created arch/x86/hvm/vm_event.c and include/asm-x86/hvm/vm_event.h, > where HVM-specific vm_event-related code will live. This cleans up > hvm_do_resume() and ensures that the vm_event maintainers are > responsible for changes to that code. > > Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com> > Acked-by: Tamas K Lengyel <tamas@tklengyel.com> Acked-by: Jan Beulich <jbeulich@suse.com> albeit I wonder ... > +void hvm_vm_event_do_resume(struct vcpu *v) > +{ > + struct monitor_write_data *w; > + > + if ( likely(!v->arch.vm_event) ) > + return; ... whether this now wouldn't better be an ASSERT(). Jan
On 05/04/17 12:11, Jan Beulich wrote: >>>> On 04.05.17 at 11:00, <rcojocaru@bitdefender.com> wrote: >> Created arch/x86/hvm/vm_event.c and include/asm-x86/hvm/vm_event.h, >> where HVM-specific vm_event-related code will live. This cleans up >> hvm_do_resume() and ensures that the vm_event maintainers are >> responsible for changes to that code. >> >> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com> >> Acked-by: Tamas K Lengyel <tamas@tklengyel.com> > > Acked-by: Jan Beulich <jbeulich@suse.com> > albeit I wonder ... > >> +void hvm_vm_event_do_resume(struct vcpu *v) >> +{ >> + struct monitor_write_data *w; >> + >> + if ( likely(!v->arch.vm_event) ) >> + return; > > ... whether this now wouldn't better be an ASSERT(). I have no objections (can this be done on commit or should I re-send V4?). Thanks, Razvan
>>> On 04.05.17 at 11:14, <rcojocaru@bitdefender.com> wrote: > On 05/04/17 12:11, Jan Beulich wrote: >>>>> On 04.05.17 at 11:00, <rcojocaru@bitdefender.com> wrote: >>> Created arch/x86/hvm/vm_event.c and include/asm-x86/hvm/vm_event.h, >>> where HVM-specific vm_event-related code will live. This cleans up >>> hvm_do_resume() and ensures that the vm_event maintainers are >>> responsible for changes to that code. >>> >>> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com> >>> Acked-by: Tamas K Lengyel <tamas@tklengyel.com> >> >> Acked-by: Jan Beulich <jbeulich@suse.com> >> albeit I wonder ... >> >>> +void hvm_vm_event_do_resume(struct vcpu *v) >>> +{ >>> + struct monitor_write_data *w; >>> + >>> + if ( likely(!v->arch.vm_event) ) >>> + return; >> >> ... whether this now wouldn't better be an ASSERT(). > > I have no objections (can this be done on commit or should I re-send V4?). Let's first see what Tamas thinks. If he agrees, I see not problem doing the adjustment while committing. Jan
On Thu, May 4, 2017 at 5:22 AM, Jan Beulich <JBeulich@suse.com> wrote: >>>> On 04.05.17 at 11:14, <rcojocaru@bitdefender.com> wrote: >> On 05/04/17 12:11, Jan Beulich wrote: >>>>>> On 04.05.17 at 11:00, <rcojocaru@bitdefender.com> wrote: >>>> Created arch/x86/hvm/vm_event.c and include/asm-x86/hvm/vm_event.h, >>>> where HVM-specific vm_event-related code will live. This cleans up >>>> hvm_do_resume() and ensures that the vm_event maintainers are >>>> responsible for changes to that code. >>>> >>>> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com> >>>> Acked-by: Tamas K Lengyel <tamas@tklengyel.com> >>> >>> Acked-by: Jan Beulich <jbeulich@suse.com> >>> albeit I wonder ... >>> >>>> +void hvm_vm_event_do_resume(struct vcpu *v) >>>> +{ >>>> + struct monitor_write_data *w; >>>> + >>>> + if ( likely(!v->arch.vm_event) ) >>>> + return; >>> >>> ... whether this now wouldn't better be an ASSERT(). >> >> I have no objections (can this be done on commit or should I re-send V4?). > > Let's first see what Tamas thinks. If he agrees, I see not problem > doing the adjustment while committing. I'm not quite sure how converting that to an ASSERT would work. It looks fine to me as is tbh. Tamas
On 05/04/17 17:57, Tamas K Lengyel wrote: > On Thu, May 4, 2017 at 5:22 AM, Jan Beulich <JBeulich@suse.com> wrote: >>>>> On 04.05.17 at 11:14, <rcojocaru@bitdefender.com> wrote: >>> On 05/04/17 12:11, Jan Beulich wrote: >>>>>>> On 04.05.17 at 11:00, <rcojocaru@bitdefender.com> wrote: >>>>> Created arch/x86/hvm/vm_event.c and include/asm-x86/hvm/vm_event.h, >>>>> where HVM-specific vm_event-related code will live. This cleans up >>>>> hvm_do_resume() and ensures that the vm_event maintainers are >>>>> responsible for changes to that code. >>>>> >>>>> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com> >>>>> Acked-by: Tamas K Lengyel <tamas@tklengyel.com> >>>> >>>> Acked-by: Jan Beulich <jbeulich@suse.com> >>>> albeit I wonder ... >>>> >>>>> +void hvm_vm_event_do_resume(struct vcpu *v) >>>>> +{ >>>>> + struct monitor_write_data *w; >>>>> + >>>>> + if ( likely(!v->arch.vm_event) ) >>>>> + return; >>>> >>>> ... whether this now wouldn't better be an ASSERT(). >>> >>> I have no objections (can this be done on commit or should I re-send V4?). >> >> Let's first see what Tamas thinks. If he agrees, I see not problem >> doing the adjustment while committing. > > I'm not quite sure how converting that to an ASSERT would work. It > looks fine to me as is tbh. I think Jan means that, since currently the only caller is hvm_do_resume() where there's already that check now (to avoid the call), we could here simply replace the if() with ASSERT(v->arch.vm_event). I could be wrong. :) Thanks, Razvan
On Thu, May 4, 2017 at 11:17 AM, Razvan Cojocaru <rcojocaru@bitdefender.com> wrote: > On 05/04/17 17:57, Tamas K Lengyel wrote: >> On Thu, May 4, 2017 at 5:22 AM, Jan Beulich <JBeulich@suse.com> wrote: >>>>>> On 04.05.17 at 11:14, <rcojocaru@bitdefender.com> wrote: >>>> On 05/04/17 12:11, Jan Beulich wrote: >>>>>>>> On 04.05.17 at 11:00, <rcojocaru@bitdefender.com> wrote: >>>>>> Created arch/x86/hvm/vm_event.c and include/asm-x86/hvm/vm_event.h, >>>>>> where HVM-specific vm_event-related code will live. This cleans up >>>>>> hvm_do_resume() and ensures that the vm_event maintainers are >>>>>> responsible for changes to that code. >>>>>> >>>>>> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com> >>>>>> Acked-by: Tamas K Lengyel <tamas@tklengyel.com> >>>>> >>>>> Acked-by: Jan Beulich <jbeulich@suse.com> >>>>> albeit I wonder ... >>>>> >>>>>> +void hvm_vm_event_do_resume(struct vcpu *v) >>>>>> +{ >>>>>> + struct monitor_write_data *w; >>>>>> + >>>>>> + if ( likely(!v->arch.vm_event) ) >>>>>> + return; >>>>> >>>>> ... whether this now wouldn't better be an ASSERT(). >>>> >>>> I have no objections (can this be done on commit or should I re-send V4?). >>> >>> Let's first see what Tamas thinks. If he agrees, I see not problem >>> doing the adjustment while committing. >> >> I'm not quite sure how converting that to an ASSERT would work. It >> looks fine to me as is tbh. > > I think Jan means that, since currently the only caller is > hvm_do_resume() where there's already that check now (to avoid the > call), we could here simply replace the if() with > ASSERT(v->arch.vm_event). I could be wrong. :) > Ah OK, yea that would be fine. Tamas
>>> On 04.05.17 at 17:17, <rcojocaru@bitdefender.com> wrote: > On 05/04/17 17:57, Tamas K Lengyel wrote: >> On Thu, May 4, 2017 at 5:22 AM, Jan Beulich <JBeulich@suse.com> wrote: >>>>>> On 04.05.17 at 11:14, <rcojocaru@bitdefender.com> wrote: >>>> On 05/04/17 12:11, Jan Beulich wrote: >>>>>>>> On 04.05.17 at 11:00, <rcojocaru@bitdefender.com> wrote: >>>>>> Created arch/x86/hvm/vm_event.c and include/asm-x86/hvm/vm_event.h, >>>>>> where HVM-specific vm_event-related code will live. This cleans up >>>>>> hvm_do_resume() and ensures that the vm_event maintainers are >>>>>> responsible for changes to that code. >>>>>> >>>>>> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com> >>>>>> Acked-by: Tamas K Lengyel <tamas@tklengyel.com> >>>>> >>>>> Acked-by: Jan Beulich <jbeulich@suse.com> >>>>> albeit I wonder ... >>>>> >>>>>> +void hvm_vm_event_do_resume(struct vcpu *v) >>>>>> +{ >>>>>> + struct monitor_write_data *w; >>>>>> + >>>>>> + if ( likely(!v->arch.vm_event) ) >>>>>> + return; >>>>> >>>>> ... whether this now wouldn't better be an ASSERT(). >>>> >>>> I have no objections (can this be done on commit or should I re-send V4?). >>> >>> Let's first see what Tamas thinks. If he agrees, I see not problem >>> doing the adjustment while committing. >> >> I'm not quite sure how converting that to an ASSERT would work. It >> looks fine to me as is tbh. > > I think Jan means that, since currently the only caller is > hvm_do_resume() where there's already that check now (to avoid the > call), we could here simply replace the if() with > ASSERT(v->arch.vm_event). I could be wrong. :) You aren't - that's precisely my reasoning. Jan
On Thu, May 4, 2017 at 11:37 AM, Jan Beulich <JBeulich@suse.com> wrote: >>>> On 04.05.17 at 17:17, <rcojocaru@bitdefender.com> wrote: >> On 05/04/17 17:57, Tamas K Lengyel wrote: >>> On Thu, May 4, 2017 at 5:22 AM, Jan Beulich <JBeulich@suse.com> wrote: >>>>>>> On 04.05.17 at 11:14, <rcojocaru@bitdefender.com> wrote: >>>>> On 05/04/17 12:11, Jan Beulich wrote: >>>>>>>>> On 04.05.17 at 11:00, <rcojocaru@bitdefender.com> wrote: >>>>>>> Created arch/x86/hvm/vm_event.c and include/asm-x86/hvm/vm_event.h, >>>>>>> where HVM-specific vm_event-related code will live. This cleans up >>>>>>> hvm_do_resume() and ensures that the vm_event maintainers are >>>>>>> responsible for changes to that code. >>>>>>> >>>>>>> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com> >>>>>>> Acked-by: Tamas K Lengyel <tamas@tklengyel.com> >>>>>> >>>>>> Acked-by: Jan Beulich <jbeulich@suse.com> >>>>>> albeit I wonder ... >>>>>> >>>>>>> +void hvm_vm_event_do_resume(struct vcpu *v) >>>>>>> +{ >>>>>>> + struct monitor_write_data *w; >>>>>>> + >>>>>>> + if ( likely(!v->arch.vm_event) ) >>>>>>> + return; >>>>>> >>>>>> ... whether this now wouldn't better be an ASSERT(). >>>>> >>>>> I have no objections (can this be done on commit or should I re-send V4?). >>>> >>>> Let's first see what Tamas thinks. If he agrees, I see not problem >>>> doing the adjustment while committing. >>> >>> I'm not quite sure how converting that to an ASSERT would work. It >>> looks fine to me as is tbh. >> >> I think Jan means that, since currently the only caller is >> hvm_do_resume() where there's already that check now (to avoid the >> call), we could here simply replace the if() with >> ASSERT(v->arch.vm_event). I could be wrong. :) > > You aren't - that's precisely my reasoning. So if we are changing this to an ASSERT here then a check needs to be added on the caller site. That would work for me. Tamas
>>> On 05.05.17 at 16:42, <tamas@tklengyel.com> wrote: > On Thu, May 4, 2017 at 11:37 AM, Jan Beulich <JBeulich@suse.com> wrote: >>>>> On 04.05.17 at 17:17, <rcojocaru@bitdefender.com> wrote: >>> On 05/04/17 17:57, Tamas K Lengyel wrote: >>>> On Thu, May 4, 2017 at 5:22 AM, Jan Beulich <JBeulich@suse.com> wrote: >>>>>>>> On 04.05.17 at 11:14, <rcojocaru@bitdefender.com> wrote: >>>>>> On 05/04/17 12:11, Jan Beulich wrote: >>>>>>>>>> On 04.05.17 at 11:00, <rcojocaru@bitdefender.com> wrote: >>>>>>>> Created arch/x86/hvm/vm_event.c and include/asm-x86/hvm/vm_event.h, >>>>>>>> where HVM-specific vm_event-related code will live. This cleans up >>>>>>>> hvm_do_resume() and ensures that the vm_event maintainers are >>>>>>>> responsible for changes to that code. >>>>>>>> >>>>>>>> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com> >>>>>>>> Acked-by: Tamas K Lengyel <tamas@tklengyel.com> >>>>>>> >>>>>>> Acked-by: Jan Beulich <jbeulich@suse.com> >>>>>>> albeit I wonder ... >>>>>>> >>>>>>>> +void hvm_vm_event_do_resume(struct vcpu *v) >>>>>>>> +{ >>>>>>>> + struct monitor_write_data *w; >>>>>>>> + >>>>>>>> + if ( likely(!v->arch.vm_event) ) >>>>>>>> + return; >>>>>>> >>>>>>> ... whether this now wouldn't better be an ASSERT(). >>>>>> >>>>>> I have no objections (can this be done on commit or should I re-send V4?). >>>>> >>>>> Let's first see what Tamas thinks. If he agrees, I see not problem >>>>> doing the adjustment while committing. >>>> >>>> I'm not quite sure how converting that to an ASSERT would work. It >>>> looks fine to me as is tbh. >>> >>> I think Jan means that, since currently the only caller is >>> hvm_do_resume() where there's already that check now (to avoid the >>> call), we could here simply replace the if() with >>> ASSERT(v->arch.vm_event). I could be wrong. :) >> >> You aren't - that's precisely my reasoning. > > So if we are changing this to an ASSERT here then a check needs to be > added on the caller site. That would work for me. I don't follow - the reason I did ask for converting the if() here was because (upon my request) a check in the caller has been added (or actually, is being kept from the original code instead of deleting it) in this version. Jan
On Fri, May 5, 2017 at 10:47 AM, Jan Beulich <JBeulich@suse.com> wrote: >>>> On 05.05.17 at 16:42, <tamas@tklengyel.com> wrote: >> On Thu, May 4, 2017 at 11:37 AM, Jan Beulich <JBeulich@suse.com> wrote: >>>>>> On 04.05.17 at 17:17, <rcojocaru@bitdefender.com> wrote: >>>> On 05/04/17 17:57, Tamas K Lengyel wrote: >>>>> On Thu, May 4, 2017 at 5:22 AM, Jan Beulich <JBeulich@suse.com> wrote: >>>>>>>>> On 04.05.17 at 11:14, <rcojocaru@bitdefender.com> wrote: >>>>>>> On 05/04/17 12:11, Jan Beulich wrote: >>>>>>>>>>> On 04.05.17 at 11:00, <rcojocaru@bitdefender.com> wrote: >>>>>>>>> Created arch/x86/hvm/vm_event.c and include/asm-x86/hvm/vm_event.h, >>>>>>>>> where HVM-specific vm_event-related code will live. This cleans up >>>>>>>>> hvm_do_resume() and ensures that the vm_event maintainers are >>>>>>>>> responsible for changes to that code. >>>>>>>>> >>>>>>>>> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com> >>>>>>>>> Acked-by: Tamas K Lengyel <tamas@tklengyel.com> >>>>>>>> >>>>>>>> Acked-by: Jan Beulich <jbeulich@suse.com> >>>>>>>> albeit I wonder ... >>>>>>>> >>>>>>>>> +void hvm_vm_event_do_resume(struct vcpu *v) >>>>>>>>> +{ >>>>>>>>> + struct monitor_write_data *w; >>>>>>>>> + >>>>>>>>> + if ( likely(!v->arch.vm_event) ) >>>>>>>>> + return; >>>>>>>> >>>>>>>> ... whether this now wouldn't better be an ASSERT(). >>>>>>> >>>>>>> I have no objections (can this be done on commit or should I re-send V4?). >>>>>> >>>>>> Let's first see what Tamas thinks. If he agrees, I see not problem >>>>>> doing the adjustment while committing. >>>>> >>>>> I'm not quite sure how converting that to an ASSERT would work. It >>>>> looks fine to me as is tbh. >>>> >>>> I think Jan means that, since currently the only caller is >>>> hvm_do_resume() where there's already that check now (to avoid the >>>> call), we could here simply replace the if() with >>>> ASSERT(v->arch.vm_event). I could be wrong. :) >>> >>> You aren't - that's precisely my reasoning. >> >> So if we are changing this to an ASSERT here then a check needs to be >> added on the caller site. That would work for me. > > I don't follow - the reason I did ask for converting the if() here > was because (upon my request) a check in the caller has been > added (or actually, is being kept from the original code instead > of deleting it) in this version. If there is already a check in the caller, then just go ahead and convert this to an ASSERT. Tamas
>>> On 04.05.17 at 11:00, <rcojocaru@bitdefender.com> wrote: > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -404,6 +404,7 @@ S: Supported > F: tools/tests/xen-access > F: xen/arch/*/monitor.c > F: xen/arch/*/vm_event.c > +F: xen/arch/*/hvm/vm_event.c > F: xen/arch/arm/mem_access.c > F: xen/arch/x86/mm/mem_access.c > F: xen/arch/x86/hvm/monitor.c > @@ -413,6 +414,7 @@ F: xen/common/vm_event.c > F: xen/include/*/mem_access.h > F: xen/include/*/monitor.h > F: xen/include/*/vm_event.h > +F: xen/include/*/hvm/vm_event.h > F: xen/include/asm-x86/hvm/monitor.h Btw., I've noticed only now that these additions would better be x86-specific, just like their hvm/monitor.[ch] counterparts. I intend to adjust this while committing. Jan
On 05/08/17 15:44, Jan Beulich wrote: >>>> On 04.05.17 at 11:00, <rcojocaru@bitdefender.com> wrote: >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -404,6 +404,7 @@ S: Supported >> F: tools/tests/xen-access >> F: xen/arch/*/monitor.c >> F: xen/arch/*/vm_event.c >> +F: xen/arch/*/hvm/vm_event.c >> F: xen/arch/arm/mem_access.c >> F: xen/arch/x86/mm/mem_access.c >> F: xen/arch/x86/hvm/monitor.c >> @@ -413,6 +414,7 @@ F: xen/common/vm_event.c >> F: xen/include/*/mem_access.h >> F: xen/include/*/monitor.h >> F: xen/include/*/vm_event.h >> +F: xen/include/*/hvm/vm_event.h >> F: xen/include/asm-x86/hvm/monitor.h > > Btw., I've noticed only now that these additions would better be > x86-specific, just like their hvm/monitor.[ch] counterparts. I intend > to adjust this while committing. Fair enough. Thanks, Razvan
diff --git a/MAINTAINERS b/MAINTAINERS index c345a50..10863bc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -404,6 +404,7 @@ S: Supported F: tools/tests/xen-access F: xen/arch/*/monitor.c F: xen/arch/*/vm_event.c +F: xen/arch/*/hvm/vm_event.c F: xen/arch/arm/mem_access.c F: xen/arch/x86/mm/mem_access.c F: xen/arch/x86/hvm/monitor.c @@ -413,6 +414,7 @@ F: xen/common/vm_event.c F: xen/include/*/mem_access.h F: xen/include/*/monitor.h F: xen/include/*/vm_event.h +F: xen/include/*/hvm/vm_event.h F: xen/include/asm-x86/hvm/monitor.h VTPM diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile index 0a3d0f4..02f0add 100644 --- a/xen/arch/x86/hvm/Makefile +++ b/xen/arch/x86/hvm/Makefile @@ -24,6 +24,7 @@ obj-y += stdvga.o obj-y += vioapic.o obj-y += viridian.o obj-y += vlapic.o +obj-y += vm_event.o obj-y += vmsi.o obj-y += vpic.o obj-y += vpt.o diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index a441955..81691e2 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -34,7 +34,6 @@ #include <xen/wait.h> #include <xen/mem_access.h> #include <xen/rangeset.h> -#include <xen/vm_event.h> #include <xen/monitor.h> #include <xen/warning.h> #include <asm/shadow.h> @@ -61,6 +60,7 @@ #include <asm/hvm/nestedhvm.h> #include <asm/hvm/monitor.h> #include <asm/hvm/ioreq.h> +#include <asm/hvm/vm_event.h> #include <asm/altp2m.h> #include <asm/mtrr.h> #include <asm/apic.h> @@ -484,66 +484,7 @@ void hvm_do_resume(struct vcpu *v) return; if ( unlikely(v->arch.vm_event) ) - { - struct monitor_write_data *w = &v->arch.vm_event->write_data; - - if ( unlikely(v->arch.vm_event->emulate_flags) ) - { - enum emul_kind kind = EMUL_KIND_NORMAL; - - /* - * Please observ the order here to match the flag descriptions - * provided in public/vm_event.h - */ - if ( v->arch.vm_event->emulate_flags & - VM_EVENT_FLAG_SET_EMUL_READ_DATA ) - kind = EMUL_KIND_SET_CONTEXT_DATA; - else if ( v->arch.vm_event->emulate_flags & - VM_EVENT_FLAG_EMULATE_NOWRITE ) - kind = EMUL_KIND_NOWRITE; - else if ( v->arch.vm_event->emulate_flags & - VM_EVENT_FLAG_SET_EMUL_INSN_DATA ) - kind = EMUL_KIND_SET_CONTEXT_INSN; - - hvm_emulate_one_vm_event(kind, TRAP_invalid_op, - X86_EVENT_NO_EC); - - v->arch.vm_event->emulate_flags = 0; - } - - if ( w->do_write.msr ) - { - if ( hvm_msr_write_intercept(w->msr, w->value, 0) == - X86EMUL_EXCEPTION ) - hvm_inject_hw_exception(TRAP_gp_fault, 0); - - w->do_write.msr = 0; - } - - if ( w->do_write.cr0 ) - { - if ( hvm_set_cr0(w->cr0, 0) == X86EMUL_EXCEPTION ) - hvm_inject_hw_exception(TRAP_gp_fault, 0); - - w->do_write.cr0 = 0; - } - - if ( w->do_write.cr4 ) - { - if ( hvm_set_cr4(w->cr4, 0) == X86EMUL_EXCEPTION ) - hvm_inject_hw_exception(TRAP_gp_fault, 0); - - w->do_write.cr4 = 0; - } - - if ( w->do_write.cr3 ) - { - if ( hvm_set_cr3(w->cr3, 0) == X86EMUL_EXCEPTION ) - hvm_inject_hw_exception(TRAP_gp_fault, 0); - - w->do_write.cr3 = 0; - } - } + hvm_vm_event_do_resume(v); /* Inject pending hw/sw event */ if ( v->arch.hvm_vcpu.inject_event.vector >= 0 ) diff --git a/xen/arch/x86/hvm/vm_event.c b/xen/arch/x86/hvm/vm_event.c new file mode 100644 index 0000000..1934556 --- /dev/null +++ b/xen/arch/x86/hvm/vm_event.c @@ -0,0 +1,103 @@ +/* + * arch/x86/hvm/vm_event.c + * + * HVM vm_event handling routines + * + * Copyright (c) 2004, Intel Corporation. + * Copyright (c) 2005, International Business Machines Corporation. + * Copyright (c) 2008, Citrix Systems, Inc. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public + * License v2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public + * License along with this program; If not, see <http://www.gnu.org/licenses/>. + */ + +#include <xen/sched.h> +#include <xen/vm_event.h> +#include <asm/hvm/support.h> +#include <asm/vm_event.h> + +void hvm_vm_event_do_resume(struct vcpu *v) +{ + struct monitor_write_data *w; + + if ( likely(!v->arch.vm_event) ) + return; + + w = &v->arch.vm_event->write_data; + + if ( unlikely(v->arch.vm_event->emulate_flags) ) + { + enum emul_kind kind = EMUL_KIND_NORMAL; + + /* + * Please observe the order here to match the flag descriptions + * provided in public/vm_event.h + */ + if ( v->arch.vm_event->emulate_flags & + VM_EVENT_FLAG_SET_EMUL_READ_DATA ) + kind = EMUL_KIND_SET_CONTEXT_DATA; + else if ( v->arch.vm_event->emulate_flags & + VM_EVENT_FLAG_EMULATE_NOWRITE ) + kind = EMUL_KIND_NOWRITE; + else if ( v->arch.vm_event->emulate_flags & + VM_EVENT_FLAG_SET_EMUL_INSN_DATA ) + kind = EMUL_KIND_SET_CONTEXT_INSN; + + hvm_emulate_one_vm_event(kind, TRAP_invalid_op, + X86_EVENT_NO_EC); + + v->arch.vm_event->emulate_flags = 0; + } + + if ( unlikely(w->do_write.cr0) ) + { + if ( hvm_set_cr0(w->cr0, 0) == X86EMUL_EXCEPTION ) + hvm_inject_hw_exception(TRAP_gp_fault, 0); + + w->do_write.cr0 = 0; + } + + if ( unlikely(w->do_write.cr4) ) + { + if ( hvm_set_cr4(w->cr4, 0) == X86EMUL_EXCEPTION ) + hvm_inject_hw_exception(TRAP_gp_fault, 0); + + w->do_write.cr4 = 0; + } + + if ( unlikely(w->do_write.cr3) ) + { + if ( hvm_set_cr3(w->cr3, 0) == X86EMUL_EXCEPTION ) + hvm_inject_hw_exception(TRAP_gp_fault, 0); + + w->do_write.cr3 = 0; + } + + if ( unlikely(w->do_write.msr) ) + { + if ( hvm_msr_write_intercept(w->msr, w->value, 0) == + X86EMUL_EXCEPTION ) + hvm_inject_hw_exception(TRAP_gp_fault, 0); + + w->do_write.msr = 0; + } +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/include/asm-x86/hvm/vm_event.h b/xen/include/asm-x86/hvm/vm_event.h new file mode 100644 index 0000000..28cb07c --- /dev/null +++ b/xen/include/asm-x86/hvm/vm_event.h @@ -0,0 +1,34 @@ +/* + * include/asm-x86/hvm/vm_event.h + * + * Hardware virtual machine vm_event abstractions. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms and conditions of the GNU General Public License, + * version 2, as published by the Free Software Foundation. + * + * This program is distributed in the hope it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + * more details. + * + * You should have received a copy of the GNU General Public License along with + * this program; If not, see <http://www.gnu.org/licenses/>. + */ + +#ifndef __ASM_X86_HVM_VM_EVENT_H__ +#define __ASM_X86_HVM_VM_EVENT_H__ + +void hvm_vm_event_do_resume(struct vcpu *v); + +#endif /* __ASM_X86_HVM_VM_EVENT_H__ */ + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */