qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 07/14] hw/i386/vmport: Add support for CMD_GETBIOSUUID


From: Michael S. Tsirkin
Subject: Re: [PATCH 07/14] hw/i386/vmport: Add support for CMD_GETBIOSUUID
Date: Tue, 10 Mar 2020 08:01:39 -0400

On Tue, Mar 10, 2020 at 04:44:54AM -0700, Liran Alon wrote:
> 
> On 10/03/2020 11:22, Michael S. Tsirkin wrote:
> > On Tue, Mar 10, 2020 at 01:54:04AM +0200, Liran Alon wrote:
> > > This is VMware documented functionallity that some guests rely on.
> > > Returns the BIOS UUID of the current virtual machine.
> > > 
> > > Reviewed-by: Nikita Leshenko <address@hidden>
> > > Signed-off-by: Liran Alon <address@hidden>
> > > ---
> > >   hw/i386/vmport.c     | 14 ++++++++++++++
> > >   include/hw/i386/pc.h |  1 +
> > >   2 files changed, 15 insertions(+)
> > > 
> > > diff --git a/hw/i386/vmport.c b/hw/i386/vmport.c
> > > index 2ae5afc42b50..7687f3368a55 100644
> > > --- a/hw/i386/vmport.c
> > > +++ b/hw/i386/vmport.c
> > > @@ -26,6 +26,7 @@
> > >   #include "hw/i386/pc.h"
> > >   #include "hw/input/i8042.h"
> > >   #include "hw/qdev-properties.h"
> > > +#include "sysemu/sysemu.h"
> > >   #include "sysemu/hw_accel.h"
> > >   #include "qemu/log.h"
> > >   #include "trace.h"
> > > @@ -121,6 +122,18 @@ static uint32_t vmport_cmd_get_version(void *opaque, 
> > > uint32_t addr)
> > >       return port_state->vmx_version;
> > >   }
> > > +static uint32_t vmport_cmd_get_bios_uuid(void *opaque, uint32_t addr)
> > > +{
> > > +    X86CPU *cpu = X86_CPU(current_cpu);
> > > +    uint32_t *uuid_parts = (uint32_t*)(qemu_uuid.data);

BTW missing space before * here.

> > > +
> > > +    cpu->env.regs[R_EAX] = uuid_parts[0];
> > > +    cpu->env.regs[R_EBX] = uuid_parts[1];
> > > +    cpu->env.regs[R_ECX] = uuid_parts[2];
> > > +    cpu->env.regs[R_EDX] = uuid_parts[3];
> > > +    return cpu->env.regs[R_EAX];
> > > +}
> > > +
> > Should be LE here?
> 
> No. This is how the UUID is expected to be returned to guest.
> 
> -Liran
> 

Um *how* is it expected to be returned? IIUC this takes network order
byte data and handles it as host endian. Assuming it's right on an LE
host it isn't on a BE host.  So I am guessing you want le32_to_cpu here.

-- 
MST




reply via email to

[Prev in Thread] Current Thread [Next in Thread]