Re: kernel selftest max_guest_memory_test fails when using more that 256 vCPUs

[Sean Christopherson <seanjc@google.com>]

On Tue, Mar 12, 2024, Andrew Jones wrote:
> On Mon, Mar 11, 2024 at 05:05:18PM -0700, Sean Christopherson wrote:
> > On Mon, Mar 11, 2024, mlevitsk@redhat.com wrote:
> > diff --git a/tools/testing/selftests/kvm/max_guest_memory_test.c b/tools/testing/selftests/kvm/max_guest_memory_test.c
> > index 6628dc4dda89..5f9950f41313 100644
> > --- a/tools/testing/selftests/kvm/max_guest_memory_test.c
> > +++ b/tools/testing/selftests/kvm/max_guest_memory_test.c
> > @@ -22,10 +22,12 @@ static void guest_code(uint64_t start_gpa, uint64_t end_gpa, uint64_t stride)
> >  {
> >         uint64_t gpa;
> >  
> > -       for (gpa = start_gpa; gpa < end_gpa; gpa += stride)
> > -               *((volatile uint64_t *)gpa) = gpa;
> > +       for (;;) {
> > +               for (gpa = start_gpa; gpa < end_gpa; gpa += stride)
> > +                       *((volatile uint64_t *)gpa) = gpa;
> >  
> > -       GUEST_DONE();
> > +               GUEST_DONE();
> 
> I'd change this to a GUEST_SYNC(0), since the infinite loop otherwise
> contradicts the "done-ness".

Eh, the guest is "done" with an iteration/run.  :-)

I don't have a strong preference, I'm just biased against GUEST_SYNC() in general,
as tests that heavily use GUEST_SYNC() tend to be ridiculously hard to follow/debug.