diff mbox

[V3,1/2] x86/vm_event: added hvm/vm_event.{h,c}

Message ID 1493888417-20803-2-git-send-email-rcojocaru@bitdefender.com (mailing list archive)
State New, archived
Headers show

Commit Message

Razvan Cojocaru May 4, 2017, 9 a.m. UTC
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>

---
Changes since V2:
 - Added if ( unlikely(v->arch.vm_event) ) before the hvm_do_resume()
   call.
 - Added unlikely()s in hvm_vm_event_do_resume() for the register
   write cases.
 - Moved the copyright lines over from hvm.c.
---
 MAINTAINERS                        |   2 +
 xen/arch/x86/hvm/Makefile          |   1 +
 xen/arch/x86/hvm/hvm.c             |  63 +----------------------
 xen/arch/x86/hvm/vm_event.c        | 103 +++++++++++++++++++++++++++++++++++++
 xen/include/asm-x86/hvm/vm_event.h |  34 ++++++++++++
 5 files changed, 142 insertions(+), 61 deletions(-)
 create mode 100644 xen/arch/x86/hvm/vm_event.c
 create mode 100644 xen/include/asm-x86/hvm/vm_event.h

Comments

Jan Beulich May 4, 2017, 9:11 a.m. UTC | #1
>>> 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
Razvan Cojocaru May 4, 2017, 9:14 a.m. UTC | #2
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
Jan Beulich May 4, 2017, 9:22 a.m. UTC | #3
>>> 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
Tamas K Lengyel May 4, 2017, 2:57 p.m. UTC | #4
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
Razvan Cojocaru May 4, 2017, 3:17 p.m. UTC | #5
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
Tamas K Lengyel May 4, 2017, 3:33 p.m. UTC | #6
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
Jan Beulich May 4, 2017, 3:37 p.m. UTC | #7
>>> 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
Tamas K Lengyel May 5, 2017, 2:42 p.m. UTC | #8
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
Jan Beulich May 5, 2017, 2:47 p.m. UTC | #9
>>> 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
Tamas K Lengyel May 5, 2017, 3:37 p.m. UTC | #10
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
Jan Beulich May 8, 2017, 12:44 p.m. UTC | #11
>>> 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
Razvan Cojocaru May 8, 2017, 12:47 p.m. UTC | #12
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 mbox

Patch

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:
+ */