| Message ID | 1454950682-9459-2-git-send-email-czuzu@bitdefender.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 08/02/16 16:57, Corneliu ZUZU wrote: > X86-side hvm.c is @ arch/x86/hvm/hvm.c. To maintain arm<->x86 symmetry, > also move arch/arm/hvm.c to arch/arm/hvm/hvm.c. > > Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com> For future reference, constructing your patches with -M (detect renames) makes reviews of patches like this far easier. While you are editing this file, please put a local variable block on the bottom of the file. See the final section of CODING_STYLE in the root. ~Andrew
On 2/8/2016 7:04 PM, Andrew Cooper wrote: > On 08/02/16 16:57, Corneliu ZUZU wrote: >> X86-side hvm.c is @ arch/x86/hvm/hvm.c. To maintain arm<->x86 symmetry, >> also move arch/arm/hvm.c to arch/arm/hvm/hvm.c. >> >> Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com> > For future reference, constructing your patches with -M (detect renames) > makes reviews of patches like this far easier. > > While you are editing this file, please put a local variable block on > the bottom of the file. See the final section of CODING_STYLE in the root. > > ~Andrew > I'm really sorry, I forgot, I was actually *counting* on that option, wanted to use it as -M40% actually. And I really don't get why git malformed the introductory message. Since the diffs would indeed look *much* better w/ the -M option and I should also add the variable block @ the end of that file (which was originally missing) would it be advised to resend this series? Corneliu.
On 08/02/16 17:12, Corneliu ZUZU wrote: > On 2/8/2016 7:04 PM, Andrew Cooper wrote: >> On 08/02/16 16:57, Corneliu ZUZU wrote: >>> X86-side hvm.c is @ arch/x86/hvm/hvm.c. To maintain arm<->x86 symmetry, >>> also move arch/arm/hvm.c to arch/arm/hvm/hvm.c. >>> >>> Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com> >> For future reference, constructing your patches with -M (detect renames) >> makes reviews of patches like this far easier. >> >> While you are editing this file, please put a local variable block on >> the bottom of the file. See the final section of CODING_STYLE in the >> root. >> >> ~Andrew >> > I'm really sorry, I forgot, I was actually *counting* on that option, > wanted to use it as -M40% > actually. And I really don't get why git malformed the introductory > message. > Since the diffs would indeed look *much* better w/ the -M option and I > should also add > the variable block @ the end of that file (which was originally > missing) would it be advised to > resend this series? I would wait for some other review first. There are some useful comments to be given even with the series like this. ~Andrew
On Mon, 8 Feb 2016, Corneliu ZUZU wrote: > X86-side hvm.c is @ arch/x86/hvm/hvm.c. To maintain arm<->x86 symmetry, > also move arch/arm/hvm.c to arch/arm/hvm/hvm.c. Why are we doing this? These are not header files, their paths don't necessarily need to be the same and xen/arch/x86/hvm/hvm.c is very different from xen/arch/arm/hvm.c. Please state the reason more clearly. > Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com> > --- > xen/arch/arm/Makefile | 2 +- > xen/arch/arm/hvm.c | 67 ----------------------------------------------- > xen/arch/arm/hvm/Makefile | 1 + > xen/arch/arm/hvm/hvm.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 68 insertions(+), 68 deletions(-) > delete mode 100644 xen/arch/arm/hvm.c > create mode 100644 xen/arch/arm/hvm/Makefile > create mode 100644 xen/arch/arm/hvm/hvm.c > > diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile > index 1783912..22f1c75 100644 > --- a/xen/arch/arm/Makefile > +++ b/xen/arch/arm/Makefile > @@ -1,6 +1,7 @@ > subdir-$(CONFIG_ARM_32) += arm32 > subdir-$(CONFIG_ARM_64) += arm64 > subdir-y += platforms > +subdir-y += hvm > subdir-$(CONFIG_ARM_64) += efi > > obj-$(EARLY_PRINTK) += early_printk.o > @@ -34,7 +35,6 @@ obj-y += vgic.o vgic-v2.o > obj-$(CONFIG_ARM_64) += vgic-v3.o > obj-y += vtimer.o > obj-y += vuart.o > -obj-y += hvm.o > obj-y += device.o > obj-y += decode.o > obj-y += processor.o > diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c > deleted file mode 100644 > index 5fd0753..0000000 > --- a/xen/arch/arm/hvm.c > +++ /dev/null > @@ -1,67 +0,0 @@ > -#include <xen/config.h> > -#include <xen/init.h> > -#include <xen/lib.h> > -#include <xen/errno.h> > -#include <xen/guest_access.h> > -#include <xen/sched.h> > - > -#include <xsm/xsm.h> > - > -#include <public/xen.h> > -#include <public/hvm/params.h> > -#include <public/hvm/hvm_op.h> > - > -#include <asm/hypercall.h> > - > -long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg) > - > -{ > - long rc = 0; > - > - switch ( op ) > - { > - case HVMOP_set_param: > - case HVMOP_get_param: > - { > - struct xen_hvm_param a; > - struct domain *d; > - > - if ( copy_from_guest(&a, arg, 1) ) > - return -EFAULT; > - > - if ( a.index >= HVM_NR_PARAMS ) > - return -EINVAL; > - > - d = rcu_lock_domain_by_any_id(a.domid); > - if ( d == NULL ) > - return -ESRCH; > - > - rc = xsm_hvm_param(XSM_TARGET, d, op); > - if ( rc ) > - goto param_fail; > - > - if ( op == HVMOP_set_param ) > - { > - d->arch.hvm_domain.params[a.index] = a.value; > - } > - else > - { > - a.value = d->arch.hvm_domain.params[a.index]; > - rc = copy_to_guest(arg, &a, 1) ? -EFAULT : 0; > - } > - > - param_fail: > - rcu_unlock_domain(d); > - break; > - } > - > - default: > - { > - gdprintk(XENLOG_DEBUG, "HVMOP op=%lu: not implemented\n", op); > - rc = -ENOSYS; > - break; > - } > - } > - > - return rc; > -} > diff --git a/xen/arch/arm/hvm/Makefile b/xen/arch/arm/hvm/Makefile > new file mode 100644 > index 0000000..6ee4054 > --- /dev/null > +++ b/xen/arch/arm/hvm/Makefile > @@ -0,0 +1 @@ > +obj-y += hvm.o > diff --git a/xen/arch/arm/hvm/hvm.c b/xen/arch/arm/hvm/hvm.c > new file mode 100644 > index 0000000..1ae681f > --- /dev/null > +++ b/xen/arch/arm/hvm/hvm.c > @@ -0,0 +1,66 @@ > +#include <xen/config.h> > +#include <xen/init.h> > +#include <xen/lib.h> > +#include <xen/errno.h> > +#include <xen/guest_access.h> > +#include <xen/sched.h> > + > +#include <xsm/xsm.h> > + > +#include <public/xen.h> > +#include <public/hvm/params.h> > +#include <public/hvm/hvm_op.h> > + > +#include <asm/hypercall.h> > + > +long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg) > +{ > + long rc = 0; > + > + switch ( op ) > + { > + case HVMOP_set_param: > + case HVMOP_get_param: > + { > + struct xen_hvm_param a; > + struct domain *d; > + > + if ( copy_from_guest(&a, arg, 1) ) > + return -EFAULT; > + > + if ( a.index >= HVM_NR_PARAMS ) > + return -EINVAL; > + > + d = rcu_lock_domain_by_any_id(a.domid); > + if ( d == NULL ) > + return -ESRCH; > + > + rc = xsm_hvm_param(XSM_TARGET, d, op); > + if ( rc ) > + goto param_fail; > + > + if ( op == HVMOP_set_param ) > + { > + d->arch.hvm_domain.params[a.index] = a.value; > + } > + else > + { > + a.value = d->arch.hvm_domain.params[a.index]; > + rc = copy_to_guest(arg, &a, 1) ? -EFAULT : 0; > + } > + > + param_fail: > + rcu_unlock_domain(d); > + break; > + } > + > + default: > + { > + gdprintk(XENLOG_DEBUG, "HVMOP op=%lu: not implemented\n", op); > + rc = -ENOSYS; > + break; > + } > + } > + > + return rc; > +} > -- > 2.5.0 >
On 2/9/2016 1:03 PM, Stefano Stabellini wrote: > On Mon, 8 Feb 2016, Corneliu ZUZU wrote: >> X86-side hvm.c is @ arch/x86/hvm/hvm.c. To maintain arm<->x86 symmetry, >> also move arch/arm/hvm.c to arch/arm/hvm/hvm.c. > Why are we doing this? These are not header files, their paths don't > necessarily need to be the same and xen/arch/x86/hvm/hvm.c is very > different from xen/arch/arm/hvm.c. > > Please state the reason more clearly. > > >> Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com> >> --- >> xen/arch/arm/Makefile | 2 +- >> xen/arch/arm/hvm.c | 67 ----------------------------------------------- >> xen/arch/arm/hvm/Makefile | 1 + >> xen/arch/arm/hvm/hvm.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++ >> Because the ARM side hvm.c currently exists solely to add an implementation for do_hvm_op, which on x86 is @ arch/x86/hvm/hvm.c. I presume the ARM hvm.c got its name from the X86 file, so I thought a symmetry between the two was intended from the start. Also, the hvm directory was created to separate hvm-specific code, which is the case w/ do_hvm_op on any arch. Corneliu.
>>> On 09.02.16 at 12:28, <czuzu@bitdefender.com> wrote: > On 2/9/2016 1:03 PM, Stefano Stabellini wrote: >> On Mon, 8 Feb 2016, Corneliu ZUZU wrote: >>> X86-side hvm.c is @ arch/x86/hvm/hvm.c. To maintain arm<->x86 symmetry, >>> also move arch/arm/hvm.c to arch/arm/hvm/hvm.c. >> Why are we doing this? These are not header files, their paths don't >> necessarily need to be the same and xen/arch/x86/hvm/hvm.c is very >> different from xen/arch/arm/hvm.c. >> >> Please state the reason more clearly. >> >> >>> Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com> >>> --- >>> xen/arch/arm/Makefile | 2 +- >>> xen/arch/arm/hvm.c | 67 ----------------------------------------------- >>> xen/arch/arm/hvm/Makefile | 1 + >>> xen/arch/arm/hvm/hvm.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++ >>> > > Because the ARM side hvm.c currently exists solely to add an implementation > for > do_hvm_op, which on x86 is @ arch/x86/hvm/hvm.c. I presume the ARM hvm.c got > its name > from the X86 file, so I thought a symmetry between the two was intended from > the start. > Also, the hvm directory was created to separate hvm-specific code, which is > the case w/ > do_hvm_op on any arch. While I'm not an ARM maintainer, this change still strikes me as odd (or a change for the change's sake). A directory with just one file in it (and - afaict - no current perspective to gain more) is just pointless. In fact it's usually the other way around: When a file grows (or would grow) too large, a similarly named subdirectory gets introduced with the contents "scattered" across multiple files in that directory. Jan
On Tue, 9 Feb 2016, Jan Beulich wrote: > >>> On 09.02.16 at 12:28, <czuzu@bitdefender.com> wrote: > > On 2/9/2016 1:03 PM, Stefano Stabellini wrote: > >> On Mon, 8 Feb 2016, Corneliu ZUZU wrote: > >>> X86-side hvm.c is @ arch/x86/hvm/hvm.c. To maintain arm<->x86 symmetry, > >>> also move arch/arm/hvm.c to arch/arm/hvm/hvm.c. > >> Why are we doing this? These are not header files, their paths don't > >> necessarily need to be the same and xen/arch/x86/hvm/hvm.c is very > >> different from xen/arch/arm/hvm.c. > >> > >> Please state the reason more clearly. > >> > >> > >>> Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com> > >>> --- > >>> xen/arch/arm/Makefile | 2 +- > >>> xen/arch/arm/hvm.c | 67 ----------------------------------------------- > >>> xen/arch/arm/hvm/Makefile | 1 + > >>> xen/arch/arm/hvm/hvm.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++ > >>> > > > > Because the ARM side hvm.c currently exists solely to add an implementation > > for > > do_hvm_op, which on x86 is @ arch/x86/hvm/hvm.c. I presume the ARM hvm.c got > > its name > > from the X86 file, so I thought a symmetry between the two was intended from > > the start. > > Also, the hvm directory was created to separate hvm-specific code, which is > > the case w/ > > do_hvm_op on any arch. > > While I'm not an ARM maintainer, this change still strikes me as odd > (or a change for the change's sake). A directory with just one file > in it (and - afaict - no current perspective to gain more) is just > pointless. In fact it's usually the other way around: When a file > grows (or would grow) too large, a similarly named subdirectory > gets introduced with the contents "scattered" across multiple files > in that directory. That's exactly what I thought.
On 2/9/2016 1:55 PM, Jan Beulich wrote: >>>> On 09.02.16 at 12:28, <czuzu@bitdefender.com> wrote: >> On 2/9/2016 1:03 PM, Stefano Stabellini wrote: >>> On Mon, 8 Feb 2016, Corneliu ZUZU wrote: >>>> X86-side hvm.c is @ arch/x86/hvm/hvm.c. To maintain arm<->x86 symmetry, >>>> also move arch/arm/hvm.c to arch/arm/hvm/hvm.c. >>> Why are we doing this? These are not header files, their paths don't >>> necessarily need to be the same and xen/arch/x86/hvm/hvm.c is very >>> different from xen/arch/arm/hvm.c. >>> >>> Please state the reason more clearly. >>> >>> >>>> Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com> >>>> --- >>>> xen/arch/arm/Makefile | 2 +- >>>> xen/arch/arm/hvm.c | 67 ----------------------------------------------- >>>> xen/arch/arm/hvm/Makefile | 1 + >>>> xen/arch/arm/hvm/hvm.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++ >>>> >> Because the ARM side hvm.c currently exists solely to add an implementation >> for >> do_hvm_op, which on x86 is @ arch/x86/hvm/hvm.c. I presume the ARM hvm.c got >> its name >> from the X86 file, so I thought a symmetry between the two was intended from >> the start. >> Also, the hvm directory was created to separate hvm-specific code, which is >> the case w/ >> do_hvm_op on any arch. > While I'm not an ARM maintainer, this change still strikes me as odd > (or a change for the change's sake). A directory with just one file > in it (and - afaict - no current perspective to gain more) is just > pointless. In fact it's usually the other way around: When a file > grows (or would grow) too large, a similarly named subdirectory > gets introduced with the contents "scattered" across multiple files > in that directory. > > Jan There are already directories w/ just one/a few files in them, even small (e.g. common/gcov/gcov.c). IMHO no harm is done if a file is put in its proper directory even before it grows too large. This way one can find the file more easily, future additions are more visibly encouraged to also be separated in that directory when it makes sense, symmetry between arch directories remains intact (=> easier to compare between code for different arches/find equivalent files between them). But I am not a Xen maintainer, I'm only a contributor so I can only suggest :). If ARM maintainers (e.g. Tamas) feel the same, I will move the file back. Corneliu.
On Tue, Feb 9, 2016 at 5:32 AM, Corneliu ZUZU <czuzu@bitdefender.com> wrote: > On 2/9/2016 1:55 PM, Jan Beulich wrote: > >> On 09.02.16 at 12:28, <czuzu@bitdefender.com> wrote: >>>>> >>>> On 2/9/2016 1:03 PM, Stefano Stabellini wrote: >>> >>>> On Mon, 8 Feb 2016, Corneliu ZUZU wrote: >>>> >>>>> X86-side hvm.c is @ arch/x86/hvm/hvm.c. To maintain arm<->x86 symmetry, >>>>> also move arch/arm/hvm.c to arch/arm/hvm/hvm.c. >>>>> >>>> Why are we doing this? These are not header files, their paths don't >>>> necessarily need to be the same and xen/arch/x86/hvm/hvm.c is very >>>> different from xen/arch/arm/hvm.c. >>>> >>>> Please state the reason more clearly. >>>> >>>> >>>> Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com> >>>>> --- >>>>> xen/arch/arm/Makefile | 2 +- >>>>> xen/arch/arm/hvm.c | 67 >>>>> ----------------------------------------------- >>>>> xen/arch/arm/hvm/Makefile | 1 + >>>>> xen/arch/arm/hvm/hvm.c | 66 >>>>> ++++++++++++++++++++++++++++++++++++++++++++++ >>>>> >>>>> Because the ARM side hvm.c currently exists solely to add an >>> implementation >>> for >>> do_hvm_op, which on x86 is @ arch/x86/hvm/hvm.c. I presume the ARM hvm.c >>> got >>> its name >>> from the X86 file, so I thought a symmetry between the two was intended >>> from >>> the start. >>> Also, the hvm directory was created to separate hvm-specific code, which >>> is >>> the case w/ >>> do_hvm_op on any arch. >>> >> While I'm not an ARM maintainer, this change still strikes me as odd >> (or a change for the change's sake). A directory with just one file >> in it (and - afaict - no current perspective to gain more) is just >> pointless. In fact it's usually the other way around: When a file >> grows (or would grow) too large, a similarly named subdirectory >> gets introduced with the contents "scattered" across multiple files >> in that directory. >> >> Jan >> > > There are already directories w/ just one/a few files in them, even small > (e.g. common/gcov/gcov.c). > IMHO no harm is done if a file is put in its proper directory even before > it grows too large. > This way one can find the file more easily, future additions are more > visibly encouraged to > also be separated in that directory when it makes sense, symmetry between > arch directories remains > intact (=> easier to compare between code for different arches/find > equivalent files between them). > > But I am not a Xen maintainer, I'm only a contributor so I can only > suggest :). > If ARM maintainers (e.g. Tamas) feel the same, I will move the file back. > I don't really have a strong opinion about this either way, so if the others prefer it staying as it is then there is no point moving it. Tamas
On 2/9/2016 7:40 PM, Tamas K Lengyel wrote: > > > On Tue, Feb 9, 2016 at 5:32 AM, Corneliu ZUZU <czuzu@bitdefender.com > <mailto:czuzu@bitdefender.com>> wrote: > > There are already directories w/ just one/a few files in them, > even small (e.g. common/gcov/gcov.c). > IMHO no harm is done if a file is put in its proper directory even > before it grows too large. > This way one can find the file more easily, future additions are > more visibly encouraged to > also be separated in that directory when it makes sense, symmetry > between arch directories remains > intact (=> easier to compare between code for different > arches/find equivalent files between them). > > But I am not a Xen maintainer, I'm only a contributor so I can > only suggest :). > If ARM maintainers (e.g. Tamas) feel the same, I will move the > file back. > > > I don't really have a strong opinion about this either way, so if the > others prefer it staying as it is then there is no point moving it. > > Tamas > Ok, will do, thanks for the feedback. Corneliu.
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile index 1783912..22f1c75 100644 --- a/xen/arch/arm/Makefile +++ b/xen/arch/arm/Makefile @@ -1,6 +1,7 @@ subdir-$(CONFIG_ARM_32) += arm32 subdir-$(CONFIG_ARM_64) += arm64 subdir-y += platforms +subdir-y += hvm subdir-$(CONFIG_ARM_64) += efi obj-$(EARLY_PRINTK) += early_printk.o @@ -34,7 +35,6 @@ obj-y += vgic.o vgic-v2.o obj-$(CONFIG_ARM_64) += vgic-v3.o obj-y += vtimer.o obj-y += vuart.o -obj-y += hvm.o obj-y += device.o obj-y += decode.o obj-y += processor.o diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c deleted file mode 100644 index 5fd0753..0000000 --- a/xen/arch/arm/hvm.c +++ /dev/null @@ -1,67 +0,0 @@ -#include <xen/config.h> -#include <xen/init.h> -#include <xen/lib.h> -#include <xen/errno.h> -#include <xen/guest_access.h> -#include <xen/sched.h> - -#include <xsm/xsm.h> - -#include <public/xen.h> -#include <public/hvm/params.h> -#include <public/hvm/hvm_op.h> - -#include <asm/hypercall.h> - -long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg) - -{ - long rc = 0; - - switch ( op ) - { - case HVMOP_set_param: - case HVMOP_get_param: - { - struct xen_hvm_param a; - struct domain *d; - - if ( copy_from_guest(&a, arg, 1) ) - return -EFAULT; - - if ( a.index >= HVM_NR_PARAMS ) - return -EINVAL; - - d = rcu_lock_domain_by_any_id(a.domid); - if ( d == NULL ) - return -ESRCH; - - rc = xsm_hvm_param(XSM_TARGET, d, op); - if ( rc ) - goto param_fail; - - if ( op == HVMOP_set_param ) - { - d->arch.hvm_domain.params[a.index] = a.value; - } - else - { - a.value = d->arch.hvm_domain.params[a.index]; - rc = copy_to_guest(arg, &a, 1) ? -EFAULT : 0; - } - - param_fail: - rcu_unlock_domain(d); - break; - } - - default: - { - gdprintk(XENLOG_DEBUG, "HVMOP op=%lu: not implemented\n", op); - rc = -ENOSYS; - break; - } - } - - return rc; -} diff --git a/xen/arch/arm/hvm/Makefile b/xen/arch/arm/hvm/Makefile new file mode 100644 index 0000000..6ee4054 --- /dev/null +++ b/xen/arch/arm/hvm/Makefile @@ -0,0 +1 @@ +obj-y += hvm.o diff --git a/xen/arch/arm/hvm/hvm.c b/xen/arch/arm/hvm/hvm.c new file mode 100644 index 0000000..1ae681f --- /dev/null +++ b/xen/arch/arm/hvm/hvm.c @@ -0,0 +1,66 @@ +#include <xen/config.h> +#include <xen/init.h> +#include <xen/lib.h> +#include <xen/errno.h> +#include <xen/guest_access.h> +#include <xen/sched.h> + +#include <xsm/xsm.h> + +#include <public/xen.h> +#include <public/hvm/params.h> +#include <public/hvm/hvm_op.h> + +#include <asm/hypercall.h> + +long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg) +{ + long rc = 0; + + switch ( op ) + { + case HVMOP_set_param: + case HVMOP_get_param: + { + struct xen_hvm_param a; + struct domain *d; + + if ( copy_from_guest(&a, arg, 1) ) + return -EFAULT; + + if ( a.index >= HVM_NR_PARAMS ) + return -EINVAL; + + d = rcu_lock_domain_by_any_id(a.domid); + if ( d == NULL ) + return -ESRCH; + + rc = xsm_hvm_param(XSM_TARGET, d, op); + if ( rc ) + goto param_fail; + + if ( op == HVMOP_set_param ) + { + d->arch.hvm_domain.params[a.index] = a.value; + } + else + { + a.value = d->arch.hvm_domain.params[a.index]; + rc = copy_to_guest(arg, &a, 1) ? -EFAULT : 0; + } + + param_fail: + rcu_unlock_domain(d); + break; + } + + default: + { + gdprintk(XENLOG_DEBUG, "HVMOP op=%lu: not implemented\n", op); + rc = -ENOSYS; + break; + } + } + + return rc; +}
X86-side hvm.c is @ arch/x86/hvm/hvm.c. To maintain arm<->x86 symmetry, also move arch/arm/hvm.c to arch/arm/hvm/hvm.c. Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com> --- xen/arch/arm/Makefile | 2 +- xen/arch/arm/hvm.c | 67 ----------------------------------------------- xen/arch/arm/hvm/Makefile | 1 + xen/arch/arm/hvm/hvm.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 68 insertions(+), 68 deletions(-) delete mode 100644 xen/arch/arm/hvm.c create mode 100644 xen/arch/arm/hvm/Makefile create mode 100644 xen/arch/arm/hvm/hvm.c