diff mbox

[kvm-unit-tests,01/14] x86: vm: allow multiple init for vm setup

Message ID 1476448852-30062-2-git-send-email-peterx@redhat.com (mailing list archive)
State New, archived
Headers show

Commit Message

Peter Xu Oct. 14, 2016, 12:40 p.m. UTC
Signed-off-by: Peter Xu <peterx@redhat.com>
---
 lib/x86/vm.c | 7 +++++++
 1 file changed, 7 insertions(+)

Comments

Andrew Jones Oct. 20, 2016, 8:17 a.m. UTC | #1
On Fri, Oct 14, 2016 at 08:40:39PM +0800, Peter Xu wrote:
> Signed-off-by: Peter Xu <peterx@redhat.com>
> ---
>  lib/x86/vm.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/lib/x86/vm.c b/lib/x86/vm.c
> index 906fbf2..9771bd7 100644
> --- a/lib/x86/vm.c
> +++ b/lib/x86/vm.c
> @@ -151,9 +151,16 @@ static void setup_mmu(unsigned long len)
>  
>  void setup_vm()
>  {
> +    static bool vm_inited = false;
> +
> +    if (vm_inited) {
> +        return;
> +    }
> +
>      end_of_memory = fwcfg_get_u64(FW_CFG_RAM_SIZE);
>      free_memory(&edata, end_of_memory - (unsigned long)&edata);
>      setup_mmu(end_of_memory);
> +    vm_inited = true;
>  }
>  
>  void *vmalloc(unsigned long size)
> -- 
> 2.7.4
>

My preference for kvm-unit-tests is that we avoid tolerating
unit tests that do things "wrong". This patch allows setup_vm
to be called multiple times, but why do that? Why not just
ensure it's only called once? If it looks like a mistake that's
easy to make and hard to debug, then maybe we need an assert

 assert(!end_of_memory); /* ensure we haven't already called setup_vm */

or something.

Thanks,
drew
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Peter Xu Oct. 20, 2016, 8:24 a.m. UTC | #2
On Thu, Oct 20, 2016 at 10:17:07AM +0200, Andrew Jones wrote:
> On Fri, Oct 14, 2016 at 08:40:39PM +0800, Peter Xu wrote:
> > Signed-off-by: Peter Xu <peterx@redhat.com>
> > ---
> >  lib/x86/vm.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/lib/x86/vm.c b/lib/x86/vm.c
> > index 906fbf2..9771bd7 100644
> > --- a/lib/x86/vm.c
> > +++ b/lib/x86/vm.c
> > @@ -151,9 +151,16 @@ static void setup_mmu(unsigned long len)
> >  
> >  void setup_vm()
> >  {
> > +    static bool vm_inited = false;
> > +
> > +    if (vm_inited) {
> > +        return;
> > +    }
> > +
> >      end_of_memory = fwcfg_get_u64(FW_CFG_RAM_SIZE);
> >      free_memory(&edata, end_of_memory - (unsigned long)&edata);
> >      setup_mmu(end_of_memory);
> > +    vm_inited = true;
> >  }
> >  
> >  void *vmalloc(unsigned long size)
> > -- 
> > 2.7.4
> >
> 
> My preference for kvm-unit-tests is that we avoid tolerating
> unit tests that do things "wrong". This patch allows setup_vm
> to be called multiple times, but why do that? Why not just
> ensure it's only called once? If it looks like a mistake that's
> easy to make and hard to debug, then maybe we need an assert
> 
>  assert(!end_of_memory); /* ensure we haven't already called setup_vm */
> 
> or something.

Yeah, sure. The first two patches are just something good to have IMO,
I did it since I see we have similar thing in setup_idt(), and I feel
it good. I can replace it with an assertion.

Thanks.

-- peterx
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Andrew Jones Oct. 20, 2016, 8:41 a.m. UTC | #3
On Thu, Oct 20, 2016 at 04:24:08PM +0800, Peter Xu wrote:
> On Thu, Oct 20, 2016 at 10:17:07AM +0200, Andrew Jones wrote:
> > On Fri, Oct 14, 2016 at 08:40:39PM +0800, Peter Xu wrote:
> > > Signed-off-by: Peter Xu <peterx@redhat.com>
> > > ---
> > >  lib/x86/vm.c | 7 +++++++
> > >  1 file changed, 7 insertions(+)
> > > 
> > > diff --git a/lib/x86/vm.c b/lib/x86/vm.c
> > > index 906fbf2..9771bd7 100644
> > > --- a/lib/x86/vm.c
> > > +++ b/lib/x86/vm.c
> > > @@ -151,9 +151,16 @@ static void setup_mmu(unsigned long len)
> > >  
> > >  void setup_vm()
> > >  {
> > > +    static bool vm_inited = false;
> > > +
> > > +    if (vm_inited) {
> > > +        return;
> > > +    }
> > > +
> > >      end_of_memory = fwcfg_get_u64(FW_CFG_RAM_SIZE);
> > >      free_memory(&edata, end_of_memory - (unsigned long)&edata);
> > >      setup_mmu(end_of_memory);
> > > +    vm_inited = true;
> > >  }
> > >  
> > >  void *vmalloc(unsigned long size)
> > > -- 
> > > 2.7.4
> > >
> > 
> > My preference for kvm-unit-tests is that we avoid tolerating
> > unit tests that do things "wrong". This patch allows setup_vm
> > to be called multiple times, but why do that? Why not just
> > ensure it's only called once? If it looks like a mistake that's
> > easy to make and hard to debug, then maybe we need an assert
> > 
> >  assert(!end_of_memory); /* ensure we haven't already called setup_vm */
> > 
> > or something.
> 
> Yeah, sure. The first two patches are just something good to have IMO,
> I did it since I see we have similar thing in setup_idt(), and I feel
> it good. I can replace it with an assertion.

