qemu-arm
[Top][All Lists]
Advanced

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

Re: [PATCH v22 7/9] ACPI: Record Generic Error Status Block(GESB) table


From: Igor Mammedov
Subject: Re: [PATCH v22 7/9] ACPI: Record Generic Error Status Block(GESB) table
Date: Mon, 3 Feb 2020 08:55:01 +0100

On Sun, 2 Feb 2020 21:42:23 +0800
gengdongjiu <address@hidden> wrote:

> On 2020/1/28 23:29, Igor Mammedov wrote:
> > On Wed, 8 Jan 2020 19:32:21 +0800
> > Dongjiu Geng <address@hidden> wrote:
> >   
> >> kvm_arch_on_sigbus_vcpu() error injection uses source_id as
> >> index in etc/hardware_errors to find out Error Status Data
> >> Block entry corresponding to error source. So supported source_id
> >> values should be assigned here and not be changed afterwards to
> >> make sure that guest will write error into expected Error Status
> >> Data Block even if guest was migrated to a newer QEMU.
> >>
> >> Before QEMU writes a new error to ACPI table, it will check whether
> >> previous error has been acknowledged. Otherwise it will ignore the new
> >> error. For the errors section type, QEMU simulate it to memory section
> >> error.
> >>
> >> Signed-off-by: Dongjiu Geng <address@hidden>
> >> Signed-off-by: Xiang Zheng <address@hidden>
> >> Reviewed-by: Michael S. Tsirkin <address@hidden>

btw:
when you are changing patch and it's not a trivial change,
you are supposed to drop Reviewed-by/Acked-by tags.

[...]
> >> diff --git a/include/qemu/uuid.h b/include/qemu/uuid.h
> >> index 129c45f..b35e294 100644
> >> --- a/include/qemu/uuid.h
> >> +++ b/include/qemu/uuid.h
> >> @@ -34,6 +34,11 @@ typedef struct {
> >>      };
> >>  } QemuUUID;
> >>  
> >> +#define UUID_LE(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7)             \
> >> +  {{{ (a) & 0xff, ((a) >> 8) & 0xff, ((a) >> 16) & 0xff, ((a) >> 24) & 
> >> 0xff, \
> >> +     (b) & 0xff, ((b) >> 8) & 0xff, (c) & 0xff, ((c) >> 8) & 0xff,        
> >>   \
> >> +     (d0), (d1), (d2), (d3), (d4), (d5), (d6), (d7) } } }  
> > 
> > since you are adding generalizing macro, take of NVDIMM_UUID_LE which 
> > served as model  
> 
> do you mean use this generalizing macro to replace NVDIMM_UUID_LE, right?

yes, and preferably do that in a separate patch

> 
> > 
> >   
> >>  #define UUID_FMT "%02hhx%02hhx%02hhx%02hhx-" \
> >>                   "%02hhx%02hhx-%02hhx%02hhx-" \
> >>                   "%02hhx%02hhx-" \  
> > 
> > .
> >   
> 




reply via email to

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