| Message ID | 1376058613-26400-1-git-send-email-christoffer.dall@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Aug 09, 2013 at 07:30:13AM -0700, Christoffer Dall wrote: > The KVM_HPAGE_DEFINES are a little artificial on ARM, since the huge > page size is statically defined at compile time and there is only a > single huge page size. > > Now when the main kvm code relying on these defines has been moved to > the x86 specific part of the world, we can get rid of these. > > Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> > --- > > [Resending this because the KVM list filter caught the subject of the > previous message due to the letter X] > > arch/arm/include/asm/kvm_host.h | 5 ----- > 1 file changed, 5 deletions(-) > > diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h > index 7d22517..e45a74b 100644 > --- a/arch/arm/include/asm/kvm_host.h > +++ b/arch/arm/include/asm/kvm_host.h > @@ -38,11 +38,6 @@ > > #define KVM_VCPU_MAX_FEATURES 1 > > -/* We don't currently support large pages. */ > -#define KVM_HPAGE_GFN_SHIFT(x) 0 > -#define KVM_NR_PAGE_SIZES 1 With huge page support you do have two different page sizes, but the only code that uses those defines currently is in the x86 shadow mmu code, so I am fine with moving gfn_to_index() into x86 specific code and getting rid of those defines (you will probably need them when you will implement nested HYP mode :)). But can you do it as a separate patch series and remove the defines for all arches? > -#define KVM_PAGES_PER_HPAGE(x) (1UL<<31) > - > #include <kvm/arm_vgic.h> > > struct kvm_vcpu; > -- > 1.7.10.4 > > _______________________________________________ > kvmarm mailing list > kvmarm@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm -- Gleb.
On 25 August 2013 15:05, Gleb Natapov <gleb@redhat.com> wrote: > (you will probably need them when you will implement > nested HYP mode :)). Smiley noted, but this is pretty unlikely since it's not possible to lie to the guest about which mode it's in, so you can't make a guest think it's in Hyp mode. -- PMM
On Sun, Aug 25, 2013 at 03:29:17PM +0100, Peter Maydell wrote: > On 25 August 2013 15:05, Gleb Natapov <gleb@redhat.com> wrote: > > (you will probably need them when you will implement > > nested HYP mode :)). > > Smiley noted, but this is pretty unlikely since it's not possible > to lie to the guest about which mode it's in, so you can't make > a guest think it's in Hyp mode. > I suspected this, but forgot most that I read about Hyp mode by now. Need to refresh my memory ASAP. Is it impossible even with a lot of emulation? Can guest detect that it is not in a Hyp mode without trapping into hypervisor? -- Gleb.
On 25 August 2013 15:48, Gleb Natapov <gleb@redhat.com> wrote: > On Sun, Aug 25, 2013 at 03:29:17PM +0100, Peter Maydell wrote: >> Smiley noted, but this is pretty unlikely since it's not possible >> to lie to the guest about which mode it's in, so you can't make >> a guest think it's in Hyp mode. >> > I suspected this, but forgot most that I read about Hyp mode by now. > Need to refresh my memory ASAP. Is it impossible even with a lot of > emulation? Can guest detect that it is not in a Hyp mode without > trapping into hypervisor? Yes. The current mode is in the the low bits of the CPSR, which is readable without causing a trap. This is just the most obvious roadblock; I bet there are more. If you really had to run Hyp mode code in a VM you probably have to do it by having it all emulated via TCG. -- PMM
On 25.08.2013, at 16:18, Peter Maydell wrote: > On 25 August 2013 15:48, Gleb Natapov <gleb@redhat.com> wrote: >> On Sun, Aug 25, 2013 at 03:29:17PM +0100, Peter Maydell wrote: >>> Smiley noted, but this is pretty unlikely since it's not possible >>> to lie to the guest about which mode it's in, so you can't make >>> a guest think it's in Hyp mode. >>> >> I suspected this, but forgot most that I read about Hyp mode by now. >> Need to refresh my memory ASAP. Is it impossible even with a lot of >> emulation? Can guest detect that it is not in a Hyp mode without >> trapping into hypervisor? > > Yes. The current mode is in the the low bits of the CPSR, which > is readable without causing a trap. This is just the most obvious > roadblock; I bet there are more. If you really had to run Hyp mode > code in a VM you probably have to do it by having it all emulated > via TCG. Or in an in-kernel instruction emulator that we have lying around anyways. For kvm-in-kvm that should be good enough, as we only need to execute a few instructions in HYP mode. Alex
On Sun, Aug 25, 2013 at 04:18:02PM +0100, Peter Maydell wrote: > On 25 August 2013 15:48, Gleb Natapov <gleb@redhat.com> wrote: > > On Sun, Aug 25, 2013 at 03:29:17PM +0100, Peter Maydell wrote: > >> Smiley noted, but this is pretty unlikely since it's not possible > >> to lie to the guest about which mode it's in, so you can't make > >> a guest think it's in Hyp mode. > >> > > I suspected this, but forgot most that I read about Hyp mode by now. > > Need to refresh my memory ASAP. Is it impossible even with a lot of > > emulation? Can guest detect that it is not in a Hyp mode without > > trapping into hypervisor? > > Yes. The current mode is in the the low bits of the CPSR, which > is readable without causing a trap. This is just the most obvious > roadblock; I bet there are more. If you really had to run Hyp mode > code in a VM you probably have to do it by having it all emulated > via TCG. > Or through some highly paravirtualized nested virtualization solution if that is ever relevant. -Christoffer
On Sun, Aug 25, 2013 at 04:27:14PM +0100, Alexander Graf wrote: > > On 25.08.2013, at 16:18, Peter Maydell wrote: > > > On 25 August 2013 15:48, Gleb Natapov <gleb@redhat.com> wrote: > >> On Sun, Aug 25, 2013 at 03:29:17PM +0100, Peter Maydell wrote: > >>> Smiley noted, but this is pretty unlikely since it's not possible > >>> to lie to the guest about which mode it's in, so you can't make > >>> a guest think it's in Hyp mode. > >>> > >> I suspected this, but forgot most that I read about Hyp mode by now. > >> Need to refresh my memory ASAP. Is it impossible even with a lot of > >> emulation? Can guest detect that it is not in a Hyp mode without > >> trapping into hypervisor? > > > > Yes. The current mode is in the the low bits of the CPSR, which > > is readable without causing a trap. This is just the most obvious > > roadblock; I bet there are more. If you really had to run Hyp mode > > code in a VM you probably have to do it by having it all emulated > > via TCG. > > Or in an in-kernel instruction emulator that we have lying around anyways. For kvm-in-kvm that should be good enough, as we only need to execute a few instructions in HYP mode. > Will require emulation on each trap to Hyp mode tough. But since you already have ideas about nested Hyp I consider it done :) -- Gleb.
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h index 7d22517..e45a74b 100644 --- a/arch/arm/include/asm/kvm_host.h +++ b/arch/arm/include/asm/kvm_host.h @@ -38,11 +38,6 @@ #define KVM_VCPU_MAX_FEATURES 1 -/* We don't currently support large pages. */ -#define KVM_HPAGE_GFN_SHIFT(x) 0 -#define KVM_NR_PAGE_SIZES 1 -#define KVM_PAGES_PER_HPAGE(x) (1UL<<31) - #include <kvm/arm_vgic.h> struct kvm_vcpu;
The KVM_HPAGE_DEFINES are a little artificial on ARM, since the huge page size is statically defined at compile time and there is only a single huge page size. Now when the main kvm code relying on these defines has been moved to the x86 specific part of the world, we can get rid of these. Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> --- [Resending this because the KVM list filter caught the subject of the previous message due to the letter X] arch/arm/include/asm/kvm_host.h | 5 ----- 1 file changed, 5 deletions(-)