[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] i386: Fix signedness of hyperv_spinlock_attempt
From: |
Vadim Rozenfeld |
Subject: |
Re: [Qemu-devel] [PATCH] i386: Fix signedness of hyperv_spinlock_attempts |
Date: |
Tue, 18 Jun 2019 11:24:57 +1000 |
On Mon, 2019-06-17 at 14:49 -0300, Eduardo Habkost wrote:
> On Mon, Jun 17, 2019 at 05:32:13PM +0000, Roman Kagan wrote:
> > On Mon, Jun 17, 2019 at 11:23:01AM -0300, Eduardo Habkost wrote:
> > > On Mon, Jun 17, 2019 at 01:48:59PM +0000, Roman Kagan wrote:
> > > > On Sat, Jun 15, 2019 at 05:05:05PM -0300, Eduardo Habkost
> > > > wrote:
> > > > > The current default value for hv-spinlocks is 0xFFFFFFFF
> > > > > (meaning
> > > > > "never retry"). However, the value is stored as a signed
> > > > > integer, making the getter of the hv-spinlocks QOM property
> > > > > return -1 instead of 0xFFFFFFFF.
> > > > >
> > > > > Fix this by changing the type of
> > > > > X86CPU::hyperv_spinlock_attempts
> > > > > to uint32_t. This has no visible effect to guest operating
> > > > > systems, affecting just the behavior of the QOM getter.
> > > > >
> > > > > Signed-off-by: Eduardo Habkost <address@hidden>
> > > > > ---
> > > > > target/i386/cpu.h | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > Reviewed-by: Roman Kagan <address@hidden>
> > > >
> > > > That said, it's tempting to just nuke qdev_prop_spinlocks and
> > > > make
> > > > hv-spinlocks a regular DEFINE_PROP_UINT32...
> > >
> > > Agreed. The only difference is that we would validate the
> > > property at realize time instead of object_property_set().
> >
> > Right. But currently it's validated to be no less than 0xfff and
> > no
> > bigger than 0xffffffff. The latter check would become unnecessary,
> > and
> > I'm unable to find any reason to do the former (neither spec
> > references
> > nor the log messages of the commits that introduced it).
>
> The 0xFFF lower limit was originally introduced by commit
> 28f52cc04d34 ("hyper-v: introduce Hyper-V support infrastructure").
>
> Vadim, do you know where the 0xFFF limit comes from?
I simply took this value from Windows Server 2008 R2 that
I used as a reference while working on Hyper-V support for KVM.
I also remember some paper (probably published by AMD ???) mentioned
that 0x2fff seemed to have the best balance for PLE logic.
Best,
Vadim.
- [Qemu-devel] [PATCH] i386: Fix signedness of hyperv_spinlock_attempts, Eduardo Habkost, 2019/06/15
- Re: [Qemu-devel] [PATCH] i386: Fix signedness of hyperv_spinlock_attempts, Vitaly Kuznetsov, 2019/06/17
- Re: [Qemu-devel] [PATCH] i386: Fix signedness of hyperv_spinlock_attempts, Roman Kagan, 2019/06/17
- Re: [Qemu-devel] [PATCH] i386: Fix signedness of hyperv_spinlock_attempts, Eduardo Habkost, 2019/06/17
- Re: [Qemu-devel] [PATCH] i386: Fix signedness of hyperv_spinlock_attempts, Roman Kagan, 2019/06/17
- Re: [Qemu-devel] [PATCH] i386: Fix signedness of hyperv_spinlock_attempts, Eduardo Habkost, 2019/06/17
- Re: [Qemu-devel] [PATCH] i386: Fix signedness of hyperv_spinlock_attempts,
Vadim Rozenfeld <=
- Re: [Qemu-devel] [PATCH] i386: Fix signedness of hyperv_spinlock_attempts, Roman Kagan, 2019/06/18
- Re: [Qemu-devel] [PATCH] i386: Fix signedness of hyperv_spinlock_attempts, Roman Kagan, 2019/06/18
- Re: [Qemu-devel] [PATCH] i386: Fix signedness of hyperv_spinlock_attempts, Vadim Rozenfeld, 2019/06/18
Re: [Qemu-devel] [PATCH] i386: Fix signedness of hyperv_spinlock_attempts, Eduardo Habkost, 2019/06/18