Let's do these patches separate from the series and maybe change setup_idt
too? It'd be interesting to see if the assert in setup_idt would fire,
i.e. if any users are relying on it being tolerant to multiple calls, and
then find out why.

drew
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Peter Xu Oct. 20, 2016, 8:55 a.m. UTC | #4
On Thu, Oct 20, 2016 at 10:41:37AM +0200, Andrew Jones wrote:

[...]

> Let's do these patches separate from the series and maybe change setup_idt
> too? It'd be interesting to see if the assert in setup_idt would fire,
> i.e. if any users are relying on it being tolerant to multiple calls, and
> then find out why.

The problem should be: smp_init() is calling setup_idt(). So if we
change the init stuff in setup_idt() into an assertion, any test
program that calls both smp_init() and setup_idt() would possibly fail
the assertion. Actually I see most test cases are using:

	setup_vm();
	smp_init();
	setup_idt();

to setup a basic environment, so I guess all of these use cases would
fail. In that sense, I'd slightly prefer keep setup_idt() as it is.

Thanks,

-- peterx
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Andrew Jones Oct. 20, 2016, 9:39 a.m. UTC | #5
On Thu, Oct 20, 2016 at 04:55:22PM +0800, Peter Xu wrote:
> On Thu, Oct 20, 2016 at 10:41:37AM +0200, Andrew Jones wrote:
> 
> [...]
> 
> > Let's do these patches separate from the series and maybe change setup_idt
> > too? It'd be interesting to see if the assert in setup_idt would fire,
> > i.e. if any users are relying on it being tolerant to multiple calls, and
> > then find out why.
> 
> The problem should be: smp_init() is calling setup_idt(). So if we
> change the init stuff in setup_idt() into an assertion, any test
> program that calls both smp_init() and setup_idt() would possibly fail
> the assertion. Actually I see most test cases are using:
> 
> 	setup_vm();
> 	smp_init();
> 	setup_idt();
> 
> to setup a basic environment, so I guess all of these use cases would
> fail. In that sense, I'd slightly prefer keep setup_idt() as it is.

Well I guess the fix is just to remove the unnecessary setup_idt calls
from all unit tests that do smp_init(). Anyway, I won't fight too hard
for this cleanup, but I certainly prefer not to propagate the sloppiness
further into the other setups.

Thanks,
drew
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Peter Xu Oct. 20, 2016, 11:01 a.m. UTC | #6
On Thu, Oct 20, 2016 at 11:39:06AM +0200, Andrew Jones wrote:
> On Thu, Oct 20, 2016 at 04:55:22PM +0800, Peter Xu wrote:
> > On Thu, Oct 20, 2016 at 10:41:37AM +0200, Andrew Jones wrote:
> > 
> > [...]
> > 
> > > Let's do these patches separate from the series and maybe change setup_idt
> > > too? It'd be interesting to see if the assert in setup_idt would fire,
> > > i.e. if any users are relying on it being tolerant to multiple calls, and
> > > then find out why.
> > 
> > The problem should be: smp_init() is calling setup_idt(). So if we
> > change the init stuff in setup_idt() into an assertion, any test
> > program that calls both smp_init() and setup_idt() would possibly fail
> > the assertion. Actually I see most test cases are using:
> > 
> > 	setup_vm();
> > 	smp_init();
> > 	setup_idt();
> > 
> > to setup a basic environment, so I guess all of these use cases would
> > fail. In that sense, I'd slightly prefer keep setup_idt() as it is.
> 
> Well I guess the fix is just to remove the unnecessary setup_idt calls
> from all unit tests that do smp_init(). Anyway, I won't fight too hard
> for this cleanup, but I certainly prefer not to propagate the sloppiness
> further into the other setups.

It won't be hard to do that. Let me cook one for this.

Thanks,

-- peterx
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/lib/x86/vm.c b/lib/x86/vm.c
index 906fbf2..9771bd7 100644
--- a/lib/x86/vm.c
+++ b/lib/x86/vm.c
@@ -151,9 +151,16 @@  static void setup_mmu(unsigned long len)
 
 void setup_vm()
 {
+    static bool vm_inited = false;
+
+    if (vm_inited) {
+        return;
+    }
+
     end_of_memory = fwcfg_get_u64(FW_CFG_RAM_SIZE);
     free_memory(&edata, end_of_memory - (unsigned long)&edata);
     setup_mmu(end_of_memory);
+    vm_inited = true;
 }
 
 void *vmalloc(unsigned long size)