Re: [PATCH v16 08/14] numa: Extend CLI to provide memory latency and bandwidth information

[Tao Xu]

On 11/19/2019 7:03 PM, Igor Mammedov wrote:

On Fri, 15 Nov 2019 15:53:46 +0800
Tao Xu  wrote:


From: Liu Jingqi 

Add -numa hmat-lb option to provide System Locality Latency and
Bandwidth Information. These memory attributes help to build
System Locality Latency and Bandwidth Information Structure(s)
in ACPI Heterogeneous Memory Attribute Table (HMAT).

Signed-off-by: Liu Jingqi 
Signed-off-by: Tao Xu 


looks good to me, so

Reviewed-by: Igor Mammedov 


PS:
also see question below


[...]

+
+hmat_lb->range_bitmap |= node->bandwidth;
+first_bit = ctz64(hmat_lb->range_bitmap);
+hmat_lb->base = UINT64_C(1) << first_bit;
+max_entry = node->bandwidth / hmat_lb->base;
+last_bit = 64 - clz64(hmat_lb->range_bitmap);
+
+/*
+ * For bandwidth, first_bit record the base unit of bandwidth bits,
+ * last_bit record the last bit of the max bandwidth. The max 
compressed
+ * bandwidth should be less than 0x (UINT16_MAX)
+ */
+if ((last_bit - first_bit) > UINT16_BITS || max_entry >= UINT16_MAX) {

^^^
what bandwidth combination is going to trigger above condition?

Only use (last_bit - first_bit) > UINT16_BITS, we can't trigger error if 
the max compressed bandwidth is 0x. Because in that condition, 
"last_bit - first_bit == UINT16_BITS". So I add "max_entry >= 
UINT16_MAX" to catch 0x. For example:


Combination 1 (Error):
bandwidth1   = ...    1110 ... (max_entry 32767)
range_bitmap = ...    1110 ... (range is 15 bits)
bandwidth2   = ...     ... (max_entry 65535)
range_bitmap = ...     ... (range is 16 bits)

Combination 2 (Error):
bandwidth1   = ...    1110 ... (max_entry 32767)
range_bitmap = ...    1110 ... (range is 15 bits)
bandwidth2   = ...0001    1110 ... (max_entry 65535)
range_bitmap = ...0001    1110 ... (range is 16 bits)

Combination 3 (OK, because bandwidth1 will be compressed to 65534):
bandwidth1   = ...    1110 ... (max_entry 32767)
range_bitmap = ...    1110 ... (range is 15 bits)
bandwidth2   = ... 0111    ... (max_entry 32767)
range_bitmap = ...     ... (range is 16 bits)

Combination 4 (Error):
bandwidth1   = ...     ... (max_entry 65535)
range_bitmap = ...     ... (range is 16 bits)

Re: [PATCH v3 14/33] serial-mm: add "regshift" property

[Marc-André Lureau]

Hi

On Mon, Nov 18, 2019 at 6:54 PM Peter Maydell  wrote:
>
> On Wed, 23 Oct 2019 at 18:34, Marc-André Lureau
>  wrote:
> >
> > And a property and rename "it_shift" field to "regshift", as it seems
> > to be more popular (and I don't know what "it" stands for).
> >
> > Signed-off-by: Marc-André Lureau 
>
> I have no idea what it_shift means either (I had a look in the
> git history but it seems to have been added with that name
> very early on when the commit logs were generally not very
> informative); 'regshift' sounds good to me too.
>
> > +static Property serial_mm_properties[] = {
> > +DEFINE_PROP_UINT8("regshift", SerialMM, regshift, 0),
>
> This could use a comment describing what the property does.

"Set the register shift value"? Half-kidding, do you have better
comment to make? Otherwise, it's probably not worth.

>From what I understand, it's just applying a shift on the IO addr,
probably for alignment/access arch-specific reasons. You probably know
better than me ;)

>
> > +DEFINE_PROP_END_OF_LIST(),
>
> Otherwise
> Reviewed-by: Peter Maydell 
>

thanks

Re: [SeaBIOS] Re: 1.13 release?

[Gerd Hoffmann]

On Mon, Nov 18, 2019 at 01:08:39PM -0500, Kevin O'Connor wrote:
> On Wed, Nov 06, 2019 at 11:29:18AM -0500, Kevin O'Connor wrote:
> > On Wed, Nov 06, 2019 at 12:12:55PM +0100, Gerd Hoffmann wrote:
> > > On Wed, Oct 16, 2019 at 12:44:12PM +0200, Gerd Hoffmann wrote:
> > > >   Hi,
> > > > 
> > > > Almost a year since 1.12.0 was tagged (Nov 17th to be exact),
> > > > time to plan the 1.13 release I think ...
> > > > 
> > > > How about freeze in a week or two, release by mid-november?
> > > > 
> > > > Pending stuff I'm aware of is the disk geometry patch series.
> > > > The corresponding qemu series is still waiting to be merged.
> > > 
> > > It's finally merged in qemu now.  Going to push the seabios
> > > series and prepare a seabios update for qemu, so upcoming
> > > seabios release gets some more test coverage.
> > 
> > Okay, thanks.
> > 
> > If we're going to update that in SeaBIOS, then we may wish to push
> > back the SeaBIOS release by a few weeks.
> 
> At this point, I'm targeting early December for the release.  Let me
> know if there are any concerns with that.

Hmm, that is a bit late for the final qemu 4.2 release (see
https://wiki.qemu.org/Planning/4.2).  But seabios 1.13 in qemu hasn't
seen any real testing so far: the update landed in -rc2 (tagged
yesterday) not -rc0 due to the lchs patch series issues (late merge of
the qemu patches and ahci test failure).  So having a tested 1.13-final
in -rc3 is pretty much impossible, even -rc4 is ambitious and requires
tagging the seabios release on Dec 1st or 2nd (less than two weeks from
now).  Which would be nice from qemu point of view, but if this doesn't
work out sky isn't falling either.  We can also release qemu 4.2 with
the snapshot and update to 1.13-final in 4.2.1 ...

cheers,
  Gerd

Re: [PATCH] spapr: Fix VSMT mode when it is not supported by the kernel

[Greg Kurz]

On Wed, 20 Nov 2019 15:36:53 +1100
David Gibson  wrote:

> On Tue, Nov 19, 2019 at 04:45:26PM +0100, Greg Kurz wrote:
> > On Tue, 19 Nov 2019 15:06:51 +0100
> > Laurent Vivier  wrote:
> > 
> > > On 19/11/2019 02:00, David Gibson wrote:
> > > > On Fri, Nov 08, 2019 at 05:47:59PM +0100, Greg Kurz wrote:
> > > >> On Fri,  8 Nov 2019 16:40:35 +0100
> > > >> Laurent Vivier  wrote:
> > > >>
> > > >>> Commit 29cb4187497d sets by default the VSMT to smp_threads,
> > > >>> but older kernels (< 4.13) don't support that.
> > > >>>
> > > >>> We can reasonably restore previous behavior with this kernel
> > > >>> to allow to run QEMU as before.
> > > >>>
> > > >>> If VSMT is not supported, VSMT will be set to MAX(8, smp_threads)
> > > >>> as it is done for previous machine types (< pseries-4.2)
> > > >>>
> > > >>
> > > >> It is usually _bad_ to base the machine behavior on host capabilities.
> > > >> What happens if we migrate between an older kernel and a recent one ?
> > > > 
> > > > Right.  We're really trying to remove instaces of such behaviour.  I'd
> > > > prefer to completely revert Greg's original patch than to re-introduce
> > > > host configuration dependency into the guest configuration..
> > > > 
> > > >> I understand this is to fix tests/migration-test on older kernels.
> > > >> Couldn't this be achieved with migration-test doing some introspection
> > > >> and maybe pass vsmt=8 on the QEMU command line ?
> > > > 
> > > > ..adjusting the test case like this might be a better idea, though.
> > > > 
> > > > What's the test setup where we're using the old kernel?  I really only
> > > > applied the original patch on the guess that we didn't really care
> > > > about kernels that old.  The fact you've hit this in practice makes me
> > > > doubt that assumption.
> > > > 
> > > 
> > > The way to fix the tests is to add "-smp threads=8" on the command line
> > > (for all tests, so basically in qtest_init_without_qmp_handshake(), and
> > > it will impact all the machine types), and we have to check if it is
> > 
> > Ohhh... it isn't possible to initialize Qtest with machine specific
> > properties ? That's a bit unfortunate :-\
> 
> Uhh... I don't see why we can't.  Couldn't we just put either -machine
> vsmt=8 or -smp 8 into the cmd_src / cmd_dst printfs() in the
> strcmp(arch, "ppc64") case?
> 

Yes you seem to be right for migration-test... so I'm not sure what Laurent is
implying with qtest_init_without_qmp_handshake().

> > > ppc64/pseries to do that, and there it becomes a little bit complicated
> > > for a so small piece of code.
> > > 
> > > So I think the best to do is to revert Greg's patch.
> > > 
> > 
> > I'm okay with that since this patch doesn't bring much for the moment.
> > 
> > But soon, ie. linux-5.5 hopefully, KVM will allow to configure the number
> > of presenters in the XIVE and XICS-on-XIVE devices on POWER9. Combined
> > with this patch, it will allow to drastically reduce the consumption of
> > resources in the XIVE HW, which currently limits the number of VMs that
> > can run concurrently with an in-kernel irqchip. So I hope the 'make check'
> > you're willing to fix is worth it :-), and BTW you didn't answer David's
> > question about the test setup.
> > 
> 



pgpQzHnVsx2QM.pgp
Description: OpenPGP digital signature

Re: [PATCH] Add minimal Hexagon target - First in a series of patches - linux-user changes + linux-user/hexagon + skeleton of target/hexagon - Files in target/hexagon/imported are from another project

[Richard Henderson]

On 11/20/19 3:26 AM, Aleksandar Markovic wrote:
> 
> 
> On Tuesday, November 19, 2019, Richard Henderson  > wrote:
> 
> On 11/19/19 6:22 PM, Taylor Simpson wrote:
> > - Laurent suggested I split the patch into two parts: linux-user and
> target/hexagon.  If I do that, which one should contain the changes to
> common files (e.g., configure)?  Also, note that we won't be able to build
> until both patches are merged.  Is that OK?
> 
> The configure parts should be a third, last, patch.
> 
> The series is bisectable, because before the configure patch,
> none of the hexagon code is compiled at all.
> 
> 
> I don't think this is a good advice. Yes, at first glance, that would make the
> submitter's job easier - since he could divide the whole code into parts
> practicaly arbitrarily - but the resulting series will be of suboptimal
> quality.

How's that?  He has been asked to split the linux-user stuff from the target
skeleton stuff.  Neither of these will compile independently.  You could merge
the configure bits artificially into the second of the two patches, or you
could leave it separate.

> If the submitter was forced from the outset to add segments of his
> solution so that each step actually (not only ostensibly) compiles, he would
> also be forced to organize patches in much more coherent way, organize his 
> code
> in much more modular way, possibly improve initial organization, additionally
> making reviews much easier.

This argument would make more sense if there were more present here than a
skeleton.  The vast majority of the work is yet to be submitted, and *will*
have to compile, be coherent, etc, just as you suggest.


r~

Re: [PATCH 0/5] ppc/pnv: fix Homer/Occ mappings on multichip systems

[Cédric Le Goater]

Hello,

On 19/11/2019 18:50, Balamuruhan S wrote:
> Hi All,
> 
> PowerNV fails to boot in multichip systems due to some misinterpretation
> and mapping in Homer/Occ device models, this patchset fixes the
> following,
> 
>  - Homer size is 4MB per chip and Occ common area size is 8MB
>  - Bar masks are used to calculate sizes of Homer/Occ in skiboot so
>return appropriate value
>  - Occ common area is in BAR 3 on Power8 but wrongly mapped to BAR 2
>currently
>  - OCC common area is shared across chips and should be mapped only once
>for multichip systems

The first thing to address is the HOMER XSCOM region. 

Introduce an empty skeleton for P8 and P9 with different mem ops handers
because the registers have a different layout. From there, add the support
for the different PBA* regs and move them out from the default XSCOM
handlers. That should fix most of the current problems and it will provide 
a nice framework for future extensions.

Why not add the associated HOMER MMIO region while we are it ? the PBA
registers have all the definitions we need and it will gives us access
to the pstate table.


Second is the OCC region. Do we need a XSCOM *or* a MMIO region ? This is 
not clear. Please check skiboot. I think a MMIO region should be enough
because this is how sensor data from the OCC is accessed. 

On that topic, we could define properties on the PnvOCC model for each 
sensor and tune the value from the QEMU monitor. It really shouldn't be
too complex.

Also the same address is used, we should only map it once but we need 
to invent something to know from which chip it is accessed. 


C.


> 
> Request for your review and suggestions to make it better. I would like to
> thank Cedric for his time and help to figure out the issues.
>
> Balamuruhan S (5):
>   hw/ppc/pnv: incorrect homer and occ common area size
>   hw/ppc/pnv_xscom: PBA bar mask values are incorrect with homer/occ
> sizes
>   hw/ppc/pnv_xscom: Power8 occ common area is in PBA BAR 3
>   hw/ppc/pnv_xscom: occ common area to be mapped only once
>   hw/ppc/pnv_xscom: add PBA BARs for Power8 slw image
> 
>  hw/ppc/pnv_occ.c |  2 +-
>  hw/ppc/pnv_xscom.c   | 37 +++--
>  include/hw/ppc/pnv.h | 12 
>  3 files changed, 36 insertions(+), 15 deletions(-)
> 

Re: [PATCH v3 13/33] serial: start making SerialMM a sysbus device

[Marc-André Lureau]

Hi

On Mon, Nov 18, 2019 at 6:43 PM Peter Maydell  wrote:
>
> On Wed, 23 Oct 2019 at 18:33, Marc-André Lureau
>  wrote:
> >
> > Memory mapped serial device is in fact a sysbus device. The following
> > patches will make use of sysbus facilities for resource and
> > registration.
> >
> > Signed-off-by: Marc-André Lureau 
> > ---
> >  hw/char/omap_uart.c  |  2 +-
> >  hw/char/serial.c | 47 
> >  hw/mips/boston.c |  2 +-
> >  hw/mips/mips_malta.c |  2 +-
> >  include/hw/char/serial.h | 20 -
> >  5 files changed, 51 insertions(+), 22 deletions(-)
>
>
> > -SerialState *serial_mm_init(MemoryRegion *address_space,
> > +SerialMM *serial_mm_init(MemoryRegion *address_space,
> >  hwaddr base, int it_shift,
> >  qemu_irq irq, int baudbase,
> >  Chardev *chr, enum device_endian end)
> >  {
> > -DeviceState *dev = DEVICE(object_new(TYPE_SERIAL));
> > -SerialState *s = SERIAL(dev);
> > +SerialMM *self = SERIAL_MM(qdev_create(NULL, TYPE_SERIAL_MM));
> > +SerialState *s = >serial;
> >
> > -s->it_shift = it_shift;
> > +self->it_shift = it_shift;
> >  s->irq = irq;
> > -qdev_prop_set_uint32(dev, "baudbase", baudbase);
> > -qdev_prop_set_chr(dev, "chardev", chr);
> > -qdev_prop_set_int32(dev, "instance-id", base);
> > -qdev_init_nofail(dev);
> > +qdev_prop_set_uint32(DEVICE(s), "baudbase", baudbase);
> > +qdev_prop_set_chr(DEVICE(s), "chardev", chr);
> > +qdev_prop_set_int32(DEVICE(s), "instance-id", base);
> > +
> > +qdev_init_nofail(DEVICE(s));
> > +qdev_init_nofail(DEVICE(self));
>
> Something odd is going on here. This is a convenience
> wrapper around creating the SERIAL_MM device, so it's
> correct that it has to init DEVICE(self). But it should
> not be doing anything with the internals of 'self'.
> It's the instance_init/realize of the SERIAL_MM object that should
> instance_init/realize the 'self->serial' object. You have the
> code below to do the 'instance_init' in the serial_mm_instance_init
> function, but are missing the equivalent realize code.

This should be addressed later with "serial-mm: use sysbus
facilities". I'll add a comment.

>
> > -memory_region_init_io(>io, NULL, _mm_ops[end], s,
> > +memory_region_init_io(>io, NULL, _mm_ops[end], self,
> >"serial", 8 << it_shift);
> >  memory_region_add_subregion(address_space, base, >io);
> > -return s;
> > +
> > +return self;
> > +}
> > +
> > +static void serial_mm_instance_init(Object *o)
> > +{
> > +SerialMM *self = SERIAL_MM(o);
>
> 'self' is not idiomatic for the name of the variable containing
> the pointer to the object in QOM code ("git grep '\Wself\W' hw"
> shows no uses of it at all, which is quite unusual for us --
> usually the codebase has at least a few uses of any non-standard
> way of writing something ;-))
>
> Usually we use something approximating to the abbreviation
> of the type name, so here 'smm' would do.

I would prefer something more straightforward than having to come up
with various name mangling.

Imho, we loose some readability, consistency & semantic by not naming
the object argument of the method "self"

>
> > +
> > +object_initialize_child(o, "serial", >serial, 
> > sizeof(self->serial),
> > +TYPE_SERIAL, _abort, NULL);
> >  }
>
> thanks
> -- PMM
>

Re: [PATCH 5/5] hw/ppc/pnv_xscom: add PBA BARs for Power8 slw image

[Cédric Le Goater]

On 19/11/2019 18:50, Balamuruhan S wrote:
> slw base and size mask are accessed during boot in homer_init_chip(),
> so include BAR2 and BARMASK2 for Power8.
> 
> Signed-off-by: Balamuruhan S 
> ---
>  hw/ppc/pnv_xscom.c   | 10 --
>  include/hw/ppc/pnv.h |  4 
>  2 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/ppc/pnv_xscom.c b/hw/ppc/pnv_xscom.c
> index f797a5ec7d..828a2e2a5a 100644
> --- a/hw/ppc/pnv_xscom.c
> +++ b/hw/ppc/pnv_xscom.c
> @@ -38,8 +38,10 @@
>  
>  /* PBA BARs */
>  #define P8_PBA_BAR0 0x2013f00
> +#define P8_PBA_BAR2 0x2013f02
>  #define P8_PBA_BAR3 0x2013f03
>  #define P8_PBA_BARMASK0 0x2013f04
> +#define P8_PBA_BARMASK2 0x2013f06

and you add the definitions back ! :)

>  #define P8_PBA_BARMASK3 0x2013f07
>  #define P9_PBA_BAR0 0x5012b00
>  #define P9_PBA_BAR2 0x5012b02
> @@ -49,6 +51,7 @@
>  /* Mask to calculate Homer/Occ size */
>  #define HOMER_SIZE_MASK 0x0030ull
>  #define OCC_SIZE_MASK   0x0070ull
> +#define SLW_SIZE_MASK   0x0
>  
>  static void xscom_complete(CPUState *cs, uint64_t hmer_bits)
>  {
> @@ -115,6 +118,11 @@ static uint64_t xscom_read_default(PnvChip *chip, 
> uint32_t pcba)
>  }
>  return 0;
>  
> +case P8_PBA_BAR2: /* P8 slw image */
> +return PNV_SLW_IMAGE_BASE(chip);
> +case P8_PBA_BARMASK2: /* P8 slw image size is 1MB and mask is zero*/
> +return SLW_SIZE_MASK;

We need a HOMER XSCOM region.

> +
>  case 0x1010c00: /* PIBAM FIR */
>  case 0x1010c03: /* PIBAM FIR MASK */
>  
> @@ -135,9 +143,7 @@ static uint64_t xscom_read_default(PnvChip *chip, 
> uint32_t pcba)
>  case 0x202000f: /* ADU stuff, receive status register*/
>  return 0;
>  case 0x2013f01: /* PBA stuff */
> -case 0x2013f02: /* PBA stuff */
>  case 0x2013f05: /* PBA stuff */
> -case 0x2013f06: /* PBA stuff */
>  return 0;
>  case 0x2013028: /* CAPP stuff */
>  case 0x201302a: /* CAPP stuff */
> diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
> index e9ed8b928a..bd22dbf8a9 100644
> --- a/include/hw/ppc/pnv.h
> +++ b/include/hw/ppc/pnv.h
> @@ -212,6 +212,10 @@ void pnv_bmc_powerdown(IPMIBmc *bmc);
>  #define PNV_HOMER_BASE(chip)\
>  (0x7ffd80ull + ((uint64_t)PNV_CHIP_INDEX(chip)) * PNV_HOMER_SIZE)
>  
> +#define PNV_SLW_SIZE0x0010ull
> +#define PNV_SLW_IMAGE_BASE(chip)\
> +(0x2ffda0ull + ((uint64_t)PNV_CHIP_INDEX(chip)) * PNV_SLW_SIZE)
> +
>  
>  /*
>   * XSCOM 0x20109CA defines the ICP BAR:
> 

Re: [PATCH 4/5] hw/ppc/pnv_xscom: occ common area to be mapped only once

[Cédric Le Goater]

On 19/11/2019 18:50, Balamuruhan S wrote:
> occ common area should be mapped once 

It's the same address on each chip. 

the question is how the HW knows from which chip the OCC access is 
being done ? How does it target the correct OCC if the address is 
the same ? 

> and disable it for every other chip.

On P8 OpenPOWER systems, the PBA3 registers are still set, not on
tuletas though (different hostboot I suppose). On OpenPOWER systems,
they are still set also.
 
> Signed-off-by: Cédric Le Goater 

nah. I didn't write any of this :) 

> Signed-off-by: Balamuruhan S 
> ---
>  hw/ppc/pnv_xscom.c | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/ppc/pnv_xscom.c b/hw/ppc/pnv_xscom.c
> index cb6d6bbcfc..f797a5ec7d 100644
> --- a/hw/ppc/pnv_xscom.c
> +++ b/hw/ppc/pnv_xscom.c
> @@ -98,13 +98,22 @@ static uint64_t xscom_read_default(PnvChip *chip, 
> uint32_t pcba)
>  return HOMER_SIZE_MASK;
>  
>  case P9_PBA_BAR2: /* P9 occ common area */
> -return PNV9_OCC_COMMON_AREA(chip);
> +if (!PNV_CHIP_INDEX(chip)) {

Yes that it is the idea. XIVE uses directly 'chip->chip_id'. 


> +return PNV9_OCC_COMMON_AREA(chip);
> +}
> +return 0;
>  case P8_PBA_BAR3: /* P8 occ common area */
> -return PNV_OCC_COMMON_AREA(chip);
> +if (!PNV_CHIP_INDEX(chip)) {
> +return PNV_OCC_COMMON_AREA(chip);
> +}
> +return 0;
>  
>  case P9_PBA_BARMASK2: /* P9 occ common area size */
>  case P8_PBA_BARMASK3: /* P8 occ common area size */
> -return OCC_SIZE_MASK;
> +if (!PNV_CHIP_INDEX(chip)) {
> +return OCC_SIZE_MASK;
> +}
> +return 0;
>  
>  case 0x1010c00: /* PIBAM FIR */
>  case 0x1010c03: /* PIBAM FIR MASK */
> 

Re: [PATCH 2/5] hw/ppc/pnv_xscom: PBA bar mask values are incorrect with homer/occ sizes

[Cédric Le Goater]

On 19/11/2019 18:50, Balamuruhan S wrote:
> homer/occ sizes are calculated in skiboot with `(mask | 0xf) + 1`,
> and from xscom access should return correct mask values instead of actual
> sizes.
> 
> Signed-off-by: Cédric Le Goater 
> Signed-off-by: Balamuruhan S 
> ---
>  hw/ppc/pnv_xscom.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/ppc/pnv_xscom.c b/hw/ppc/pnv_xscom.c
> index f01d788a65..cdd5fa356e 100644
> --- a/hw/ppc/pnv_xscom.c
> +++ b/hw/ppc/pnv_xscom.c
> @@ -46,6 +46,10 @@
>  #define P9_PBA_BARMASK0 0x5012b04
>  #define P9_PBA_BARMASK2 0x5012b06
>  
> +/* Mask to calculate Homer/Occ size */
> +#define HOMER_SIZE_MASK 0x0030ull
> +#define OCC_SIZE_MASK   0x0070ull
> +

Can't we deduce these values from the size ? 

>  static void xscom_complete(CPUState *cs, uint64_t hmer_bits)
>  {
>  /*
> @@ -90,9 +94,8 @@ static uint64_t xscom_read_default(PnvChip *chip, uint32_t 
> pcba)
>  return PNV_HOMER_BASE(chip);
>  
>  case P9_PBA_BARMASK0: /* P9 homer region size */
> -return PNV9_HOMER_SIZE;
>  case P8_PBA_BARMASK0: /* P8 homer region size */
> -return PNV_HOMER_SIZE;
> +return HOMER_SIZE_MASK;

I would prefer to move all the HOMER accesses in a XSCOM region
under the PnvHomer model than expanding the default handlers. 
You will need a different set of handlers for P8 and P9 and a 
different mapping address also. 

Could you do that please ? 
  
>  case P9_PBA_BAR2: /* P9 occ common area */
>  return PNV9_OCC_COMMON_AREA(chip);
> @@ -100,9 +103,8 @@ static uint64_t xscom_read_default(PnvChip *chip, 
> uint32_t pcba)
>  return PNV_OCC_COMMON_AREA(chip);
>  
>  case P9_PBA_BARMASK2: /* P9 occ common area size */
> -return PNV9_OCC_COMMON_AREA_SIZE;
>  case P8_PBA_BARMASK2: /* P8 occ common area size */

Shouldn't that be PBA_*3 under P8 ? 

C. 

> -return PNV_OCC_COMMON_AREA_SIZE;
> +return OCC_SIZE_MASK;
>  
>  case 0x1010c00: /* PIBAM FIR */
>  case 0x1010c03: /* PIBAM FIR MASK */
> 

Re: [PATCH 3/5] hw/ppc/pnv_xscom: Power8 occ common area is in PBA BAR 3

[Cédric Le Goater]

On 19/11/2019 18:50, Balamuruhan S wrote:
> Fix incorrect PBA BAR and BARMASK value for Power8 occ common area
> region where skiboot enum declaration have it in BAR 3 and BARMASK
> is calculated BARMASK0 + BAR,
> 
> enum P8_BAR {
> P8_BAR_HOMER = 0,
> P8_BAR_CENTAUR = 1,
> P8_BAR_SLW = 2,
> P8_BAR_OCC_COMMON = 3,
> };
> 
> Signed-off-by: Cédric Le Goater 

Please remove my SoB.

> Signed-off-by: Balamuruhan S 
> ---
>  hw/ppc/pnv_xscom.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/hw/ppc/pnv_xscom.c b/hw/ppc/pnv_xscom.c
> index cdd5fa356e..cb6d6bbcfc 100644
> --- a/hw/ppc/pnv_xscom.c
> +++ b/hw/ppc/pnv_xscom.c
> @@ -38,9 +38,9 @@
>  
>  /* PBA BARs */
>  #define P8_PBA_BAR0 0x2013f00
> -#define P8_PBA_BAR2 0x2013f02
> +#define P8_PBA_BAR3 0x2013f03
>  #define P8_PBA_BARMASK0 0x2013f04
> -#define P8_PBA_BARMASK2 0x2013f06
> +#define P8_PBA_BARMASK3 0x2013f07

Why are you removing the BAR2 definitions ? they are still valid.


>  #define P9_PBA_BAR0 0x5012b00
>  #define P9_PBA_BAR2 0x5012b02
>  #define P9_PBA_BARMASK0 0x5012b04
> @@ -99,11 +99,11 @@ static uint64_t xscom_read_default(PnvChip *chip, 
> uint32_t pcba)
>  
>  case P9_PBA_BAR2: /* P9 occ common area */
>  return PNV9_OCC_COMMON_AREA(chip);
> -case P8_PBA_BAR2: /* P8 occ common area */
> +case P8_PBA_BAR3: /* P8 occ common area */
>  return PNV_OCC_COMMON_AREA(chip);
>  
>  case P9_PBA_BARMASK2: /* P9 occ common area size */
> -case P8_PBA_BARMASK2: /* P8 occ common area size */
> +case P8_PBA_BARMASK3: /* P8 occ common area size */
>  return OCC_SIZE_MASK;
>  
>  case 0x1010c00: /* PIBAM FIR */
> @@ -126,9 +126,9 @@ static uint64_t xscom_read_default(PnvChip *chip, 
> uint32_t pcba)
>  case 0x202000f: /* ADU stuff, receive status register*/
>  return 0;
>  case 0x2013f01: /* PBA stuff */
> -case 0x2013f03: /* PBA stuff */
> +case 0x2013f02: /* PBA stuff */
>  case 0x2013f05: /* PBA stuff */
> -case 0x2013f07: /* PBA stuff */
> +case 0x2013f06: /* PBA stuff */

We need defines for the above ^

>  return 0;
>  case 0x2013028: /* CAPP stuff */
>  case 0x201302a: /* CAPP stuff */
> 

Re: [PATCH 1/5] hw/ppc/pnv: incorrect homer and occ common area size

[Cédric Le Goater]

On 19/11/2019 18:50, Balamuruhan S wrote:
> Homer size is 4MB and OCC common area size is 8MB, but currently
> it is assigned with bar mask value. Also pass on the occ sram
> size 3 bits right shifted to initialize the size appropriately.
> 
> Signed-off-by: Cédric Le Goater 
> Signed-off-by: Balamuruhan S 
> ---
>  hw/ppc/pnv_occ.c | 2 +-
>  include/hw/ppc/pnv.h | 8 
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/ppc/pnv_occ.c b/hw/ppc/pnv_occ.c
> index 785653bb67..05c51c9de0 100644
> --- a/hw/ppc/pnv_occ.c
> +++ b/hw/ppc/pnv_occ.c
> @@ -276,7 +276,7 @@ static void pnv_occ_realize(DeviceState *dev, Error 
> **errp)
>  
>  /* XScom region for OCC SRAM registers */
>  pnv_xscom_region_init(>sram_regs, OBJECT(dev), poc->sram_ops,
> -  occ, "occ-common-area", poc->sram_size);
> +  occ, "occ-common-area", poc->sram_size >> 3);

the OCC common area seems to be accessed through MMIO also. Not only XSCOM.

In skiboot  : 

bool occ_sensors_init(void)
{
...
occ_sensor_base = chip->occ_common_base + OCC_SENSOR_DATA_BLOCK_OFFSET;
...
}

OCC would need two regions. One for the XSCOM access and one for the MMIO.

>  }
>  
>  static void pnv_occ_class_init(ObjectClass *klass, void *data)
> diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
> index 0b4c722e6b..e9ed8b928a 100644
> --- a/include/hw/ppc/pnv.h
> +++ b/include/hw/ppc/pnv.h
> @@ -203,12 +203,12 @@ void pnv_bmc_powerdown(IPMIBmc *bmc);
>  #define PNV_XSCOM_BASE(chip)\
>  (0x0003fc00ull + ((uint64_t)(chip)->chip_id) * PNV_XSCOM_SIZE)
>  
> -#define PNV_OCC_COMMON_AREA_SIZE0x0070ull
> +#define PNV_OCC_COMMON_AREA_SIZE0x0080ull

ok. These are the BAR sizes. Can we deduce the barmask from the size ? 


>  #define PNV_OCC_COMMON_AREA(chip)   \
>  (0x7fff80ull + ((uint64_t)PNV_CHIP_INDEX(chip) * \
>   PNV_OCC_COMMON_AREA_SIZE))
>  
> -#define PNV_HOMER_SIZE  0x0030ull
> +#define PNV_HOMER_SIZE  0x0040ull
>  #define PNV_HOMER_BASE(chip)\
>  (0x7ffd80ull + ((uint64_t)PNV_CHIP_INDEX(chip)) * PNV_HOMER_SIZE)
>  
> @@ -271,12 +271,12 @@ void pnv_bmc_powerdown(IPMIBmc *bmc);
>  #define PNV9_XSCOM_SIZE  0x0004ull
>  #define PNV9_XSCOM_BASE(chip)PNV9_CHIP_BASE(chip, 
> 0x00603fcull)
>  
> -#define PNV9_OCC_COMMON_AREA_SIZE0x0070ull
> +#define PNV9_OCC_COMMON_AREA_SIZE0x0080ull
>  #define PNV9_OCC_COMMON_AREA(chip)  \
>  (0x203fff80ull + ((uint64_t)PNV_CHIP_INDEX(chip) * \
> PNV9_OCC_COMMON_AREA_SIZE))
>  
> -#define PNV9_HOMER_SIZE  0x0030ull
> +#define PNV9_HOMER_SIZE  0x0040ull
>  #define PNV9_HOMER_BASE(chip)   \
>  (0x203ffd80ull + ((uint64_t)PNV_CHIP_INDEX(chip)) * PNV9_HOMER_SIZE)
>  #endif /* PPC_PNV_H */
> 

[Bug 1853083] Re: qemu ppc64 4.0 boot AIX5.1 hung

[Thomas Huth]

AIX 5.1 is quite a bit older than POWER8, so I don't think that it will
run with this processor anymore. You could try "power5" or "970fx" as
CPU (maybe even the "40p" machine instead of "pseries"), but I guess it
won't make a big difference - the QEMU pseries machine has been written
for later operating systems in mind, there was never a big effort to get
older operating systems running with it.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1853083

Title:
  qemu ppc64 4.0 boot AIX5.1 hung

Status in QEMU:
  Incomplete

Bug description:
  When boot AIX5.1 from cdrom device, qemu hung there, no further info
  is displayed and cpu consumption is high.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1853083/+subscriptions

Re: [PATCH v16 09/14] numa: Extend CLI to provide memory side cache information

[Tao Xu]

On 11/19/2019 7:47 PM, Igor Mammedov wrote:

On Fri, 15 Nov 2019 15:53:47 +0800
Tao Xu  wrote:


From: Liu Jingqi 

Add -numa hmat-cache option to provide Memory Side Cache Information.
These memory attributes help to build Memory Side Cache Information
Structure(s) in ACPI Heterogeneous Memory Attribute Table (HMAT).

Reviewed-by: Daniel Black 
Signed-off-by: Liu Jingqi 
Signed-off-by: Tao Xu 
---

Changes in v16:
 - Add cross check with hmat_lb data (Igor)
 - Drop total_levels in struct HMAT_Cache_Info (Igor)
 - Correct the error table number (Igor)

Changes in v15:
 - Change the QAPI version tag to 5.0 (Eric)

Changes in v13:
 - Drop the total_levels option.
 - Use readable cache size (Igor)
---
  hw/core/numa.c| 73 
  include/sysemu/numa.h | 26 +++
  qapi/machine.json | 78 +--
  qemu-options.hx   | 16 +++--
  4 files changed, 189 insertions(+), 4 deletions(-)

diff --git a/hw/core/numa.c b/hw/core/numa.c
index 47c7a96863..4d7af60bfd 100644
--- a/hw/core/numa.c
+++ b/hw/core/numa.c
@@ -359,6 +359,66 @@ void parse_numa_hmat_lb(NumaState *numa_state, 
NumaHmatLBOptions *node,
  g_array_append_val(hmat_lb->list, lb_data);
  }
  
+void parse_numa_hmat_cache(MachineState *ms, NumaHmatCacheOptions *node,

+   Error **errp)
+{
+int nb_numa_nodes = ms->numa_state->num_nodes;
+NodeInfo *numa_info = ms->numa_state->nodes;
+HMAT_Cache_Info *hmat_cache = NULL;
+
+if (node->node_id >= nb_numa_nodes) {
+error_setg(errp, "Invalid node-id=%" PRIu32 ", it should be less "
+   "than %d", node->node_id, nb_numa_nodes);
+return;
+}
+
+if (numa_info[node->node_id].lb_info_provided != (BIT(0) | BIT(1))) {
+error_setg(errp, "The latency and bandwidth information of "
+   "node-id=%" PRIu32 " should be provided before configure "


s/configure//


+   "memory side cache attributes",
+   node->node_id);
+return;
+}
+
+if (node->level >= HMAT_LB_LEVELS) {
+error_setg(errp, "Invalid level=%" PRIu8 ", it should be less than or "
+   "equal to %d", node->level, HMAT_LB_LEVELS - 1);
+return;
+}
+assert(node->assoc < HMAT_CACHE_ASSOCIATIVITY__MAX);
+assert(node->policy < HMAT_CACHE_WRITE_POLICY__MAX);
+if (ms->numa_state->hmat_cache[node->node_id][node->level]) {
+error_setg(errp, "Duplicate configuration of the side cache for "
+   "node-id=%" PRIu32 " and level=%" PRIu8,
+   node->node_id, node->level);
+return;
+}
+
+if ((node->level > 1) &&
+ms->numa_state->hmat_cache[node->node_id][node->level - 1] &&

will this check work as expected if I define on CLI "L+1" and then after it "L"?



No, I will fix it.

+(node->size >=
+ms->numa_state->hmat_cache[node->node_id][node->level - 1]->size)) 
{
+error_setg(errp, "Invalid size=0x%" PRIx64 ", the size of level=%" 
PRIu8
+   " should be less than the size(0x%" PRIx64 ") of "
+   "level=%" PRIu8, node->size, node->level,
+   ms->numa_state->hmat_cache[node->node_id]
+ [node->level - 1]->size,
+   node->level - 1);
+return;
+}
+
+hmat_cache = g_malloc0(sizeof(*hmat_cache));
+
+hmat_cache->proximity = node->node_id;
+hmat_cache->size = node->size;
+hmat_cache->level = node->level;
+hmat_cache->associativity = node->assoc;
+hmat_cache->write_policy = node->policy;
+hmat_cache->line_size = node->line;
+
+ms->numa_state->hmat_cache[node->node_id][node->level] = hmat_cache;
+}
+
  void set_numa_options(MachineState *ms, NumaOptions *object, Error **errp)
  {
  Error *err = NULL;
@@ -410,6 +470,19 @@ void set_numa_options(MachineState *ms, NumaOptions 
*object, Error **errp)
  goto end;
  }
  break;
+case NUMA_OPTIONS_TYPE_HMAT_CACHE:
+if (!ms->numa_state->hmat_enabled) {
+error_setg(errp, "ACPI Heterogeneous Memory Attribute Table "
+   "(HMAT) is disabled, enable it with -machine hmat=on "
+   "before using any of hmat specific options");
+return;
+}
+
+parse_numa_hmat_cache(ms, >u.hmat_cache, );
+if (err) {
+goto end;
+}
+break;
  default:
  abort();
  }
diff --git a/include/sysemu/numa.h b/include/sysemu/numa.h
index 70f93c83d7..b415550678 100644
--- a/include/sysemu/numa.h
+++ b/include/sysemu/numa.h
@@ -76,6 +76,27 @@ struct HMAT_LB_Info {
  };
  typedef struct HMAT_LB_Info HMAT_LB_Info;
  
+struct HMAT_Cache_Info {

+/* The memory proximity domain to which the memory belongs. */
+uint32_tproximity;
+
+/* Size of memory side 

Re: [RFC 5/5] spapr: Work around spurious warnings from vfio INTx initialization

[Cédric Le Goater]

On 20/11/2019 05:17, David Gibson wrote:
> On Thu, Oct 17, 2019 at 03:42:06PM +0200, Cédric Le Goater wrote:
>> On 17/10/2019 10:43, Cédric Le Goater wrote:
>>> On 17/10/2019 07:42, David Gibson wrote:
 Traditional PCI INTx for vfio devices can only perform well if using
 an in-kernel irqchip.  Therefore, vfio_intx_update() issues a warning
 if an in kernel irqchip is not available.

 We usually do have an in-kernel irqchip available for pseries machines
 on POWER hosts.  However, because the platform allows feature
 negotiation of what interrupt controller model to use, we don't
 currently initialize it until machine reset.  vfio_intx_update() is
 called (first) from vfio_realize() before that, so it can issue a
 spurious warning, even if we will have an in kernel irqchip by the
 time we need it.

 To workaround this, make a call to spapr_irq_update_active_intc() from
 spapr_irq_init() which is called at machine realize time, before the
 vfio realize.  This call will be pretty much obsoleted by the later
 call at reset time, but it serves to suppress the spurious warning
 from VFIO.

 Cc: Alex Williamson 
 Cc: Alexey Kardashevskiy 

 Signed-off-by: David Gibson 
 ---
  hw/ppc/spapr_irq.c | 11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)

 diff --git a/hw/ppc/spapr_irq.c b/hw/ppc/spapr_irq.c
 index 45544b8976..bb91c61fa0 100644
 --- a/hw/ppc/spapr_irq.c
 +++ b/hw/ppc/spapr_irq.c
 @@ -345,6 +345,14 @@ void spapr_irq_init(SpaprMachineState *spapr, Error 
 **errp)
  
  spapr->qirqs = qemu_allocate_irqs(spapr_set_irq, spapr,
smc->nr_xirqs + SPAPR_XIRQ_BASE);
 +
 +/*
 + * Mostly we don't actually need this until reset, except that not
 + * having this set up can cause VFIO devices to issue a
 + * false-positive warning during realize(), because they don't yet
 + * have an in-kernel irq chip.
 + */
 +spapr_irq_update_active_intc(spapr);
>>>
>>> This will call the de/activate hooks of the irq chip very early 
>>> before reset and CAS, and won't call them at reset if the intc
>>> pointers are the same (xive only for instance). It breaks very 
>>> obviously the emulated XIVE device which won't reset the OS CAM 
>>> line with the CPU id values and CPU notification will be broken.
>>>
>>> We have to find something else.
>>
>> Here is a possible fix for the (re)setting of the OS CAM line. 
>>
>> Removing spapr_xive_set_tctx_os_cam() is a good thing but this solution
>> shows some issues in our modeling of hot-plugged CPUS with a reset() 
>> being called at realize().
> 
> Ok, I've applied the patch below now. 

Yes. this was replaced by :

  http://patchwork.ozlabs.org/cover/1181522/

> Does that mean that my 5/5 patch should be good now?

We should.

C.

Re: [PATCH v2] virtio-pci: disable vring processing when bus-mastering is disabled

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20191120005003.27035-1-mdr...@linux.vnet.ibm.com/



Hi,

This series failed the docker-quick@centos7 build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-centos7 V=1 NETWORK=1
time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===

  TESTcheck-unit: tests/test-thread-pool
wait_for_migration_fail: unexpected status status=wait-unplug allow_active=1
**
ERROR:/tmp/qemu-test/src/tests/migration-test.c:908:wait_for_migration_fail: 
assertion failed: (result)
ERROR - Bail out! 
ERROR:/tmp/qemu-test/src/tests/migration-test.c:908:wait_for_migration_fail: 
assertion failed: (result)
make: *** [check-qtest-aarch64] Error 1
make: *** Waiting for unfinished jobs
  TESTcheck-unit: tests/test-hbitmap
  TESTcheck-unit: tests/test-bdrv-drain
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', 
'--label', 'com.qemu.instance.uuid=c863e15882a747a88c290575505cc1de', '-u', 
'1001', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', 
'-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 
'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', 
'/home/patchew/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', 
'/var/tmp/patchew-tester-tmp-wg70rgpu/src/docker-src.2019-11-20-01.02.57.12412:/var/tmp/qemu:z,ro',
 'qemu:centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit 
status 2.
filter=--filter=label=com.qemu.instance.uuid=c863e15882a747a88c290575505cc1de
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-wg70rgpu/src'
make: *** [docker-run-test-quick@centos7] Error 2

real9m13.236s
user0m8.131s


The full log is available at
http://patchew.org/logs/20191120005003.27035-1-mdr...@linux.vnet.ibm.com/testing.docker-quick@centos7/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

[Bug 1853083] Re: qemu ppc64 4.0 boot AIX5.1 hung

[wzis]

I'm running this to start the AIX5.1 installation on qemu:
#!/bin/bash
qemu-system-ppc64 -cpu POWER8 -machine pseries -m 2048 -serial mon:stdio  -hda 
aix-hdd.qcow2 -cdrom /Download/AIX5.1/VOLUME1.iso -prom-env boot-command='boot 
cdrom: -s verbose'

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1853083

Title:
  qemu ppc64 4.0 boot AIX5.1 hung

Status in QEMU:
  Incomplete

Bug description:
  When boot AIX5.1 from cdrom device, qemu hung there, no further info
  is displayed and cpu consumption is high.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1853083/+subscriptions

[Bug 1853083] Re: qemu ppc64 4.0 boot AIX5.1 hung

[wzis]

and it got:
[root@192 emu]# ./aix51
VNC server running on ::1:5900
qemu-system-ppc64: warning: TCG doesn't support requested feature, 
cap-cfpc=workaround
qemu-system-ppc64: warning: TCG doesn't support requested feature, 
cap-sbbc=workaround
qemu-system-ppc64: warning: TCG doesn't support requested feature, 
cap-ibs=workaround


SLOF **
QEMU Starting
 Build Date = Jul  3 2019 12:26:14
 FW Version = git-ba1ab360eebe6338
 Press "s" to enter Open Firmware.

Populating /vdevice methods
Populating /vdevice/vty@7100
Populating /vdevice/nvram@7101
Populating /vdevice/l-lan@7102
Populating /vdevice/v-scsi@7103
   SCSI: Looking for devices
  8000 DISK : "QEMU QEMU HARDDISK2.5+"
  8200 CD-ROM   : "QEMU QEMU CD-ROM  2.5+"
Populating /pci@8002000
 00  (D) : 1234 qemu vga
 00 0800 (D) : 1033 0194serial bus [ usb-xhci ]
Installing QEMU fb


Scanning USB
  XHCI: Initializing
USB Keyboard
USB mouse
No console specified using screen & keyboard

  Welcome to Open Firmware

  Copyright (c) 2004, 2017 IBM Corporation All rights reserved.
  This program and the accompanying materials are made available
  under the terms of the BSD License available at
  http://www.opensource.org/licenses/bsd-license.php


Trying to load: -s verbose from: 
/vdevice/v-scsi@7103/disk@8200: ...

and just hung there, took lots of CPU time, never proceed further.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1853083

Title:
  qemu ppc64 4.0 boot AIX5.1 hung

Status in QEMU:
  Incomplete

Bug description:
  When boot AIX5.1 from cdrom device, qemu hung there, no further info
  is displayed and cpu consumption is high.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1853083/+subscriptions

Re: [PULL for-4.2-rc2 0/2] Tracing patches

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20191119204551.240792-1-stefa...@redhat.com/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Subject: [PULL for-4.2-rc2 0/2] Tracing patches
Type: series
Message-id: 20191119204551.240792-1-stefa...@redhat.com

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Switched to a new branch 'test'

=== OUTPUT BEGIN ===
checkpatch.pl: no revisions returned for revlist '1'
=== OUTPUT END ===

Test command exited with code: 255


The full log is available at
http://patchew.org/logs/20191119204551.240792-1-stefa...@redhat.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [PATCH v4 17/19] spapr: Remove last pieces of SpaprIrq

[David Gibson]

On Mon, Oct 14, 2019 at 11:15:16AM +0200, Greg Kurz wrote:
> On Sat, 12 Oct 2019 11:00:41 +1100
> David Gibson  wrote:
> 
> > On Fri, Oct 11, 2019 at 08:13:33AM +0200, Greg Kurz wrote:
> > > On Fri, 11 Oct 2019 16:07:58 +1100
> > > David Gibson  wrote:
> > > 
> > > > On Thu, Oct 10, 2019 at 10:33:04PM +0200, Greg Kurz wrote:
> > > > > On Thu, 10 Oct 2019 08:29:58 +0200
> > > > > Greg Kurz  wrote:
> > > > > 
> > > > > > On Thu, 10 Oct 2019 13:02:09 +1100
> > > > > > David Gibson  wrote:
> > > > > > 
> > > > > > > On Wed, Oct 09, 2019 at 07:02:15PM +0200, Greg Kurz wrote:
> > > > > > > > On Wed,  9 Oct 2019 17:08:16 +1100
> > > > > > > > David Gibson  wrote:
> > > > > > > > 
> > > > > > > > > The only thing remaining in this structure are the flags to 
> > > > > > > > > allow either
> > > > > > > > > XICS or XIVE to be present.  These actually make more sense 
> > > > > > > > > as spapr
> > > > > > > > > capabilities - that way they can take advantage of the 
> > > > > > > > > existing
> > > > > > > > > infrastructure to sanity check capability states across 
> > > > > > > > > migration and so
> > > > > > > > > forth.
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > The user can now choose the interrupt controller mode either 
> > > > > > > > through
> > > > > > > > ic-mode or through cap-xics/cap-xive. I guess it doesn't break 
> > > > > > > > anything
> > > > > > > > to expose another API to do the same thing but it raises some 
> > > > > > > > questions.
> > > > > > > > 
> > > > > > > > We should at least document somewhere that ic-mode is an alias 
> > > > > > > > to these
> > > > > > > > caps, and maybe state which is the preferred method (I 
> > > > > > > > personally vote
> > > > > > > > for the caps).
> > > > > > > > 
> > > > > > > > Also, we must keep ic-mode for the moment to stay compatible 
> > > > > > > > with the
> > > > > > > > existing pseries-4.0 and pseries-4.1 machine types, but will we
> > > > > > > > keep ic-mode forever ? If no, maybe start by not allowing it for
> > > > > > > > pseries-4.2 ?
> > > > > > > 
> > > > > > > I'm actually inclined to keep it for now, maybe even leave it as 
> > > > > > > the
> > > > > > > suggested way to configure this.  The caps are nice from an 
> > > > > > > internal
> > > > > > > organization point of view, but ic-mode is arguably a more user
> > > > > > > friendly way of configuring it.  The conversion of one to the 
> > > > > > > other is
> > > > > > > straightforward, isolated ans small, so I'm not especially 
> > > > > > > bothered by
> > > > > > > keeping it around.
> > > > > > > 
> > > > > > 
> > > > > > Fair enough.
> > > > > > 
> > > > > > Reviewed-by: Greg Kurz 
> > > > > > 
> > > > > 
> > > > > But unfortunately this still requires care :-\
> > > > > 
> > > > > qemu-system-ppc64: cap-xive higher level (1) in incoming stream than 
> > > > > on destination (0)
> > > > > qemu-system-ppc64: error while loading state for instance 0x0 of 
> > > > > device 'spapr'
> > > > > qemu-system-ppc64: load of migration failed: Invalid argument
> > > > > 
> > > > > or
> > > > > 
> > > > > qemu-system-ppc64: cap-xics higher level (1) in incoming stream than 
> > > > > on destination (0)
> > > > > qemu-system-ppc64: error while loading state for instance 0x0 of 
> > > > > device 'spapr'
> > > > > qemu-system-ppc64: load of migration failed: Invalid argument
> > > > > 
> > > > > when migrating from QEMU 4.1 with ic-mode=xics and ic-mode=xive 
> > > > > respectively.
> > > > > 
> > > > > This happens because the existing pseries-4.1 machine type doesn't 
> > > > > send the
> > > > > new caps and the logic in spapr_caps_post_migration() wrongly assumes 
> > > > > that
> > > > > the source has both caps set:
> > > > > 
> > > > > srccaps = default_caps_with_cpu(spapr, MACHINE(spapr)->cpu_type);
> > > > > for (i = 0; i < SPAPR_CAP_NUM; i++) {
> > > > > /* If not default value then assume came in with the 
> > > > > migration */
> > > > > if (spapr->mig.caps[i] != spapr->def.caps[i]) {
> > > > > 
> > > > > spapr->mig.caps[SPAPR_CAP_XICS] = 0
> > > > > spapr->mig.caps[SPAPR_CAP_XIVE] = 0
> > > > > 
> > > > > srccaps.caps[i] = spapr->mig.caps[i];
> > > > > 
> > > > > srcaps.caps[SPAPR_CAP_XICS] = 1
> > > > > srcaps.caps[SPAPR_CAP_XIVE] = 1
> > > > > 
> > > > > }
> > > > > }
> > > > > 
> > > > > and breaks
> > > > > 
> > > > > for (i = 0; i < SPAPR_CAP_NUM; i++) {
> > > > > SpaprCapabilityInfo *info = _table[i];
> > > > > 
> > > > > if (srccaps.caps[i] > dstcaps.caps[i]) {
> > > > > 
> > > > > srcaps.caps[SPAPR_CAP_XICS] = 0 when ic-mode=xive
> > > > > srcaps.caps[SPAPR_CAP_XIVE] = 0 when ic-mode=xics
> > > > > 
> > > > > error_report("cap-%s higher level (%d) in incoming stream 
> > > > > than on destination (%d)",
> > > > >  info->name, srccaps.caps[i], 
> > > > > dstcaps.caps[i]);
> > > > > ok = false;
> > > > > }
> > > > 
> > > > Ah.. right.  

Re: [PATCH] exynos4210_gic: Suppress gcc9 format-truncation warnings

[David Gibson]

On Mon, Oct 14, 2019 at 01:51:39PM +0100, Peter Maydell wrote:
> On Fri, 4 Oct 2019 at 04:10, David Gibson  wrote:
> >
> > exynos4210_gic_realize() prints the number of cpus into some temporary
> > buffers, but it only allows 3 bytes space for it.  That's plenty - I'm
> > pretty sure that existing machines will only ever set this value to 2
> > (EXYNOS4210_NCPUS).  But the compiler can't really be expected to figure
> > that out.
> >
> > Some[*] gcc9 versions therefore emit -Wformat-truncation warnings.  Fix
> > that by allowing more space in the temporary buffers - these are on stack
> > very briefly before being essentially strdup()ed inside the memory region
> > code, so there's not much cost to doing so.
> >
> > [*] The bizarre thing here, is that I've long gotten these warnings
> > compiling in a 32-bit x86 container as host - Fedora 30 with
> > gcc-9.2.1-1.fc30.i686 - but it compiles just fine on my normal x86_64 host
> > - Fedora 30 with and gcc-9.2.1-1.fc30.x86_64.
> >
> > Signed-off-by: David Gibson 
> > ---
> >  hw/intc/exynos4210_gic.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/hw/intc/exynos4210_gic.c b/hw/intc/exynos4210_gic.c
> > index a1b699b6ba..2e5e47f9ec 100644
> > --- a/hw/intc/exynos4210_gic.c
> > +++ b/hw/intc/exynos4210_gic.c
> > @@ -290,8 +290,8 @@ static void exynos4210_gic_realize(DeviceState *dev, 
> > Error **errp)
> >  SysBusDevice *sbd = SYS_BUS_DEVICE(obj);
> >  const char cpu_prefix[] = "exynos4210-gic-alias_cpu";
> >  const char dist_prefix[] = "exynos4210-gic-alias_dist";
> > -char cpu_alias_name[sizeof(cpu_prefix) + 3];
> > -char dist_alias_name[sizeof(cpu_prefix) + 3];
> > +char cpu_alias_name[sizeof(cpu_prefix) + 10];
> > +char dist_alias_name[sizeof(cpu_prefix) + 10];
> >  SysBusDevice *gicbusdev;
> >  uint32_t i;
> 
> If we assert() that num_cpu is always <= EXYNOS4210_NCPUS
> is that sufficient to clue gcc in that the buffer can't overflow?

Interestingly, assert(s->num_cpu <= EXYNOS$210_NCPUS) is *not*
sufficient, but assert(i <= EXYNOS4210_NCPUS) within the loop *is*
enough.  I've updated my patch accordingly.

This isn't 4.2 material, obviously.  Should I just sit on it until 5.0
opens, or does one of you have someplace to stage the patch in the
meanwhile?

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

RE: [PATCH] Hexagon: Swap SIGRGMAX-1 and SIGRTMIN+1

[Taylor Simpson]

Peter,

Yeah, I was surprised not to see other targets encountering this problem.  
However, I don't understand how something under #ifdef TARGET_HEXAGON can break 
anything else.

Could you point me to the patch set you mention?

One generic solution I can think of is to reference a target-defined macro in 
linux-user/signal.c and let targets optionally define it in their 
target_signal.h.  So, it would look something like this
> @@ -72,6 +72,14 @@ static uint8_t host_to_target_signal_table[_NSIG] = {
> over a single host signal.  */
>  [__SIGRTMIN] = __SIGRTMAX,
>  [__SIGRTMAX] = __SIGRTMIN,
> +#ifdef TARGET_SIGNAL_TABLE_MODIFY
> +TARGET_SIGNAL_TABLE_MODIFY

Thanks,
Taylor


-Original Message-
From: Peter Maydell 
Sent: Tuesday, November 19, 2019 1:31 PM
To: Taylor Simpson 
Cc: Riku Voipio ; Laurent Vivier ; QEMU 
Developers 
Subject: Re: [PATCH] Hexagon: Swap SIGRGMAX-1 and SIGRTMIN+1


On Tue, 19 Nov 2019 at 19:07, Taylor Simpson  wrote:
>
> Signed-off-by: Taylor Simpson 
> ---
>  linux-user/signal.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/linux-user/signal.c b/linux-user/signal.c index
> 5ca6d62..ce3d27f 100644
> --- a/linux-user/signal.c
> +++ b/linux-user/signal.c
> @@ -72,6 +72,14 @@ static uint8_t host_to_target_signal_table[_NSIG] = {
> over a single host signal.  */
>  [__SIGRTMIN] = __SIGRTMAX,
>  [__SIGRTMAX] = __SIGRTMIN,
> +#ifdef TARGET_HEXAGON
> +/*
> + * Hexagon uses the same signal for pthread cancel as the host pthreads,
> + * so cannot be overridden.
> + * Therefore, we map Hexagon signal to a different host signal.
> + */
> +[__SIGRTMAX - 1] = __SIGRTMIN + 1, #endif
>  };

This breaks other stuff, unfortunately, like Go binaries.
(Also, you now have two host signals mapped to the same target signal; notice 
that the existing RTMAX/RTMIN is a swap of the two slots.)

We need a generic solution for this, Hexagon is not the only one with the 
problem. There's a patchset on list from ages back that had a suggested 
approach, but it needed review and work.

thanks
-- PMM

RE: [PATCH] Add minimal Hexagon target - First in a series of patches - linux-user changes + linux-user/hexagon + skeleton of target/hexagon - Files in target/hexagon/imported are from another project

[Taylor Simpson]

Thanks for the feedback Richard.

Responses below ...

Thanks,
Taylor


-Original Message-
From: Richard Henderson 
Sent: Tuesday, November 19, 2019 1:34 PM
To: Taylor Simpson ; laur...@vivier.eu; 
riku.voi...@iki.fi; qemu-devel@nongnu.org
Subject: Re: [PATCH] Add minimal Hexagon target - First in a series of patches 
- linux-user changes + linux-user/hexagon + skeleton of target/hexagon - Files 
in target/hexagon/imported are from another project and therefore do not 
conform to qemu coding standards

-
CAUTION: This email originated from outside of the organization.
-

On 11/19/19 12:58 AM, Taylor Simpson wrote:
> +static abi_ulong get_sigframe(struct target_sigaction *ka,
> +  CPUHexagonState *regs, size_t
> +framesize) {
> +abi_ulong sp = get_sp_from_cpustate(regs);
> +
> +/* This is the X/Open sanctioned signal stack switching.  */
> +sp = target_sigsp(sp, ka) - framesize;
> +
> +sp &= ~7UL; /* align sp on 8-byte boundary */

QEMU_ALIGN_DOWN.

> diff --git a/linux-user/hexagon/sockbits.h
> b/linux-user/hexagon/sockbits.h new file mode 100644 index
> 000..85bd64a
> --- /dev/null
> +++ b/linux-user/hexagon/sockbits.h
> @@ -0,0 +1,3 @@
> +/* Copyright (c) 2019 Qualcomm Innovation Center, Inc. All Rights
> +Reserved. */
> +
> +#include "../generic/sockbits.h"

All new files should have denote their license.

> +static inline const char *cpu_get_model(uint32_t eflags) {
> +/* For now, treat anything newer than v60 as a v67 */
> +/* FIXME - Disable instructions that are newer than the specified arch */
> +if (eflags == 0x04 ||/* v5  */
> +eflags == 0x05 ||/* v55 */
> +eflags == 0x60 ||/* v60 */
> +eflags == 0x61 ||/* v61 */
> +eflags == 0x62 ||/* v62 */
> +eflags == 0x65 ||/* v65 */
> +eflags == 0x66 ||/* v66 */
> +eflags == 0x67) {/* v67 */
> +return "v67";
> +}
> +printf("eflags = 0x%x\n", eflags);

Left over debug.

> diff --git a/target/hexagon/Makefile.objs
> b/target/hexagon/Makefile.objs new file mode 100644 index
> 000..dfab6ee
> --- /dev/null
> +++ b/target/hexagon/Makefile.objs
> @@ -0,0 +1,6 @@
> +obj-y += \
> +cpu.o \
> +translate.o \
> +op_helper.o
> +
> +CFLAGS += -I$(SRC_PATH)/target/hexagon/imported

Is this really better than

#include "imported/global_types.h"

etc?

> +++ b/target/hexagon/cpu-param.h
> @@ -0,0 +1,11 @@
> +/* Copyright (c) 2019 Qualcomm Innovation Center, Inc. All Rights
> +Reserved. */
> +
> +
> +#ifndef HEXAGON_CPU_PARAM_H
> +#define HEXAGON_CPU_PARAM_H
> +
> +# define TARGET_PHYS_ADDR_SPACE_BITS 36

Watch your spacing.

Does this really compile without TARGET_VIRT_ADDR_SPACE_BITS?

It's used in linux-user/main.c, but I suppose in a way that the preprocessor 
interprets it as 0.

> +const char * const hexagon_prednames[] = {
> +  "p0 ", "p1 ", "p2 ", "p3 "
> +};

Inter-string spacing probably belongs to the format not the name.
[Taylor] Could you elaborate?  Should I put spacing  after the commas?

> +static inline target_ulong hack_stack_ptrs(CPUHexagonState *env,
> +   target_ulong addr) {
> +target_ulong stack_start = env->stack_start;
> +target_ulong stack_size = 0x1;
> +target_ulong stack_adjust = env->stack_adjust;
> +
> +if (stack_start + 0x1000 >= addr && addr >= (stack_start - stack_size)) {
> +return addr - stack_adjust;
> +}
> +return addr;
> +}

An explanation would be welcome here.
[Taylor]  I will add a comment.  One of the main debugging techniques is to use 
"-d cpu" and compare against LLDB output when single stepping.  However, the 
target and qemu put the stacks in different locations.  This is used to 
compensate so the diff is cleaner.

> +static void hexagon_dump(CPUHexagonState *env, FILE *f) {
> +static target_ulong last_pc;
> +int i;
> +
> +/*
> + * When comparing with LLDB, it doesn't step through single-cycle
> + * hardware loops the same way.  So, we just skip them here
> + */
> +if (env->gpr[HEX_REG_PC] == last_pc) {
> +return;
> +}

This seems mis-placed.
[Taylor] Hexagon has hardware controlled loops, so we can have a single packet 
that executes multiple times.  We don't want the dump to print every time.

> +#ifdef FIXME
> +/*
> + * LLDB bug swaps gp and ugp
> + * FIXME when the LLDB bug is fixed
> + */
> +print_reg(f, env, HEX_REG_GP);
> +print_reg(f, env, HEX_REG_UGP);
> +#else
> +fprintf(f, "  %s = 0x" TARGET_FMT_lx "\n",
> +hexagon_regnames[HEX_REG_GP],
> +hack_stack_ptrs(env, env->gpr[HEX_REG_UGP]));
> +fprintf(f, "  %s = 0x" TARGET_FMT_lx "\n",
> +hexagon_regnames[HEX_REG_UGP],
> +hack_stack_ptrs(env, env->gpr[HEX_REG_GP])); 

RE: [PATCH] Add minimal Hexagon target - First in a series of patches - linux-user changes + linux-user/hexagon + skeleton of target/hexagon - Files in target/hexagon/imported are from another project

[Taylor Simpson]

For the general DEBUG_HEX messages, I think the trace infrastructure isn't 
quite what I'm looking for.

Here's a sample of what it prints
Start packet: pc = 0x4002f0
Packet committed: pc = 0x4002f0
Regs written
r18 = -69420 (0xfffef0d4)
r19 = -69412 (0xfffef0dc)
Stores
memd[0xfffef0b0] = 0 (0x)
Next PC = 0x4002f8
Exec counters: pkt = 17, insn = 24, hvx = 0

For performance, I'd like a way to disable them completely when --enable-debug 
isn't passed to configure.  It looks like #ifdef CONFIG_DEBUG_TCG will work for 
this.  Then, I'd like a command-line option to turn them on.  The "-d exec" 
seems like a reasonable place.  So, the code will look like this

#ifdef CONFIG_DEBUG_TCG
if (qemu_loglevel_maks(CPU_LOG_EXEC)) {
qemu_log(...);
}
#endif

Please let me know if I'm on the right track here.

Thanks,
Taylor


-Original Message-
From: Laurent Vivier 
Sent: Tuesday, November 19, 2019 12:13 PM
To: Taylor Simpson ; Philippe Mathieu-Daudé 
; riku.voi...@iki.fi; qemu-devel@nongnu.org
Subject: Re: [PATCH] Add minimal Hexagon target - First in a series of patches 
- linux-user changes + linux-user/hexagon + skeleton of target/hexagon - Files 
in target/hexagon/imported are from another project and therefore do not 
conform to qemu coding standards


Le 19/11/2019 à 18:22, Taylor Simpson a écrit :
> Thanks for all the feedback on the patch.  I'll summarize my TODO list here.  
> Please let me know if there's anything I missed.
> - Add a README file in the imported directory to make it clear that the code 
> comes from another project.  Personally, I prefer keeping the name as 
> "imported".  It was suggested by Richard at the meeting.  Also as a heads-up, 
> that is a small subset of the files that will be in that directory 
> eventually.  Right now, it is the minimum needed to build the skeleton target.
> - Work on the .checkpatchignore as Philippe suggested.
> - Split out the "[__SIGRTMAX - 1] = __SIGRTMIN + 1" into a separate patch.
> - Clean up the long subject line.
> - Add license text to the new files.
> - Remove the DEBUG_HEX blocks.  In general the DEBUG_HEX macro controls a 
> bunch of debugging output as you'll see in later patches.  In the long run, I 
> think it should be replaces with a macro that is defined when configured with 
> --enable-debug and then an additional command-line argument.  I haven't 
> looked into this, so any pointers would be appreciated.

You can have a look to the trace infrastructure (docs/devel/tracing.txt). We 
have also some qemu_log() macros for low level debugging.

> - Laurent suggested I split the patch into two parts: linux-user and 
> target/hexagon.  If I do that, which one should contain the changes to common 
> files (e.g., configure)?  Also, note that we won't be able to build until 
> both patches are merged.  Is that OK?

You should add target/hexagon first, and it should not be build as we don't 
have any target (hexagon-linux-user or hexagon-softmmu), then you can add 
linux-user part that will be built and use the target/hexagone CPU. I think the 
configure part should go to the linux-user part as it enables the build.

I asked to split the patch for review purpose, but this should not break 
anything (to allow bisect).

Thanks,
Laurent

>
> Thanks,
> Taylor
>
>
> -Original Message-
> From: Philippe Mathieu-Daudé 
> Sent: Tuesday, November 19, 2019 9:19 AM
> To: Taylor Simpson ; laur...@vivier.eu;
> riku.voi...@iki.fi; qemu-devel@nongnu.org
> Subject: Re: [PATCH] Add minimal Hexagon target - First in a series of
> patches - linux-user changes + linux-user/hexagon + skeleton of
> target/hexagon - Files in target/hexagon/imported are from another
> project and therefore do not conform to qemu coding standards
>
> --
> ---
> CAUTION: This email originated from outside of the organization.
> --
> ---
>
> On 11/19/19 12:58 AM, Taylor Simpson wrote:
>> Signed-off-by: Taylor Simpson 
>> ---
> [...]
>>   target/hexagon/imported/global_types.h  |  25 +++
>>   target/hexagon/imported/iss_ver_registers.h | 183 +++
>>   target/hexagon/imported/max.h   |  78 +++
>>   target/hexagon/imported/regs.h  |  19 ++
>
> Maybe you can rename this directory as:
>
> target/hexagon/dsp-sdk/
>
> and add a README "Files under this directory are imported from the SDK 
> available once registered on developer.qualcomm.com ..."
>
>

Re: [PATCH] spapr: Fix VSMT mode when it is not supported by the kernel

[David Gibson]

On Tue, Nov 19, 2019 at 04:45:26PM +0100, Greg Kurz wrote:
> On Tue, 19 Nov 2019 15:06:51 +0100
> Laurent Vivier  wrote:
> 
> > On 19/11/2019 02:00, David Gibson wrote:
> > > On Fri, Nov 08, 2019 at 05:47:59PM +0100, Greg Kurz wrote:
> > >> On Fri,  8 Nov 2019 16:40:35 +0100
> > >> Laurent Vivier  wrote:
> > >>
> > >>> Commit 29cb4187497d sets by default the VSMT to smp_threads,
> > >>> but older kernels (< 4.13) don't support that.
> > >>>
> > >>> We can reasonably restore previous behavior with this kernel
> > >>> to allow to run QEMU as before.
> > >>>
> > >>> If VSMT is not supported, VSMT will be set to MAX(8, smp_threads)
> > >>> as it is done for previous machine types (< pseries-4.2)
> > >>>
> > >>
> > >> It is usually _bad_ to base the machine behavior on host capabilities.
> > >> What happens if we migrate between an older kernel and a recent one ?
> > > 
> > > Right.  We're really trying to remove instaces of such behaviour.  I'd
> > > prefer to completely revert Greg's original patch than to re-introduce
> > > host configuration dependency into the guest configuration..
> > > 
> > >> I understand this is to fix tests/migration-test on older kernels.
> > >> Couldn't this be achieved with migration-test doing some introspection
> > >> and maybe pass vsmt=8 on the QEMU command line ?
> > > 
> > > ..adjusting the test case like this might be a better idea, though.
> > > 
> > > What's the test setup where we're using the old kernel?  I really only
> > > applied the original patch on the guess that we didn't really care
> > > about kernels that old.  The fact you've hit this in practice makes me
> > > doubt that assumption.
> > > 
> > 
> > The way to fix the tests is to add "-smp threads=8" on the command line
> > (for all tests, so basically in qtest_init_without_qmp_handshake(), and
> > it will impact all the machine types), and we have to check if it is
> 
> Ohhh... it isn't possible to initialize Qtest with machine specific
> properties ? That's a bit unfortunate :-\

Uhh... I don't see why we can't.  Couldn't we just put either -machine
vsmt=8 or -smp 8 into the cmd_src / cmd_dst printfs() in the
strcmp(arch, "ppc64") case?

> > ppc64/pseries to do that, and there it becomes a little bit complicated
> > for a so small piece of code.
> > 
> > So I think the best to do is to revert Greg's patch.
> > 
> 
> I'm okay with that since this patch doesn't bring much for the moment.
> 
> But soon, ie. linux-5.5 hopefully, KVM will allow to configure the number
> of presenters in the XIVE and XICS-on-XIVE devices on POWER9. Combined
> with this patch, it will allow to drastically reduce the consumption of
> resources in the XIVE HW, which currently limits the number of VMs that
> can run concurrently with an in-kernel irqchip. So I hope the 'make check'
> you're willing to fix is worth it :-), and BTW you didn't answer David's
> question about the test setup.
> 

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [PATCH] spapr: Fix VSMT mode when it is not supported by the kernel

[David Gibson]

On Tue, Nov 19, 2019 at 05:13:29PM +0100, Lukáš Doktor wrote:
> Dne 19. 11. 19 v 16:45 Greg Kurz napsal(a):
> > On Tue, 19 Nov 2019 15:06:51 +0100
> > Laurent Vivier  wrote:
> > 
> >> On 19/11/2019 02:00, David Gibson wrote:
> >>> On Fri, Nov 08, 2019 at 05:47:59PM +0100, Greg Kurz wrote:
>  On Fri,  8 Nov 2019 16:40:35 +0100
>  Laurent Vivier  wrote:
> 
> > Commit 29cb4187497d sets by default the VSMT to smp_threads,
> > but older kernels (< 4.13) don't support that.
> >
> > We can reasonably restore previous behavior with this kernel
> > to allow to run QEMU as before.
> >
> > If VSMT is not supported, VSMT will be set to MAX(8, smp_threads)
> > as it is done for previous machine types (< pseries-4.2)
> >
> 
>  It is usually _bad_ to base the machine behavior on host capabilities.
>  What happens if we migrate between an older kernel and a recent one ?
> >>>
> >>> Right.  We're really trying to remove instaces of such behaviour.  I'd
> >>> prefer to completely revert Greg's original patch than to re-introduce
> >>> host configuration dependency into the guest configuration..
> >>>
>  I understand this is to fix tests/migration-test on older kernels.
>  Couldn't this be achieved with migration-test doing some introspection
>  and maybe pass vsmt=8 on the QEMU command line ?
> >>>
> >>> ..adjusting the test case like this might be a better idea, though.
> >>>
> >>> What's the test setup where we're using the old kernel?  I really only
> >>> applied the original patch on the guess that we didn't really care
> >>> about kernels that old.  The fact you've hit this in practice makes me
> >>> doubt that assumption.
> >>>
> >>
> >> The way to fix the tests is to add "-smp threads=8" on the command line
> >> (for all tests, so basically in qtest_init_without_qmp_handshake(), and
> >> it will impact all the machine types), and we have to check if it is
> > 
> > Ohhh... it isn't possible to initialize Qtest with machine specific
> > properties ? That's a bit unfortunate :-\
> > 
> >> ppc64/pseries to do that, and there it becomes a little bit complicated
> >> for a so small piece of code.
> >>
> >> So I think the best to do is to revert Greg's patch.
> >>
> > 
> > I'm okay with that since this patch doesn't bring much for the moment.
> > 
> > But soon, ie. linux-5.5 hopefully, KVM will allow to configure the number
> > of presenters in the XIVE and XICS-on-XIVE devices on POWER9. Combined
> > with this patch, it will allow to drastically reduce the consumption of
> > resources in the XIVE HW, which currently limits the number of VMs that
> > can run concurrently with an in-kernel irqchip. So I hope the 'make check'
> > you're willing to fix is worth it :-), and BTW you didn't answer David's
> > question about the test setup.
> > 
> 
> Hello Greg, guys,
> 
> it is P8 machine using RHEL7 host with a stock kernel-3.10.0-. If you're 
> interested in the whole setup, then:
> 
> ./configure --enable-kvm 
> --block-drv-rw-whitelist=vmdk,null-aio,quorum,null-co,blkverify,file,nbd,raw,blkdebug,host_device,qed,nbd,iscsi,gluster,rbd,qcow2,throttle,copy-on-read
> make -j 13
> SPEED=slow make check

Really the only relevant factor here is that it's a RHEL7 host, which
has an old kernel (3.10 is misleading, since it has a *heap* of
backports, but support for the vsmt feature isn't one of them).

So more generally than this specific test, the question really is
whether we thinkg RHEL7 is still in wide enough use that we care to
keep supporting it with the latest upstream machine type.  I'm a bit
undecided on that.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [RFC v2 09/22] vfio/pci: add iommu_context notifier for pasid alloc/free

[David Gibson]

On Wed, Nov 06, 2019 at 12:14:50PM +, Liu, Yi L wrote:
> > From: David Gibson [mailto:da...@gibson.dropbear.id.au]
> > Sent: Tuesday, October 29, 2019 8:16 PM
> > To: Liu, Yi L 
> > Subject: Re: [RFC v2 09/22] vfio/pci: add iommu_context notifier for pasid 
> > alloc/free
> > 
> > On Thu, Oct 24, 2019 at 08:34:30AM -0400, Liu Yi L wrote:
> > > This patch adds pasid alloc/free notifiers for vfio-pci. It is
> > > supposed to be fired by vIOMMU. VFIO then sends PASID allocation
> > > or free request to host.
> > >
> > > Cc: Kevin Tian 
> > > Cc: Jacob Pan 
> > > Cc: Peter Xu 
> > > Cc: Eric Auger 
> > > Cc: Yi Sun 
> > > Cc: David Gibson 
> > > Signed-off-by: Liu Yi L 
> > > ---
> > >  hw/vfio/common.c |  9 ++
> > >  hw/vfio/pci.c| 81
> > 
> > >  include/hw/iommu/iommu.h | 15 +
> > >  3 files changed, 105 insertions(+)
> > >
> > > diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> > > index d418527..e6ad21c 100644
> > > --- a/hw/vfio/common.c
> > > +++ b/hw/vfio/common.c
> > > @@ -1436,6 +1436,7 @@ static void vfio_disconnect_container(VFIOGroup
> > *group)
> > >  if (QLIST_EMPTY(>group_list)) {
> > >  VFIOAddressSpace *space = container->space;
> > >  VFIOGuestIOMMU *giommu, *tmp;
> > > +VFIOIOMMUContext *giommu_ctx, *ctx;
> > >
> > >  QLIST_REMOVE(container, next);
> > >
> > > @@ -1446,6 +1447,14 @@ static void vfio_disconnect_container(VFIOGroup
> > *group)
> > >  g_free(giommu);
> > >  }
> > >
> > > +QLIST_FOREACH_SAFE(giommu_ctx, >iommu_ctx_list,
> > > +   iommu_ctx_next, ctx) {
> > > +iommu_ctx_notifier_unregister(giommu_ctx->iommu_ctx,
> > > +  _ctx->n);
> > > +QLIST_REMOVE(giommu_ctx, iommu_ctx_next);
> > > +g_free(giommu_ctx);
> > > +}
> > > +
> > >  trace_vfio_disconnect_container(container->fd);
> > >  close(container->fd);
> > >  g_free(container);
> > > diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> > > index 12fac39..8721ff6 100644
> > > --- a/hw/vfio/pci.c
> > > +++ b/hw/vfio/pci.c
> > > @@ -2699,11 +2699,80 @@ static void
> > vfio_unregister_req_notifier(VFIOPCIDevice *vdev)
> > >  vdev->req_enabled = false;
> > >  }
> > >
> > > +static void vfio_register_iommu_ctx_notifier(VFIOPCIDevice *vdev,
> > > + IOMMUContext *iommu_ctx,
> > > + IOMMUCTXNotifyFn fn,
> > > + IOMMUCTXEvent event)
> > > +{
> > > +VFIOContainer *container = vdev->vbasedev.group->container;
> > > +VFIOIOMMUContext *giommu_ctx;
> > > +
> > > +giommu_ctx = g_malloc0(sizeof(*giommu_ctx));
> > > +giommu_ctx->container = container;
> > > +giommu_ctx->iommu_ctx = iommu_ctx;
> > > +QLIST_INSERT_HEAD(>iommu_ctx_list,
> > > +  giommu_ctx,
> > > +  iommu_ctx_next);
> > > +iommu_ctx_notifier_register(iommu_ctx,
> > > +_ctx->n,
> > > +fn,
> > > +event);
> > > +}
> > > +
> > > +static void vfio_iommu_pasid_alloc_notify(IOMMUCTXNotifier *n,
> > > +  IOMMUCTXEventData *event_data)
> > > +{
> > > +VFIOIOMMUContext *giommu_ctx = container_of(n, VFIOIOMMUContext, n);
> > > +VFIOContainer *container = giommu_ctx->container;
> > > +IOMMUCTXPASIDReqDesc *pasid_req =
> > > +  (IOMMUCTXPASIDReqDesc *) event_data->data;
> > > +struct vfio_iommu_type1_pasid_request req;
> > > +unsigned long argsz;
> > > +int pasid;
> > > +
> > > +argsz = sizeof(req);
> > > +req.argsz = argsz;
> > > +req.flag = VFIO_IOMMU_PASID_ALLOC;
> > > +req.min_pasid = pasid_req->min_pasid;
> > > +req.max_pasid = pasid_req->max_pasid;
> > > +
> > > +pasid = ioctl(container->fd, VFIO_IOMMU_PASID_REQUEST, );
> > > +if (pasid < 0) {
> > > +error_report("%s: %d, alloc failed", __func__, -errno);
> > > +}
> > > +pasid_req->alloc_result = pasid;
> > 
> > Altering the event data from the notifier doesn't make sense.  By
> > definition there can be multiple notifiers on the chain, so in that
> > case which one is responsible for updating the writable field?
> 
> I guess you mean multiple pasid_alloc nofitiers. right?
> 
> It works for VT-d now, as Intel vIOMMU maintains the IOMMUContext
> per-bdf. And there will be only 1 pasid_alloc notifier in the chain. But, I
> agree it is not good if other module just share an IOMMUConext across
> devices. Definitely, it would have multiple pasid_alloc notifiers.

Right.

> How about enforcing IOMMUContext layer to only invoke one successful
> pasid_alloc/free notifier if PASID_ALLOC/FREE event comes? pasid
> 

Re: [RFC 5/5] spapr: Work around spurious warnings from vfio INTx initialization

[David Gibson]

On Thu, Oct 17, 2019 at 03:42:06PM +0200, Cédric Le Goater wrote:
> On 17/10/2019 10:43, Cédric Le Goater wrote:
> > On 17/10/2019 07:42, David Gibson wrote:
> >> Traditional PCI INTx for vfio devices can only perform well if using
> >> an in-kernel irqchip.  Therefore, vfio_intx_update() issues a warning
> >> if an in kernel irqchip is not available.
> >>
> >> We usually do have an in-kernel irqchip available for pseries machines
> >> on POWER hosts.  However, because the platform allows feature
> >> negotiation of what interrupt controller model to use, we don't
> >> currently initialize it until machine reset.  vfio_intx_update() is
> >> called (first) from vfio_realize() before that, so it can issue a
> >> spurious warning, even if we will have an in kernel irqchip by the
> >> time we need it.
> >>
> >> To workaround this, make a call to spapr_irq_update_active_intc() from
> >> spapr_irq_init() which is called at machine realize time, before the
> >> vfio realize.  This call will be pretty much obsoleted by the later
> >> call at reset time, but it serves to suppress the spurious warning
> >> from VFIO.
> >>
> >> Cc: Alex Williamson 
> >> Cc: Alexey Kardashevskiy 
> >>
> >> Signed-off-by: David Gibson 
> >> ---
> >>  hw/ppc/spapr_irq.c | 11 ++-
> >>  1 file changed, 10 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/hw/ppc/spapr_irq.c b/hw/ppc/spapr_irq.c
> >> index 45544b8976..bb91c61fa0 100644
> >> --- a/hw/ppc/spapr_irq.c
> >> +++ b/hw/ppc/spapr_irq.c
> >> @@ -345,6 +345,14 @@ void spapr_irq_init(SpaprMachineState *spapr, Error 
> >> **errp)
> >>  
> >>  spapr->qirqs = qemu_allocate_irqs(spapr_set_irq, spapr,
> >>smc->nr_xirqs + SPAPR_XIRQ_BASE);
> >> +
> >> +/*
> >> + * Mostly we don't actually need this until reset, except that not
> >> + * having this set up can cause VFIO devices to issue a
> >> + * false-positive warning during realize(), because they don't yet
> >> + * have an in-kernel irq chip.
> >> + */
> >> +spapr_irq_update_active_intc(spapr);
> > 
> > This will call the de/activate hooks of the irq chip very early 
> > before reset and CAS, and won't call them at reset if the intc
> > pointers are the same (xive only for instance). It breaks very 
> > obviously the emulated XIVE device which won't reset the OS CAM 
> > line with the CPU id values and CPU notification will be broken.
> > 
> > We have to find something else.
> 
> Here is a possible fix for the (re)setting of the OS CAM line. 
> 
> Removing spapr_xive_set_tctx_os_cam() is a good thing but this solution
> shows some issues in our modeling of hot-plugged CPUS with a reset() 
> being called at realize().

Ok, I've applied the patch below now.  Does that mean that my 5/5
patch should be good now?

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [PATCH for-5.0 v5 06/23] ppc/xive: Introduce OS CAM line helpers

[David Gibson]

On Fri, Nov 15, 2019 at 05:24:19PM +0100, Cédric Le Goater wrote:
> The OS CAM line has a special encoding exploited by the HW. Provide
> helper routines to hide the details to the TIMA command handlers. This
> also clarifies the endianness of different variables : 'qw1w2' is
> big-endian and 'cam' is native.
> 
> Signed-off-by: Cédric Le Goater 

Applied, thanks.

> ---
>  hw/intc/xive.c | 41 ++---
>  1 file changed, 38 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/intc/xive.c b/hw/intc/xive.c
> index 177663d2b43e..42e9a11ef731 100644
> --- a/hw/intc/xive.c
> +++ b/hw/intc/xive.c
> @@ -337,14 +337,49 @@ static void xive_tm_set_os_pending(XiveTCTX *tctx, 
> hwaddr offset,
>  xive_tctx_notify(tctx, TM_QW1_OS);
>  }
>  
> +static void xive_os_cam_decode(uint32_t cam, uint8_t *nvt_blk,
> +   uint32_t *nvt_idx, bool *vo)
> +{
> +if (nvt_blk) {
> +*nvt_blk = xive_nvt_blk(cam);
> +}
> +if (nvt_idx) {
> +*nvt_idx = xive_nvt_idx(cam);
> +}
> +if (vo) {
> +*vo = !!(cam & TM_QW1W2_VO);
> +}
> +}
> +
> +static uint32_t xive_tctx_get_os_cam(XiveTCTX *tctx, uint8_t *nvt_blk,
> + uint32_t *nvt_idx, bool *vo)
> +{
> +uint32_t qw1w2 = xive_tctx_word2(>regs[TM_QW1_OS]);
> +uint32_t cam = be32_to_cpu(qw1w2);
> +
> +xive_os_cam_decode(cam, nvt_blk, nvt_idx, vo);
> +return qw1w2;
> +}
> +
> +static void xive_tctx_set_os_cam(XiveTCTX *tctx, uint32_t qw1w2)
> +{
> +memcpy(>regs[TM_QW1_OS + TM_WORD2], , 4);
> +}
> +
>  static uint64_t xive_tm_pull_os_ctx(XiveTCTX *tctx, hwaddr offset,
>  unsigned size)
>  {
> -uint32_t qw1w2_prev = xive_tctx_word2(>regs[TM_QW1_OS]);
>  uint32_t qw1w2;
> +uint32_t qw1w2_new;
> +uint8_t nvt_blk;
> +uint32_t nvt_idx;
> +bool vo;
>  
> -qw1w2 = xive_set_field32(TM_QW1W2_VO, qw1w2_prev, 0);
> -memcpy(>regs[TM_QW1_OS + TM_WORD2], , 4);
> +qw1w2 = xive_tctx_get_os_cam(tctx, _blk, _idx, );
> +
> +/* Invalidate CAM line */
> +qw1w2_new = xive_set_field32(TM_QW1W2_VO, qw1w2, 0);
> +xive_tctx_set_os_cam(tctx, qw1w2_new);
>  return qw1w2;
>  }
>  

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [PATCH for-5.0 v5 07/23] ppc/xive: Check V bit in TM_PULL_POOL_CTX

[David Gibson]

On Fri, Nov 15, 2019 at 05:24:20PM +0100, Cédric Le Goater wrote:
> A context should be 'valid' when pulled from the thread interrupt
> context registers.
> 
> Signed-off-by: Cédric Le Goater 

Applied, thanks.

> ---
>  hw/intc/xive.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/hw/intc/xive.c b/hw/intc/xive.c
> index 42e9a11ef731..511e1a936347 100644
> --- a/hw/intc/xive.c
> +++ b/hw/intc/xive.c
> @@ -377,6 +377,11 @@ static uint64_t xive_tm_pull_os_ctx(XiveTCTX *tctx, 
> hwaddr offset,
>  
>  qw1w2 = xive_tctx_get_os_cam(tctx, _blk, _idx, );
>  
> +if (!vo) {
> +qemu_log_mask(LOG_GUEST_ERROR, "XIVE: pulling invalid NVT %x/%x 
> !?\n",
> +  nvt_blk, nvt_idx);
> +}
> +
>  /* Invalidate CAM line */
>  qw1w2_new = xive_set_field32(TM_QW1W2_VO, qw1w2, 0);
>  xive_tctx_set_os_cam(tctx, qw1w2_new);

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [RFC 3/5] vfio/pci: Respond to KVM irqchip change notifier

[David Gibson]

On Thu, Oct 17, 2019 at 02:28:45PM -0600, Alex Williamson wrote:
> On Thu, 17 Oct 2019 16:42:16 +1100
> David Gibson  wrote:
> 
> > VFIO PCI devices already respond to the pci intx routing notifier, in order
> > to update kernel irqchip mappings when routing is updated.  However this
> > won't handle the case where the irqchip itself is replaced by a different
> > model while retaining the same routing.  This case can happen on
> > the pseries machine type due to PAPR feature negotiation.
> > 
> > To handle that case, add a handler for the irqchip change notifier, which
> > does much the same thing as the routing notifier, but is unconditional,
> > rather than being a no-op when the routing hasn't changed.
> > 
> > Cc: Alex Williamson 
> > Cc: Alexey Kardashevskiy 
> > 
> > Signed-off-by: David Gibson 
> > ---
> >  hw/vfio/pci.c | 12 
> >  hw/vfio/pci.h |  2 ++
> >  2 files changed, 14 insertions(+)
> > 
> > diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> > index 529ad13908..6aa806baff 100644
> > --- a/hw/vfio/pci.c
> > +++ b/hw/vfio/pci.c
> > @@ -255,6 +255,14 @@ static void vfio_intx_routing_notifier(PCIDevice *pdev)
> >  }
> >  }
> >  
> > +static void vfio_irqchip_change(Notifier *notify, void *data)
> > +{
> > +VFIOPCIDevice *vdev = container_of(notify, VFIOPCIDevice,
> > +   irqchip_change_notifier);
> > +
> > +vfio_intx_update(vdev, >intx.route);
> > +}
> > +
> >  static int vfio_intx_enable(VFIOPCIDevice *vdev, Error **errp)
> >  {
> >  uint8_t pin = vfio_pci_read_config(>pdev, PCI_INTERRUPT_PIN, 1);
> > @@ -2960,6 +2968,8 @@ static void vfio_realize(PCIDevice *pdev, Error 
> > **errp)
> >vfio_intx_mmap_enable, 
> > vdev);
> >  pci_device_set_intx_routing_notifier(>pdev,
> >   vfio_intx_routing_notifier);
> > +vdev->irqchip_change_notifier.notify = vfio_irqchip_change;
> > +kvm_irqchip_add_change_notifier(>irqchip_change_notifier);
> >  ret = vfio_intx_enable(vdev, errp);
> >  if (ret) {
> >  goto out_teardown;
> > @@ -3009,6 +3019,7 @@ static void vfio_realize(PCIDevice *pdev, Error 
> > **errp)
> >  
> >  out_teardown:
> >  pci_device_set_intx_routing_notifier(>pdev, NULL);
> > +kvm_irqchip_remove_change_notifier(>irqchip_change_notifier);
> 
> We can get here without having added the irqchip notifier and I don't
> think QLIST_REMOVE is very friendly with gratuitous calls.

Good point, adjusted.


> >  vfio_teardown_msi(vdev);
> >  vfio_bars_exit(vdev);
> >  error:
> > @@ -3042,6 +3053,7 @@ static void vfio_exitfn(PCIDevice *pdev)
> >  vfio_unregister_req_notifier(vdev);
> >  vfio_unregister_err_notifier(vdev);
> >  pci_device_set_intx_routing_notifier(>pdev, NULL);
> > +kvm_irqchip_remove_change_notifier(>irqchip_change_notifier);
> 
> Same here.  Otherwise the approach looks sane to me.  Thanks,
> 
> Alex
> 
> >  vfio_disable_interrupts(vdev);
> >  if (vdev->intx.mmap_timer) {
> >  timer_free(vdev->intx.mmap_timer);
> > diff --git a/hw/vfio/pci.h b/hw/vfio/pci.h
> > index 834a90d646..11324f28ce 100644
> > --- a/hw/vfio/pci.h
> > +++ b/hw/vfio/pci.h
> > @@ -168,6 +168,8 @@ typedef struct VFIOPCIDevice {
> >  bool no_vfio_ioeventfd;
> >  bool enable_ramfb;
> >  VFIODisplay *dpy;
> > +
> > +Notifier irqchip_change_notifier;
> >  } VFIOPCIDevice;
> >  
> >  uint32_t vfio_pci_read_config(PCIDevice *pdev, uint32_t addr, int len);
> 

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [PATCH v3 01/33] qdev: remove unused qdev_prop_int64

[Marc-André Lureau]

Hi

On Mon, Nov 18, 2019 at 6:01 PM Peter Maydell  wrote:
>
> On Wed, 23 Oct 2019 at 18:32, Marc-André Lureau
>  wrote:
> >
> > Signed-off-by: Marc-André Lureau 
> > ---
> >  hw/core/qdev-properties.c| 32 
> >  include/hw/qdev-properties.h |  3 ---
> >  2 files changed, 35 deletions(-)
>
> I think I'd rather keep this. It's weird to not have a symmetric
> set of properties for the common integer types, and annoying
> for whoever next runs into a need for an int64 property to
> have to reinstate the deleted code. (Yes, I know we don't
> currently have int8 or int16.)
>

I don't think we should aim at being complete. Whenever we identify
dead code, unused for a long while, we should clean it up.

In this case, it is even worse, this has never been used since its
introduction in commit 07d1d063d3235c02f60dc92ec174d419e6f8a750, in
2017.

Re: [PATCH 2/5] hw/ppc/pnv_xscom: PBA bar mask values are incorrect with homer/occ sizes

[Balamuruhan S]

On Wed, Nov 20, 2019 at 08:31:03AM +0530, Balamuruhan S wrote:
> On Wed, Nov 20, 2019 at 09:02:26AM +1100, David Gibson wrote:
> > On Wed, Nov 20, 2019 at 09:00:32AM +1100, David Gibson wrote:
> > > On Wed, Nov 20, 2019 at 08:56:18AM +1100, David Gibson wrote:
> > > > On Tue, Nov 19, 2019 at 11:20:53PM +0530, Balamuruhan S wrote:
> > > > > homer/occ sizes are calculated in skiboot with `(mask | 0xf) + 1`,
> > > > > and from xscom access should return correct mask values instead of 
> > > > > actual
> > > > > sizes.
> > > > > 
> > > > > Signed-off-by: Cédric Le Goater 
> > > > > Signed-off-by: Balamuruhan S 
> > > > > ---
> > > > >  hw/ppc/pnv_xscom.c | 10 ++
> > > > >  1 file changed, 6 insertions(+), 4 deletions(-)
> > > > > 
> > > > > diff --git a/hw/ppc/pnv_xscom.c b/hw/ppc/pnv_xscom.c
> > > > > index f01d788a65..cdd5fa356e 100644
> > > > > --- a/hw/ppc/pnv_xscom.c
> > > > > +++ b/hw/ppc/pnv_xscom.c
> > > > > @@ -46,6 +46,10 @@
> > > > >  #define P9_PBA_BARMASK0 0x5012b04
> > > > >  #define P9_PBA_BARMASK2 0x5012b06
> > > > >  
> > > > > +/* Mask to calculate Homer/Occ size */
> > > > > +#define HOMER_SIZE_MASK 0x0030ull
> > > > > +#define OCC_SIZE_MASK   0x0070ull
> > > > 
> > > > Uuuh... AFAICT these defines have identical values to
> > > > PNV_HOMER_SIZE and PNV_OCC_COMMON_AREA_SIZE, so I don't see what this
> > > > patch is actually changing.
> > > 
> > > Oh, sorry, missed that the values were changed in 1/5.  Would have
> > > been easier to follow if the two patches were folded together, but
> > > never mind.  Applied.
> > 
> > Ugh.. or not.  The first patch doesn't apply for me, looks like it
> > needs a rebase (or you have something else in your tree I don't know
> > about).
> 
> I checked out from upstream master (commit: 8937f17249 ) and worked on
 ^
 |
ignore this its my first patch commit id (1/5)

> it.

upstream commit id: f086f22d6c (VFIO fixes 2019-11-18), please let me
know if you would like me to respin the patches after rebase with v4.2.0
rc2 release.

-- Bala

> 
> -- Bala
> > 
> > -- 
> > David Gibson| I'll have my music baroque, and my 
> > code
> > david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ 
> > _other_
> > | _way_ _around_!
> > http://www.ozlabs.org/~dgibson
> 
> 
> 

Re: [PATCH 2/5] hw/ppc/pnv_xscom: PBA bar mask values are incorrect with homer/occ sizes

[Balamuruhan S]

On Wed, Nov 20, 2019 at 09:02:26AM +1100, David Gibson wrote:
> On Wed, Nov 20, 2019 at 09:00:32AM +1100, David Gibson wrote:
> > On Wed, Nov 20, 2019 at 08:56:18AM +1100, David Gibson wrote:
> > > On Tue, Nov 19, 2019 at 11:20:53PM +0530, Balamuruhan S wrote:
> > > > homer/occ sizes are calculated in skiboot with `(mask | 0xf) + 1`,
> > > > and from xscom access should return correct mask values instead of 
> > > > actual
> > > > sizes.
> > > > 
> > > > Signed-off-by: Cédric Le Goater 
> > > > Signed-off-by: Balamuruhan S 
> > > > ---
> > > >  hw/ppc/pnv_xscom.c | 10 ++
> > > >  1 file changed, 6 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/hw/ppc/pnv_xscom.c b/hw/ppc/pnv_xscom.c
> > > > index f01d788a65..cdd5fa356e 100644
> > > > --- a/hw/ppc/pnv_xscom.c
> > > > +++ b/hw/ppc/pnv_xscom.c
> > > > @@ -46,6 +46,10 @@
> > > >  #define P9_PBA_BARMASK0 0x5012b04
> > > >  #define P9_PBA_BARMASK2 0x5012b06
> > > >  
> > > > +/* Mask to calculate Homer/Occ size */
> > > > +#define HOMER_SIZE_MASK 0x0030ull
> > > > +#define OCC_SIZE_MASK   0x0070ull
> > > 
> > > Uuuh... AFAICT these defines have identical values to
> > > PNV_HOMER_SIZE and PNV_OCC_COMMON_AREA_SIZE, so I don't see what this
> > > patch is actually changing.
> > 
> > Oh, sorry, missed that the values were changed in 1/5.  Would have
> > been easier to follow if the two patches were folded together, but
> > never mind.  Applied.
> 
> Ugh.. or not.  The first patch doesn't apply for me, looks like it
> needs a rebase (or you have something else in your tree I don't know
> about).

I checked out from upstream master (commit: 8937f17249) and worked on
it.

-- Bala
> 
> -- 
> David Gibson  | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au| minimalist, thank you.  NOT _the_ 
> _other_
>   | _way_ _around_!
> http://www.ozlabs.org/~dgibson

Re: [PATCH] linux-user/strace: Improve output of various syscalls

[Aleksandar Markovic]

>
>  #ifdef TARGET_NR_ioctl
> -{ TARGET_NR_ioctl, "ioctl" , NULL, NULL, NULL },
> +{ TARGET_NR_ioctl, "ioctl" , "%s(%d,%#x,%#x,%#x,%#x,%#x)", NULL, NULL },
>  #endif


ioctl() has only three arguments.

Regards,

Aleksandar

Re: [PATCH] Add minimal Hexagon target - First in a series of patches - linux-user changes + linux-user/hexagon + skeleton of target/hexagon - Files in target/hexagon/imported are from another project

[Aleksandar Markovic]

On Tuesday, November 19, 2019, Richard Henderson <
richard.hender...@linaro.org> wrote:

> On 11/19/19 6:22 PM, Taylor Simpson wrote:
> > - Laurent suggested I split the patch into two parts: linux-user and
> target/hexagon.  If I do that, which one should contain the changes to
> common files (e.g., configure)?  Also, note that we won't be able to build
> until both patches are merged.  Is that OK?
>
> The configure parts should be a third, last, patch.
>
> The series is bisectable, because before the configure patch,
> none of the hexagon code is compiled at all.
>
>
I don't think this is a good advice. Yes, at first glance, that would make
the submitter's job easier - since he could divide the whole code into
parts practicaly arbitrarily - but the resulting series will be of
suboptimal quality. If the submitter was forced from the outset to add
segments of his solution so that each step actually (not only ostensibly)
compiles, he would also be forced to organize patches in much more coherent
way, organize his code in much more modular way, possibly improve initial
organization, additionally making reviews much easier.

Aleksandar


>
> r~
>
>

Re: [PULL 00/12] Misc patches for QEMU 4.2-rc

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/1574179728-35535-1-git-send-email-pbonz...@redhat.com/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Subject: [PULL 00/12] Misc patches for QEMU 4.2-rc
Type: series
Message-id: 1574179728-35535-1-git-send-email-pbonz...@redhat.com

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Switched to a new branch 'test'
b13136f mc146818rtc: fix timer interrupt reinjection again
c8aba23 Revert "mc146818rtc: fix timer interrupt reinjection"
e8adcab scsi: deprecate scsi-disk
42092c5 hw/i386: Move save_tsc_khz from PCMachineClass to X86MachineClass
06c7471 docs/microvm.rst: add instructions for shutting down the guest
13c0c9d docs/microvm.rst: fix alignment in "Limitations"
02f7826 hw/i386: Fix compiler warning when CONFIG_IDE_ISA is disabled
9062194 target/i386: Export TAA_NO bit to guests
1950075 target/i386: add PSCHANGE_NO bit for the ARCH_CAPABILITIES MSR
885825e microvm: fix memory leak in microvm_fix_kernel_cmdline
7efdfb1 scripts: Detect git worktrees for get_maintainer.pl --git

=== OUTPUT BEGIN ===
1/11 Checking commit 7efdfb18179f (scripts: Detect git worktrees for 
get_maintainer.pl --git)
2/11 Checking commit 885825e5f343 (microvm: fix memory leak in 
microvm_fix_kernel_cmdline)
3/11 Checking commit 19500750d17c (target/i386: add PSCHANGE_NO bit for the 
ARCH_CAPABILITIES MSR)
4/11 Checking commit 90621948f8f4 (target/i386: Export TAA_NO bit to guests)
5/11 Checking commit 02f7826045a6 (hw/i386: Fix compiler warning when 
CONFIG_IDE_ISA is disabled)
6/11 Checking commit 13c0c9d930a3 (docs/microvm.rst: fix alignment in 
"Limitations")
7/11 Checking commit 06c747141471 (docs/microvm.rst: add instructions for 
shutting down the guest)
8/11 Checking commit 42092c5e828c (hw/i386: Move save_tsc_khz from 
PCMachineClass to X86MachineClass)
9/11 Checking commit e8adcab85cc4 (scsi: deprecate scsi-disk)
10/11 Checking commit c8aba2331468 (Revert "mc146818rtc: fix timer interrupt 
reinjection")
11/11 Checking commit b13136ffee50 (mc146818rtc: fix timer interrupt 
reinjection again)
ERROR: line over 90 characters
#33: FILE: hw/rtc/mc146818rtc.c:171:
+periodic_timer_update(RTCState *s, int64_t current_time, uint32_t old_period, 
bool period_change)

WARNING: line over 80 characters
#101: FILE: hw/rtc/mc146818rtc.c:808:
+periodic_timer_update(s, qemu_clock_get_ns(rtc_clock), s->period, 
false);

total: 1 errors, 1 warnings, 69 lines checked

Patch 11/11 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/1574179728-35535-1-git-send-email-pbonz...@redhat.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [PATCH v9 Kernel 2/5] vfio iommu: Add ioctl defination to get dirty pages bitmap.

[Yan Zhao]

On Fri, Nov 15, 2019 at 11:21:33AM +0800, Alex Williamson wrote:
> On Thu, 14 Nov 2019 21:40:35 -0500
> Yan Zhao  wrote:
> 
> > On Fri, Nov 15, 2019 at 05:06:25AM +0800, Alex Williamson wrote:
> > > On Fri, 15 Nov 2019 00:26:07 +0530
> > > Kirti Wankhede  wrote:
> > >   
> > > > On 11/14/2019 1:37 AM, Alex Williamson wrote:  
> > > > > On Thu, 14 Nov 2019 01:07:21 +0530
> > > > > Kirti Wankhede  wrote:
> > > > > 
> > > > >> On 11/13/2019 4:00 AM, Alex Williamson wrote:
> > > > >>> On Tue, 12 Nov 2019 22:33:37 +0530
> > > > >>> Kirti Wankhede  wrote:
> > > > >>>
> > > >  All pages pinned by vendor driver through vfio_pin_pages API 
> > > >  should be
> > > >  considered as dirty during migration. IOMMU container maintains a 
> > > >  list of
> > > >  all such pinned pages. Added an ioctl defination to get bitmap of 
> > > >  such
> > > > >>>
> > > > >>> definition
> > > > >>>
> > > >  pinned pages for requested IO virtual address range.
> > > > >>>
> > > > >>> Additionally, all mapped pages are considered dirty when physically
> > > > >>> mapped through to an IOMMU, modulo we discussed devices opting in to
> > > > >>> per page pinning to indicate finer granularity with a TBD mechanism 
> > > > >>> to
> > > > >>> figure out if any non-opt-in devices remain.
> > > > >>>
> > > > >>
> > > > >> You mean, in case of device direct assignment (device pass through)? 
> > > > >>
> > > > > 
> > > > > Yes, or IOMMU backed mdevs.  If vfio_dmas in the container are fully
> > > > > pinned and mapped, then the correct dirty page set is all mapped 
> > > > > pages.
> > > > > We discussed using the vpfn list as a mechanism for vendor drivers to
> > > > > reduce their migration footprint, but we also discussed that we would
> > > > > need a way to determine that all participants in the container have
> > > > > explicitly pinned their working pages or else we must consider the
> > > > > entire potential working set as dirty.
> > > > > 
> > > > 
> > > > How can vendor driver tell this capability to iommu module? Any 
> > > > suggestions?  
> > > 
> > > I think it does so by pinning pages.  Is it acceptable that if the
> > > vendor driver pins any pages, then from that point forward we consider
> > > the IOMMU group dirty page scope to be limited to pinned pages?  There
> > > are complications around non-singleton IOMMU groups, but I think we're
> > > already leaning towards that being a non-worthwhile problem to solve.
> > > So if we require that only singleton IOMMU groups can pin pages and we
> > > pass the IOMMU group as a parameter to
> > > vfio_iommu_driver_ops.pin_pages(), then the type1 backend can set a
> > > flag on its local vfio_group struct to indicate dirty page scope is
> > > limited to pinned pages.  We might want to keep a flag on the
> > > vfio_iommu struct to indicate if all of the vfio_groups for each
> > > vfio_domain in the vfio_iommu.domain_list dirty page scope limited to
> > > pinned pages as an optimization to avoid walking lists too often.  Then
> > > we could test if vfio_iommu.domain_list is not empty and this new flag
> > > does not limit the dirty page scope, then everything within each
> > > vfio_dma is considered dirty.
> > >  
> > 
> > hi Alex
> > could you help clarify whether my understandings below are right?
> > In future,
> > 1. for mdev and for passthrough device withoug hardware ability to track
> > dirty pages, the vendor driver has to explicitly call
> > vfio_pin_pages()/vfio_unpin_pages() + a flag to tell vfio its dirty page 
> > set.
> 
> For non-IOMMU backed mdevs without hardware dirty page tracking,
> there's no change to the vendor driver currently.  Pages pinned by the
> vendor driver are marked as dirty.
> 
> For any IOMMU backed device, mdev or direct assignment, all mapped
> memory would be considered dirty unless there are explicit calls to pin
> pages on top of the IOMMU page pinning and mapping.  These would likely
> be enabled only when the device is in the _SAVING device_state.
> 
> > 2. for those devices with hardware ability to track dirty pages, will still
> > provide a callback to vendor driver to get dirty pages. (as for those 
> > devices,
> > it is hard to explicitly call vfio_pin_pages()/vfio_unpin_pages())
> >
> > 3. for devices relying on dirty bit info in physical IOMMU, there
> > will be a callback to physical IOMMU driver to get dirty page set from
> > vfio.
> 
> The proposal here does not cover exactly how these would be
> implemented, it only establishes the container as the point of user
> interaction with the dirty bitmap and hopefully allows us to maintain
> that interface regardless of whether we have dirty tracking at the
> device or the system IOMMU.  Ideally devices with dirty tracking would
> make use of page pinning and we'd extend the interface to allow vendor
> drivers the ability to indicate the clean/dirty state of those pinned
> pages.  For system IOMMU dirty page 

RE: [PATCH v7 0/4] colo: Add support for continuous replication

[Zhang, Chen]

> -Original Message-
> From: Jason Wang 
> Sent: Tuesday, November 19, 2019 11:03 PM
> To: Zhang, Chen ; Lukas Straub
> ; qemu-devel 
> Cc: Kevin Wolf ; qemu-block  bl...@nongnu.org>; Wen Congyang ; Max
> Reitz ; Xie Changlong 
> Subject: Re: [PATCH v7 0/4] colo: Add support for continuous replication
> 
> 
> On 2019/11/19 下午8:28, Zhang, Chen wrote:
> >
> >> -Original Message-
> >> From: Lukas Straub 
> >> Sent: Thursday, November 14, 2019 12:36 AM
> >> To: qemu-devel 
> >> Cc: Zhang, Chen ; Jason Wang
> >> ; Wen Congyang
> ; Xie
> >> Changlong ; Kevin Wolf
> ;
> >> Max Reitz ; qemu-block 
> >> Subject: Re: [PATCH v7 0/4] colo: Add support for continuous
> >> replication
> >>
> >> On Fri, 25 Oct 2019 19:06:31 +0200
> >> Lukas Straub  wrote:
> >>
> >>> Hello Everyone,
> >>> These Patches add support for continuous replication to colo. This
> >>> means that after the Primary fails and the Secondary did a failover,
> >>> the Secondary can then become Primary and resume replication to a
> >>> new
> >> Secondary.
> >>> Regards,
> >>> Lukas Straub
> >>>
> >>> v7:
> >>>   - clarify meaning of ip's in documentation and note that active and
> hidden
> >>> images just need to be created once
> >>>   - reverted removal of bdrv_is_root_node(top_bs) in replication and
> >> adjusted
> >>> the top-id= parameter in documentation acordingly
> >>>
> >>> v6:
> >>>   - documented the position= and insert= options
> >>>   - renamed replication test
> >>>   - clarified documentation by using different ip's for primary and
> >>> secondary
> >>>   - added Reviewed-by tags
> >>>
> >>> v5:
> >>>   - change syntax for the position= parameter
> >>>   - fix spelling mistake
> >>>
> >>> v4:
> >>>   - fix checkpatch.pl warnings
> >>>
> >>> v3:
> >>>   - add test for replication changes
> >>>   - check if the filter to be inserted before/behind belongs to the
> >>> same interface
> >>>   - fix the error message for the position= parameter
> >>>   - rename term "after" -> "behind" and variable "insert_before" ->
> >> "insert_before_flag"
> >>>   - document the quorum node on the secondary side
> >>>   - simplify quorum parameters in documentation
> >>>   - remove trailing spaces in documentation
> >>>   - clarify the testing procedure in documentation
> >>>
> >>> v2:
> >>>   - fix email formating
> >>>   - fix checkpatch.pl warnings
> >>>   - fix patchew error
> >>>   - clearer commit messages
> >>>
> >>>
> >>> Lukas Straub (4):
> >>>block/replication.c: Ignore requests after failover
> >>>tests/test-replication.c: Add test for for secondary node continuing
> >>>  replication
> >>>net/filter.c: Add Options to insert filters anywhere in the filter
> >>>  list
> >>>colo: Update Documentation for continuous replication
> >>>
> >>>   block/replication.c|  35 +-
> >>>   docs/COLO-FT.txt   | 224 +++-
> -
> >>>   docs/block-replication.txt |  28 +++--
> >>>   include/net/filter.h   |   2 +
> >>>   net/filter.c   |  92 ++-
> >>>   qemu-options.hx|  31 -
> >>>   tests/test-replication.c   |  52 +
> >>>   7 files changed, 389 insertions(+), 75 deletions(-)
> >>>
> >> Hello Everyone,
> >> So I guess this is ready for merging or will that have to wait until
> >> the 4.2 release is done?
> > Due to Qemu 4.2 release schedule, after soft feature freeze(Oct29) the
> master branch does not accept feature changes.
> > But I don't know if sub-maintainer(block or net) can queue this series first
> then merge it after 4.2 release?
> >
> > Thanks
> > Zhang Chen
> 
> 
> Will try to queue this series.

Thank you Jason~

Thanks
Zhang Chen

> 
> Thanks
> 
> 
> >
> >> Regards,
> >> Lukas Straub

RE: [PATCH v9 Kernel 2/5] vfio iommu: Add ioctl defination to get dirty pages bitmap.

[Tian, Kevin]

> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Wednesday, November 20, 2019 7:17 AM
> 
> On Fri, 15 Nov 2019 05:10:53 +
> "Tian, Kevin"  wrote:
> 
> > > From: Alex Williamson
> > > Sent: Friday, November 15, 2019 11:22 AM
> > >
> > > On Thu, 14 Nov 2019 21:40:35 -0500
> > > Yan Zhao  wrote:
> > >
> > > > On Fri, Nov 15, 2019 at 05:06:25AM +0800, Alex Williamson wrote:
> > > > > On Fri, 15 Nov 2019 00:26:07 +0530
> > > > > Kirti Wankhede  wrote:
> > > > >
> > > > > > On 11/14/2019 1:37 AM, Alex Williamson wrote:
> > > > > > > On Thu, 14 Nov 2019 01:07:21 +0530
> > > > > > > Kirti Wankhede  wrote:
> > > > > > >
> > > > > > >> On 11/13/2019 4:00 AM, Alex Williamson wrote:
> > > > > > >>> On Tue, 12 Nov 2019 22:33:37 +0530
> > > > > > >>> Kirti Wankhede  wrote:
> > > > > > >>>
> > > > > >  All pages pinned by vendor driver through vfio_pin_pages
> API
> > > should be
> > > > > >  considered as dirty during migration. IOMMU container
> > > maintains a list of
> > > > > >  all such pinned pages. Added an ioctl defination to get
> bitmap of
> > > such
> > > > > > >>>
> > > > > > >>> definition
> > > > > > >>>
> > > > > >  pinned pages for requested IO virtual address range.
> > > > > > >>>
> > > > > > >>> Additionally, all mapped pages are considered dirty when
> > > physically
> > > > > > >>> mapped through to an IOMMU, modulo we discussed devices
> > > opting in to
> > > > > > >>> per page pinning to indicate finer granularity with a TBD
> > > mechanism to
> > > > > > >>> figure out if any non-opt-in devices remain.
> > > > > > >>>
> > > > > > >>
> > > > > > >> You mean, in case of device direct assignment (device pass
> > > through)?
> > > > > > >
> > > > > > > Yes, or IOMMU backed mdevs.  If vfio_dmas in the container are
> > > fully
> > > > > > > pinned and mapped, then the correct dirty page set is all
> mapped
> > > pages.
> > > > > > > We discussed using the vpfn list as a mechanism for vendor
> drivers
> > > to
> > > > > > > reduce their migration footprint, but we also discussed that we
> > > would
> > > > > > > need a way to determine that all participants in the container
> have
> > > > > > > explicitly pinned their working pages or else we must consider
> the
> > > > > > > entire potential working set as dirty.
> > > > > > >
> > > > > >
> > > > > > How can vendor driver tell this capability to iommu module? Any
> > > suggestions?
> > > > >
> > > > > I think it does so by pinning pages.  Is it acceptable that if the
> > > > > vendor driver pins any pages, then from that point forward we
> consider
> > > > > the IOMMU group dirty page scope to be limited to pinned pages?
> > > There
> > > > > are complications around non-singleton IOMMU groups, but I think
> > > we're
> > > > > already leaning towards that being a non-worthwhile problem to
> solve.
> > > > > So if we require that only singleton IOMMU groups can pin pages
> and
> > > we
> > > > > pass the IOMMU group as a parameter to
> > > > > vfio_iommu_driver_ops.pin_pages(), then the type1 backend can
> set a
> > > > > flag on its local vfio_group struct to indicate dirty page scope is
> > > > > limited to pinned pages.  We might want to keep a flag on the
> > > > > vfio_iommu struct to indicate if all of the vfio_groups for each
> > > > > vfio_domain in the vfio_iommu.domain_list dirty page scope limited
> to
> > > > > pinned pages as an optimization to avoid walking lists too often.
> Then
> > > > > we could test if vfio_iommu.domain_list is not empty and this new
> flag
> > > > > does not limit the dirty page scope, then everything within each
> > > > > vfio_dma is considered dirty.
> > > > >
> > > >
> > > > hi Alex
> > > > could you help clarify whether my understandings below are right?
> > > > In future,
> > > > 1. for mdev and for passthrough device withoug hardware ability to
> track
> > > > dirty pages, the vendor driver has to explicitly call
> > > > vfio_pin_pages()/vfio_unpin_pages() + a flag to tell vfio its dirty page
> set.
> > >
> > > For non-IOMMU backed mdevs without hardware dirty page tracking,
> > > there's no change to the vendor driver currently.  Pages pinned by the
> > > vendor driver are marked as dirty.
> >
> > What about the vendor driver can figure out, in software means, which
> > pinned pages are actually dirty? In that case, would a separate mark_dirty
> > interface make more sense? Or introduce read/write flag to the
> pin_pages
> > interface similar to DMA API? Existing drivers always set both r/w flags
> but
> > just in case then a specific driver may set read-only or write-only...
> 
> You're jumping ahead to 2. below, where my reply is that we need to

They are different. 2) is about hardware support which may collect
dirty page info in a log buffer and then report to driver when the latter
requests. Here I'm talking about software approach, i.e. when the
vendor driver intercepts certain guest operations, it may figure out
whether the captured DMA pages are used for write 

[PATCH v2] virtio-pci: disable vring processing when bus-mastering is disabled

[Michael Roth]

Currently the SLOF firmware for pseries guests will disable/re-enable
a PCI device multiple times via IO/MEM/MASTER bits of PCI_COMMAND
register after the initial probe/feature negotiation, as it tends to
work with a single device at a time at various stages like probing
and running block/network bootloaders without doing a full reset
in-between.

In QEMU, when PCI_COMMAND_MASTER is disabled we disable the
corresponding IOMMU memory region, so DMA accesses (including to vring
fields like idx/flags) will no longer undergo the necessary
translation. Normally we wouldn't expect this to happen since it would
be misbehavior on the driver side to continue driving DMA requests.

However, in the case of pseries, with iommu_platform=on, we trigger the
following sequence when tearing down the virtio-blk dataplane ioeventfd
in response to the guest unsetting PCI_COMMAND_MASTER:

  #2  0x55922651 in virtqueue_map_desc (vdev=vdev@entry=0x56dbcfb0, 
p_num_sg=p_num_sg@entry=0x7fffe657e1a8, addr=addr@entry=0x7fffe657e240, 
iov=iov@entry=0x7fffe6580240, max_num_sg=max_num_sg@entry=1024, 
is_write=is_write@entry=false, pa=0, sz=0)
  at /home/mdroth/w/qemu.git/hw/virtio/virtio.c:757
  #3  0x55922a89 in virtqueue_pop (vq=vq@entry=0x56dc8660, 
sz=sz@entry=184)
  at /home/mdroth/w/qemu.git/hw/virtio/virtio.c:950
  #4  0x558d3eca in virtio_blk_get_request (vq=0x56dc8660, 
s=0x56dbcfb0)
  at /home/mdroth/w/qemu.git/hw/block/virtio-blk.c:255
  #5  0x558d3eca in virtio_blk_handle_vq (s=0x56dbcfb0, 
vq=0x56dc8660)
  at /home/mdroth/w/qemu.git/hw/block/virtio-blk.c:776
  #6  0x5591dd66 in virtio_queue_notify_aio_vq 
(vq=vq@entry=0x56dc8660)
  at /home/mdroth/w/qemu.git/hw/virtio/virtio.c:1550
  #7  0x5591ecef in virtio_queue_notify_aio_vq (vq=0x56dc8660)
  at /home/mdroth/w/qemu.git/hw/virtio/virtio.c:1546
  #8  0x5591ecef in virtio_queue_host_notifier_aio_poll 
(opaque=0x56dc86c8)
  at /home/mdroth/w/qemu.git/hw/virtio/virtio.c:2527
  #9  0x55d02164 in run_poll_handlers_once 
(ctx=ctx@entry=0x5688bfc0, timeout=timeout@entry=0x7fffe65844a8)
  at /home/mdroth/w/qemu.git/util/aio-posix.c:520
  #10 0x55d02d1b in try_poll_mode (timeout=0x7fffe65844a8, 
ctx=0x5688bfc0)
  at /home/mdroth/w/qemu.git/util/aio-posix.c:607
  #11 0x55d02d1b in aio_poll (ctx=ctx@entry=0x5688bfc0, 
blocking=blocking@entry=true)
  at /home/mdroth/w/qemu.git/util/aio-posix.c:639
  #12 0x55d0004d in aio_wait_bh_oneshot (ctx=0x5688bfc0, 
cb=cb@entry=0x558d5130 , 
opaque=opaque@entry=0x56de86f0)
  at /home/mdroth/w/qemu.git/util/aio-wait.c:71
  #13 0x558d59bf in virtio_blk_data_plane_stop (vdev=)
  at /home/mdroth/w/qemu.git/hw/block/dataplane/virtio-blk.c:288
  #14 0x55b906a1 in virtio_bus_stop_ioeventfd 
(bus=bus@entry=0x56dbcf38)
  at /home/mdroth/w/qemu.git/hw/virtio/virtio-bus.c:245
  #15 0x55b90dbb in virtio_bus_stop_ioeventfd 
(bus=bus@entry=0x56dbcf38)
  at /home/mdroth/w/qemu.git/hw/virtio/virtio-bus.c:237
  #16 0x55b92a8e in virtio_pci_stop_ioeventfd (proxy=0x56db4e40)
  at /home/mdroth/w/qemu.git/hw/virtio/virtio-pci.c:292
  #17 0x55b92a8e in virtio_write_config (pci_dev=0x56db4e40, 
address=, val=1048832, len=)
  at /home/mdroth/w/qemu.git/hw/virtio/virtio-pci.c:613

I.e. the calling code is only scheduling a one-shot BH for
virtio_blk_data_plane_stop_bh, but somehow we end up trying to process
an additional virtqueue entry before we get there. This is likely due
to the following check in virtio_queue_host_notifier_aio_poll:

  static bool virtio_queue_host_notifier_aio_poll(void *opaque)
  {
  EventNotifier *n = opaque;
  VirtQueue *vq = container_of(n, VirtQueue, host_notifier);
  bool progress;

  if (!vq->vring.desc || virtio_queue_empty(vq)) {
  return false;
  }

  progress = virtio_queue_notify_aio_vq(vq);

namely the call to virtio_queue_empty(). In this case, since no new
requests have actually been issued, shadow_avail_idx == last_avail_idx,
so we actually try to access the vring via vring_avail_idx() to get
the latest non-shadowed idx:

  int virtio_queue_empty(VirtQueue *vq)
  {
  bool empty;
  ...

  if (vq->shadow_avail_idx != vq->last_avail_idx) {
  return 0;
  }

  rcu_read_lock();
  empty = vring_avail_idx(vq) == vq->last_avail_idx;
  rcu_read_unlock();
  return empty;

but since the IOMMU region has been disabled we get a bogus value (0
usually), which causes virtio_queue_empty() to falsely report that
there are entries to be processed, which causes errors such as:

  "virtio: zero sized buffers are not allowed"

or

  "virtio-blk missing headers"

and puts the device in an error state.

This patch works around the issue by introducing virtio_set_disabled(),
which sets a 'disabled' flag to bypass checks 

Re: [virtio-dev] Re: guest / host buffer sharing ...

[Gurchetan Singh]

On Tue, Nov 19, 2019 at 7:31 AM Liam Girdwood
 wrote:
>
> On Tue, 2019-11-12 at 14:55 -0800, Gurchetan Singh wrote:
> > On Tue, Nov 12, 2019 at 5:56 AM Liam Girdwood
> >  wrote:
> > >
> > > On Mon, 2019-11-11 at 16:54 -0800, Gurchetan Singh wrote:
> > > > On Tue, Nov 5, 2019 at 2:55 AM Gerd Hoffmann 
> > > > wrote:
> > > > > Each buffer also has some properties to carry metadata, some
> > > > > fixed
> > > > > (id, size, application), but
> > > > > also allow free form (name = value, framebuffers would have
> > > > > width/height/stride/format for example).
> > > >
> > > > Sounds a lot like the recently added DMA_BUF_SET_NAME ioctls:
> > > >
> > > > https://patchwork.freedesktop.org/patch/310349/
> > > >
> > > > For virtio-wayland + virtio-vdec, the problem is sharing -- not
> > > > allocation.
> > > >
> > >
> > > Audio also needs to share buffers with firmware running on DSPs.
> > >
> > > > As the buffer reaches a kernel boundary, it's properties devolve
> > > > into
> > > > [fd, size].  Userspace can typically handle sharing
> > > > metadata.  The
> > > > issue is the guest dma-buf fd doesn't mean anything on the host.
> > > >
> > > > One scenario could be:
> > > >
> > > > 1) Guest userspace (say, gralloc) allocates using virtio-
> > > > gpu.  When
> > > > allocating, we call uuidgen() and then pass that via
> > > > RESOURCE_CREATE
> > > > hypercall to the host.
> > > > 2) When exporting the dma-buf, we call DMA_BUF_SET_NAME (the
> > > > buffer
> > > > name will be "virtgpu-buffer-${UUID}").
> > > > 3) When importing, virtio-{vdec, video} reads the dma-buf name in
> > > > userspace, and calls fd to handle.  The name is sent to the host
> > > > via
> > > > a
> > > > hypercall, giving host virtio-{vdec, video} enough information to
> > > > identify the buffer.
> > > >
> > > > This solution is entirely userspace -- we can probably come up
> > > > with
> > > > something in kernel space [generate_random_uuid()] if need
> > > > be.  We
> > > > only need two universal IDs: {device ID, buffer ID}.
> > > >
> > >
> > > I need something where I can take a guest buffer and then convert
> > > it to
> > > physical scatter gather page list. I can then either pass the SG
> > > page
> > > list to the DSP firmware (for DMAC IP programming) or have the host
> > > driver program the DMAC directly using the page list (who programs
> > > DMAC
> > > depends on DSP architecture).
> >
> > So you need the HW address space from a guest allocation?
>
> Yes.
>
> >  Would your
> > allocation hypercalls use something like the virtio_gpu_mem_entry
> > (virtio_gpu.h) and the draft virtio_video_mem_entry (draft)?
>
> IIUC, this looks like generic SG buffer allocation ?
>
> >
> > struct {
> > __le64 addr;
> > __le32 length;
> > __le32 padding;
> > };
> >
> > /* VIRTIO_GPU_CMD_RESOURCE_ATTACH_BACKING */
> > struct virtio_gpu_resource_attach_backing {
> > struct virtio_gpu_ctrl_hdr hdr;
> > __le32 resource_id;
> > __le32 nr_entries;
> >   *struct struct virtio_gpu_mem_entry */
> > };
> >
> > struct virtio_video_mem_entry {
> > __le64 addr;
> > __le32 length;
> > __u8 padding[4];
> > };
> >
> > struct virtio_video_resource_attach_backing {
> > struct virtio_video_ctrl_hdr hdr;
> > __le32 resource_id;
> > __le32 nr_entries;
> > };
> >
> > >
> > > DSP FW has no access to userspace so we would need some additional
> > > API
> > > on top of DMA_BUF_SET_NAME etc to get physical hardware pages ?
> >
> > The dma-buf api currently can share guest memory sg-lists.
>
> Ok, IIUC buffers can either be shared using the GPU proposed APIs
> (above) or using the dma-buf API to share via userspace ?

If we restrict ourselves to guest-sg lists only, then the current
dma-buf API is sufficient to share buffers.  From example, virtio-gpu
can allocate with the following hypercall (as it does now):

struct virtio_gpu_resource_attach_backing {
 struct virtio_gpu_ctrl_hdr hdr;
 __le32 resource_id;
 __le32 nr_entries;
   *struct struct virtio_gpu_mem_entry */
};

Then in the guest kernel, virtio-{video, snd} can get the sg-list via
dma_buf_map_attachment, and then have a hypercall of it's own:

struct virtio_video_resource_import {
 struct virtio_video_ctrl_hdr hdr;
 __le32 video_resource_id;
 __le32 nr_entries;
   *struct struct virtio_gpu_mem_entry */
};

Then it can create dmabuf on the host or get the HW address from the SG list.

The complications come in from sharing host allocated buffers ... for
that we may need a method to translate from guest fds to universal
"virtualized" resource IDs.  I've heard talk about the need to
translate from guest fence fds to host fence fds as well.

> My preference
> would be to use teh more direct GPU APIs sending physical page
> addresses from Guest to device driver. I guess this is your use case
> too ?

For my use case, guest memory is sufficient, especially given the
direction towards 

Re: [PATCH] audio: fix audio recording

[Zoltán Kővágó]

On 2019-11-19 20:43, Richard Henderson wrote:

On 11/19/19 9:01 AM, Philippe Mathieu-Daudé wrote:

Cc'ing Zoltán.

On 11/19/19 7:58 AM, Volker Rümelin wrote:

With current code audio recording with all audio backends
except PulseAudio and DirectSound is broken. The generic audio
recording buffer management forgot to update the current read
position after a read.

Fixes: ff095e5231 "audio: api for mixeng code free backends"

Signed-off-by: Volker Rümelin 
---
   audio/audio.c | 1 +
   1 file changed, 1 insertion(+)

diff --git a/audio/audio.c b/audio/audio.c
index 7fc3aa9d16..56fae55047 100644
--- a/audio/audio.c
+++ b/audio/audio.c
@@ -1390,6 +1390,7 @@ void *audio_generic_get_buffer_in(HWVoiceIn *hw, size_t
*size)
   size_t read = hw->pcm_ops->read(hw, hw->buf_emul + hw->pos_emul,
   read_len);
   hw->pending_emul += read;
+    hw->pos_emul = (hw->pos_emul + read) % hw->size_emul;


Anyway since read() can return a negative value, both previous assignments
should go after this if/break check...


This isn't read(2).

 size_t (*read)(HWVoiceIn *hw, void *buf, size_t size);

Since this isn't ssize_t, no negative return value possible.


Yes, read failures are handled inside the backends.  If the backend 
really can't read anything, it'll return zero, which is harmless here.


Zoltan

Re: [PATCH] audio: fix audio recording

[Zoltán Kővágó]

On 2019-11-19 07:58, Volker Rümelin wrote:

With current code audio recording with all audio backends
except PulseAudio and DirectSound is broken. The generic audio
recording buffer management forgot to update the current read
position after a read.


Indeed, pos_emul is updated in audio_generic_put_buffer_out_nowrite but 
it's never updated on the capture end.  I tested it with alsa and 
hda-micro and it fixes the problem (that is, if I add in.try-poll=off, 
but I need that for output too).


Thanks.



Fixes: ff095e5231 "audio: api for mixeng code free backends"

Signed-off-by: Volker Rümelin 

Reviewed-by: Zoltán Kővágó 


---
  audio/audio.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/audio/audio.c b/audio/audio.c
index 7fc3aa9d16..56fae55047 100644
--- a/audio/audio.c
+++ b/audio/audio.c
@@ -1390,6 +1390,7 @@ void *audio_generic_get_buffer_in(HWVoiceIn *hw, size_t 
*size)
  size_t read = hw->pcm_ops->read(hw, hw->buf_emul + hw->pos_emul,
  read_len);
  hw->pending_emul += read;
+hw->pos_emul = (hw->pos_emul + read) % hw->size_emul;
  if (read < read_len) {
  break;
  }

Re: [PATCH 2/2] migration/multifd: not use multifd during postcopy

[Wei Yang]

On Tue, Nov 19, 2019 at 11:55:52AM +0100, Juan Quintela wrote:
>Wei Yang  wrote:
>> We don't support multifd during postcopy, but user still could enable
>> both multifd and postcopy. This leads to migration failure.
>>
>> Skip multifd during postcopy.
>>
>> Signed-off-by: Wei Yang 
>
>Reviewed-by: Juan Quintela 
>
>I was working in a different implementation, but I agree with the idea.
>
>My patch series try to decide during negotiation if multifd + everything
>else is setup or not.
>

Look forward your approach :-)

>Thanks, Juan.

-- 
Wei Yang
Help you, Help me

Re: [PATCH v3 18/33] mips: inline serial_init

[Aleksandar Markovic]

On Wednesday, October 23, 2019, Marc-André Lureau <
marcandre.lur...@redhat.com> wrote:

> The function is specific to mipssim, let's inline it.
>
> Signed-off-by: Marc-André Lureau 
> ---
>  hw/char/serial.c | 16 
>  hw/mips/mips_mipssim.c   | 13 ++---
>  include/hw/char/serial.h |  2 --
>  3 files changed, 10 insertions(+), 21 deletions(-)


Marc-André, hi!

Mismatch between the commit message and the patch content. Not acceptable.

Yours,
Aleksandar


>
> diff --git a/hw/char/serial.c b/hw/char/serial.c
> index 84de2740a7..ca95e09ec9 100644
> --- a/hw/char/serial.c
> +++ b/hw/char/serial.c
> @@ -1023,22 +1023,6 @@ static const TypeInfo serial_io_info = {
>  .class_init = serial_io_class_init,
>  };
>
> -SerialIO *serial_init(int base, qemu_irq irq, int baudbase,
> - Chardev *chr, MemoryRegion *system_io)
> -{
> -SerialIO *self = SERIAL_IO(qdev_create(NULL, TYPE_SERIAL_IO));
> -
> -qdev_prop_set_uint32(DEVICE(self), "baudbase", baudbase);
> -qdev_prop_set_chr(DEVICE(self), "chardev", chr);
> -qdev_prop_set_int32(DEVICE(self), "instance-id", base);
> -qdev_init_nofail(DEVICE(self));
> -
> -sysbus_connect_irq(SYS_BUS_DEVICE(self), 0, irq);
> -memory_region_add_subregion(system_io, base, >serial.io);
> -
> -return self;
> -}
> -
>  static Property serial_properties[] = {
>  DEFINE_PROP_CHR("chardev", SerialState, chr),
>  DEFINE_PROP_UINT32("baudbase", SerialState, baudbase, 115200),
> diff --git a/hw/mips/mips_mipssim.c b/hw/mips/mips_mipssim.c
> index 282bbecb24..26fb8fa4de 100644
> --- a/hw/mips/mips_mipssim.c
> +++ b/hw/mips/mips_mipssim.c
> @@ -40,6 +40,7 @@
>  #include "hw/loader.h"
>  #include "elf.h"
>  #include "hw/sysbus.h"
> +#include "hw/qdev-properties.h"
>  #include "exec/address-spaces.h"
>  #include "qemu/error-report.h"
>  #include "sysemu/qtest.h"
> @@ -219,9 +220,15 @@ mips_mipssim_init(MachineState *machine)
>   * A single 16450 sits at offset 0x3f8. It is attached to
>   * MIPS CPU INT2, which is interrupt 4.
>   */
> -if (serial_hd(0))
> -serial_init(0x3f8, env->irq[4], 115200, serial_hd(0),
> -get_system_io());
> +if (serial_hd(0)) {
> +DeviceState *dev = qdev_create(NULL, TYPE_SERIAL_IO);
> +
> +qdev_prop_set_chr(dev, "chardev", serial_hd(0));
> +qdev_prop_set_int32(dev, "instance-id", 0x3f8);
> +qdev_init_nofail(dev);
> +sysbus_connect_irq(SYS_BUS_DEVICE(dev), 0, env->irq[4]);
> +sysbus_add_io(SYS_BUS_DEVICE(dev), 0x3f8, _IO(dev)->
> serial.io);
> +}
>
>  if (nd_table[0].used)
>  /* MIPSnet uses the MIPS CPU INT0, which is interrupt 2. */
> diff --git a/include/hw/char/serial.h b/include/hw/char/serial.h
> index cf9cdafaee..40e35e6fff 100644
> --- a/include/hw/char/serial.h
> +++ b/include/hw/char/serial.h
> @@ -109,8 +109,6 @@ void serial_set_frequency(SerialState *s, uint32_t
> frequency);
>  #define TYPE_SERIAL_IO "serial-io"
>  #define SERIAL_IO(s) OBJECT_CHECK(SerialIO, (s), TYPE_SERIAL_IO)
>
> -SerialIO *serial_init(int base, qemu_irq irq, int baudbase,
> -  Chardev *chr, MemoryRegion *system_io);
>  SerialMM *serial_mm_init(MemoryRegion *address_space,
>   hwaddr base, int regshift,
>   qemu_irq irq, int baudbase,
> --
> 2.23.0.606.g08da6496b6
>
>
>

Re: [PATCH for-5.0 v5 04/23] ppc/pnv: Dump the XIVE NVT table

[David Gibson]

On Fri, Nov 15, 2019 at 05:24:17PM +0100, Cédric Le Goater wrote:
> This is useful to dump the saved contexts of the vCPUs : configuration
> of the base END index of the vCPU and the Interrupt Pending Buffer
> register, which is updated when an interrupt can not be presented.
> 
> When dumping the NVT table, we skip empty indirect pages which are not
> necessarily allocated.
> 
> Signed-off-by: Cédric Le Goater 
> ---
>  include/hw/ppc/xive_regs.h |  2 ++
>  hw/intc/pnv_xive.c | 30 ++
>  2 files changed, 32 insertions(+)
> 
> diff --git a/include/hw/ppc/xive_regs.h b/include/hw/ppc/xive_regs.h
> index 1a5622f8ded8..94338b4b551e 100644
> --- a/include/hw/ppc/xive_regs.h
> +++ b/include/hw/ppc/xive_regs.h
> @@ -252,6 +252,8 @@ typedef struct XiveNVT {
>  uint32_tw0;
>  #define NVT_W0_VALID PPC_BIT32(0)
>  uint32_tw1;
> +#define NVT_W1_EQ_BLOCK  PPC_BITMASK32(0, 3)
> +#define NVT_W1_EQ_INDEX  PPC_BITMASK32(4, 31)
>  uint32_tw2;
>  uint32_tw3;
>  uint32_tw4;
> diff --git a/hw/intc/pnv_xive.c b/hw/intc/pnv_xive.c
> index a4d80fd5e79c..02faf4135e48 100644
> --- a/hw/intc/pnv_xive.c
> +++ b/hw/intc/pnv_xive.c
> @@ -1554,6 +1554,27 @@ static const MemoryRegionOps pnv_xive_pc_ops = {
>  },
>  };
>  
> +/*
> + * skiboot uses an indirect NVT table with 64k subpages
> + */
> +#define XIVE_NVT_COUNT  (1 << XIVE_NVT_SHIFT)
> +#define XIVE_NVT_PER_PAGE   (0x1 / sizeof(XiveNVT))

Hrm.  So skiboot uses 64kiB pages, but how does the hardware know
that?  Is the hw fixed to 64kiB pages, or is there some register
controlling the subpage size?  In which case shouldn't you be looking
at that rather than assuming 64kiB?

> +static void xive_nvt_pic_print_info(XiveNVT *nvt, uint32_t nvt_idx,
> +Monitor *mon)
> +{
> +uint8_t  eq_blk = xive_get_field32(NVT_W1_EQ_BLOCK, nvt->w1);
> +uint32_t eq_idx = xive_get_field32(NVT_W1_EQ_INDEX, nvt->w1);
> +
> +if (!xive_nvt_is_valid(nvt)) {
> +return;
> +}
> +
> +monitor_printf(mon, "  %08x end:%02x/%04x IPB:%02x\n", nvt_idx,
> +   eq_blk, eq_idx,
> +   xive_get_field32(NVT_W4_IPB, nvt->w4));
> +}
> +
>  void pnv_xive_pic_print_info(PnvXive *xive, Monitor *mon)
>  {
>  XiveRouter *xrtr = XIVE_ROUTER(xive);
> @@ -1562,6 +1583,7 @@ void pnv_xive_pic_print_info(PnvXive *xive, Monitor 
> *mon)
>  uint32_t nr_ipis = pnv_xive_nr_ipis(xive, blk);
>  XiveEAS eas;
>  XiveEND end;
> +XiveNVT nvt;
>  int i;
>  
>  monitor_printf(mon, "XIVE[%x] Source %08x .. %08x\n", blk, srcno0,
> @@ -1590,6 +1612,14 @@ void pnv_xive_pic_print_info(PnvXive *xive, Monitor 
> *mon)
>  while (!xive_router_get_end(xrtr, blk, i, )) {
>  xive_end_eas_pic_print_info(, i++, mon);
>  }
> +
> +monitor_printf(mon, "XIVE[%x] NVTT %08x .. %08x\n", blk, 0,
> +   XIVE_NVT_COUNT - 1);
> +for (i = 0; i < XIVE_NVT_COUNT; i += XIVE_NVT_PER_PAGE) {
> +while (!xive_router_get_nvt(xrtr, blk, i, )) {
> +xive_nvt_pic_print_info(, i++, mon);
> +}
> +}
>  }
>  
>  static void pnv_xive_reset(void *dev)

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [PATCH] ppc/pnv: Create BMC devices at machine init

[David Gibson]

On Tue, Nov 19, 2019 at 07:49:33AM +0100, Cédric Le Goater wrote:
> On 19/11/2019 01:52, David Gibson wrote:
> > On Mon, Nov 18, 2019 at 10:22:22AM +0100, Cédric Le Goater wrote:
> >> The BMC of the OpenPOWER systems monitors the machine state using
> >> sensors, controls the power and controls the access to the PNOR flash
> >> device containing the firmware image required to boot the host.
> >>
> >> QEMU models the power cycle process, access to the sensors and access
> >> to the PNOR device. But, for these features to be available, the QEMU
> >> PowerNV machine needs two extras devices on the command line, an IPMI
> >> BT device for communication and a BMC backend device:
> >>
> >>   -device ipmi-bmc-sim,id=bmc0 -device isa-ipmi-bt,bmc=bmc0,irq=10
> >>
> >> The BMC properties are then defined accordingly in the device tree and
> >> OPAL self adapts. If a BMC device and an IPMI BT device are not
> >> available, OPAL does not try to communicate with the BMC in any
> >> manner. This is not how real systems behave.
> >>
> >> To be closer to the default behavior, create an IPMI BMC simulator
> >> device and an IPMI BT device at machine initialization time. We loose
> >> the ability to define an external BMC device but there are benefits:
> >>
> >>   - a better match with real systems,
> >>   - a better test coverage of the OPAL code,
> >>   - system powerdown and reset commands that work,
> >>   - a QEMU device tree compliant with the specifications (*).
> >>
> >> (*) Still needs a MBOX device.
> >>
> >> Signed-off-by: Cédric Le Goater 
> > 
> > This doesn't apply to ppc-for-5.0 for me.  I'm not sure which change
> > in there it's conflicting with, but there seems to be something.
> 
> Sorry I should have been more precise.
> 
> 
> This is because we need an IPMI patch to be merged first in 
> Corey's tree :
> 
>   ipmi: Add support to customize OEM functions
>   http://patchwork.ozlabs.org/patch/1185187/
> 
> and another one merged in the PPC tree: 
> 
>   ppc/pnv: Add HIOMAP commands
>   http://patchwork.ozlabs.org/patch/1185185/
> 
> 
> David, if Corey agrees, I think it would be simpler if you took 
> them all.

Ok.  Corey, could I get an Acked-by from you?

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [PATCH for-5.0 v5 05/23] ppc/pnv: Quiesce some XIVE errors

[David Gibson]

On Fri, Nov 15, 2019 at 05:24:18PM +0100, Cédric Le Goater wrote:
> When dumping the END and NVT tables, the error logging is too noisy.
> 
> Signed-off-by: Cédric Le Goater 

Applied, thanks.

> ---
>  hw/intc/pnv_xive.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/intc/pnv_xive.c b/hw/intc/pnv_xive.c
> index 02faf4135e48..a394331ddd6a 100644
> --- a/hw/intc/pnv_xive.c
> +++ b/hw/intc/pnv_xive.c
> @@ -29,7 +29,7 @@
>  
>  #include "pnv_xive_regs.h"
>  
> -#define XIVE_DEBUG
> +#undef XIVE_DEBUG
>  
>  /*
>   * Virtual structures table (VST)
> @@ -157,7 +157,9 @@ static uint64_t pnv_xive_vst_addr_indirect(PnvXive *xive, 
> uint32_t type,
>  vsd = ldq_be_dma(_space_memory, vsd_addr);
>  
>  if (!(vsd & VSD_ADDRESS_MASK)) {
> +#ifdef XIVE_DEBUG
>  xive_error(xive, "VST: invalid %s entry %x !?", info->name, idx);
> +#endif
>  return 0;
>  }
>  
> @@ -178,7 +180,9 @@ static uint64_t pnv_xive_vst_addr_indirect(PnvXive *xive, 
> uint32_t type,
>  vsd = ldq_be_dma(_space_memory, vsd_addr);
>  
>  if (!(vsd & VSD_ADDRESS_MASK)) {
> +#ifdef XIVE_DEBUG
>  xive_error(xive, "VST: invalid %s entry %x !?", info->name, idx);
> +#endif
>  return 0;
>  }
>  

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [PATCH] vfio: don't ignore return value of migrate_add_blocker

[Alex Williamson]

On Thu, 14 Nov 2019 14:34:49 +0100
Jens Freimann  wrote:

> When an error occurs in migrate_add_blocker() it sets a
> negative return value and uses error pointer we pass in.
> Instead of just looking at the error pointer check for a negative return
> value and avoid a coverity error because the return value is
> set but never used. This fixes CID 1407219.
> 
> Fixes: f045a0104c8c ("vfio: unplug failover primary device before
>   migration")
> Signed-off-by: Jens Freimann 
> ---
>  hw/vfio/pci.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index e6569a7968..ed01774673 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -2737,7 +2737,7 @@ static void vfio_realize(PCIDevice *pdev, Error **errp)
>  error_setg(>migration_blocker,
>  "VFIO device doesn't support migration");
>  ret = migrate_add_blocker(vdev->migration_blocker, );
> -if (err) {
> +if (ret) {
>  error_propagate(errp, err);
>  error_free(vdev->migration_blocker);
>  return;

Slightly late notice, but I did include this in my last pull request
and it's included in v4.2.0-rc2 with Stefano and Philippe's R-b.
Thanks,

Alex

Re: [PATCH v9 Kernel 2/5] vfio iommu: Add ioctl defination to get dirty pages bitmap.

[Alex Williamson]

On Fri, 15 Nov 2019 05:10:53 +
"Tian, Kevin"  wrote:

> > From: Alex Williamson
> > Sent: Friday, November 15, 2019 11:22 AM
> > 
> > On Thu, 14 Nov 2019 21:40:35 -0500
> > Yan Zhao  wrote:
> >   
> > > On Fri, Nov 15, 2019 at 05:06:25AM +0800, Alex Williamson wrote:  
> > > > On Fri, 15 Nov 2019 00:26:07 +0530
> > > > Kirti Wankhede  wrote:
> > > >  
> > > > > On 11/14/2019 1:37 AM, Alex Williamson wrote:  
> > > > > > On Thu, 14 Nov 2019 01:07:21 +0530
> > > > > > Kirti Wankhede  wrote:
> > > > > >  
> > > > > >> On 11/13/2019 4:00 AM, Alex Williamson wrote:  
> > > > > >>> On Tue, 12 Nov 2019 22:33:37 +0530
> > > > > >>> Kirti Wankhede  wrote:
> > > > > >>>  
> > > > >  All pages pinned by vendor driver through vfio_pin_pages API  
> > should be  
> > > > >  considered as dirty during migration. IOMMU container  
> > maintains a list of  
> > > > >  all such pinned pages. Added an ioctl defination to get bitmap 
> > > > >  of  
> > such  
> > > > > >>>
> > > > > >>> definition
> > > > > >>>  
> > > > >  pinned pages for requested IO virtual address range.  
> > > > > >>>
> > > > > >>> Additionally, all mapped pages are considered dirty when  
> > physically  
> > > > > >>> mapped through to an IOMMU, modulo we discussed devices  
> > opting in to  
> > > > > >>> per page pinning to indicate finer granularity with a TBD  
> > mechanism to  
> > > > > >>> figure out if any non-opt-in devices remain.
> > > > > >>>  
> > > > > >>
> > > > > >> You mean, in case of device direct assignment (device pass  
> > through)?  
> > > > > >
> > > > > > Yes, or IOMMU backed mdevs.  If vfio_dmas in the container are  
> > fully  
> > > > > > pinned and mapped, then the correct dirty page set is all mapped  
> > pages.  
> > > > > > We discussed using the vpfn list as a mechanism for vendor drivers  
> > to  
> > > > > > reduce their migration footprint, but we also discussed that we  
> > would  
> > > > > > need a way to determine that all participants in the container have
> > > > > > explicitly pinned their working pages or else we must consider the
> > > > > > entire potential working set as dirty.
> > > > > >  
> > > > >
> > > > > How can vendor driver tell this capability to iommu module? Any  
> > suggestions?  
> > > >
> > > > I think it does so by pinning pages.  Is it acceptable that if the
> > > > vendor driver pins any pages, then from that point forward we consider
> > > > the IOMMU group dirty page scope to be limited to pinned pages?  
> > There  
> > > > are complications around non-singleton IOMMU groups, but I think  
> > we're  
> > > > already leaning towards that being a non-worthwhile problem to solve.
> > > > So if we require that only singleton IOMMU groups can pin pages and  
> > we  
> > > > pass the IOMMU group as a parameter to
> > > > vfio_iommu_driver_ops.pin_pages(), then the type1 backend can set a
> > > > flag on its local vfio_group struct to indicate dirty page scope is
> > > > limited to pinned pages.  We might want to keep a flag on the
> > > > vfio_iommu struct to indicate if all of the vfio_groups for each
> > > > vfio_domain in the vfio_iommu.domain_list dirty page scope limited to
> > > > pinned pages as an optimization to avoid walking lists too often.  Then
> > > > we could test if vfio_iommu.domain_list is not empty and this new flag
> > > > does not limit the dirty page scope, then everything within each
> > > > vfio_dma is considered dirty.
> > > >  
> > >
> > > hi Alex
> > > could you help clarify whether my understandings below are right?
> > > In future,
> > > 1. for mdev and for passthrough device withoug hardware ability to track
> > > dirty pages, the vendor driver has to explicitly call
> > > vfio_pin_pages()/vfio_unpin_pages() + a flag to tell vfio its dirty page 
> > > set.  
> > 
> > For non-IOMMU backed mdevs without hardware dirty page tracking,
> > there's no change to the vendor driver currently.  Pages pinned by the
> > vendor driver are marked as dirty.  
> 
> What about the vendor driver can figure out, in software means, which
> pinned pages are actually dirty? In that case, would a separate mark_dirty
> interface make more sense? Or introduce read/write flag to the pin_pages
> interface similar to DMA API? Existing drivers always set both r/w flags but
> just in case then a specific driver may set read-only or write-only...

You're jumping ahead to 2. below, where my reply is that we need to
extend the interface to allow the vendor driver to manipulate
clean/dirty state.  I don't know exactly what those interfaces should
look like, but yes, something should exist to allow that control.  If
the default is to mark pinned pages dirty, then we might need a
separate pin_pages_clean callback.

> > For any IOMMU backed device, mdev or direct assignment, all mapped
> > memory would be considered dirty unless there are explicit calls to pin
> > pages on top of the IOMMU page pinning and mapping.  These would likely
> > be enabled only when 

[ANNOUNCE] QEMU 4.2.0-rc2 is now available

[Michael Roth]

Hello,

On behalf of the QEMU Team, I'd like to announce the availability of the
third release candidate for the QEMU 4.2 release.  This release is meant
for testing purposes and should not be used in a production environment.

  http://download.qemu-project.org/qemu-4.2.0-rc2.tar.xz
  http://download.qemu-project.org/qemu-4.2.0-rc2.tar.xz.sig

You can help improve the quality of the QEMU 4.2 release by testing this
release and reporting bugs on Launchpad:

  https://bugs.launchpad.net/qemu/

The release plan, as well a documented known issues for release
candidates, are available at:

  http://wiki.qemu.org/Planning/4.2

Please add entries to the ChangeLog for the 4.2 release below:

  http://wiki.qemu.org/ChangeLog/4.2

Thank you to everyone involved!

Changes since rc1:

39e2821077: Update version for v4.2.0-rc2 release (Peter Maydell)
abc7cf3655: hw/mips/gt64xxx: Remove dynamic field width from trace events 
(Philippe Mathieu-Daudé)
10f9f1fbed: hw/block/pflash: Remove dynamic field width from trace events 
(Philippe Mathieu-Daudé)
04c9c81b8f: target/arm: Support EL0 v7m msr/mrs for CONFIG_USER_ONLY (Richard 
Henderson)
d46ad79efa: target/arm: Relax r13 restriction for ldrex/strex for v8.0 (Richard 
Henderson)
655b02646d: target/arm: Do not reject rt == rt2 for strexd (Richard Henderson)
6623d21445: net/cadence_gem: Set PHY autonegotiation restart status (Linus 
Ziegert)
3a6606c7aa: ssi: xilinx_spips: Skip spi bus update for a few register writes 
(Sai Pavan Boddu)
6e553f2a1b: target/arm: Merge arm_cpu_vq_map_next_smaller into sole caller 
(Richard Henderson)
83ad95957c: pl031: Expose RTCICR as proper WC register (Alexander Graf)
7a3e29b12f: mc146818rtc: fix timer interrupt reinjection again (Paolo Bonzini)
3ae32adff1: Revert "mc146818rtc: fix timer interrupt reinjection" (Paolo 
Bonzini)
0d074bf8e7: scsi: deprecate scsi-disk (Paolo Bonzini)
2f34ebf222: hw/i386: Move save_tsc_khz from PCMachineClass to X86MachineClass 
(Liam Merwick)
62e9dc3582: docs/microvm.rst: add instructions for shutting down the guest 
(Sergio Lopez)
ff9d708933: docs/microvm.rst: fix alignment in "Limitations" (Sergio Lopez)
7771e1ae1b: vfio: vfio-pci requires EDID (Paolo Bonzini)
c9d6da3a5e: hw/i386: Fix compiler warning when CONFIG_IDE_ISA is disabled 
(Thomas Huth)
7fac38635e: target/i386: Export TAA_NO bit to guests (Pawan Gupta)
7f7a585d5b: target/i386: add PSCHANGE_NO bit for the ARCH_CAPABILITIES MSR 
(Paolo Bonzini)
c3157b74c4: microvm: fix memory leak in microvm_fix_kernel_cmdline (Sergio 
Lopez)
b73f059cf2: scripts: Detect git worktrees for get_maintainer.pl --git (Alexey 
Kardashevskiy)
2895aaa139: monitor/qmp: resume monitor when clearing its queue (Wolfgang 
Bumiller)
296416ff0f: tests: More iotest 223 improvements (Eric Blake)
a98b1a1fef: iotests: Include QMP input in .out files (Eric Blake)
f3923a72f1: iotests: Switch nbd tests to use Unix rather than TCP (Eric Blake)
509e91c127: iotests: Fix 173 (Eric Blake)
052db8e714: MAINTAINERS: add more bitmap-related to Dirty Bitmaps section 
(Vladimir Sementsov-Ogievskiy)
93676c88d7: nbd: Don't send oversize strings (Eric Blake)
cf7c49cf6a: bitmap: Enforce maximum bitmap name length (Eric Blake)
9d7ab222da: nbd/server: Prefer heap over stack for parsing client names (Eric 
Blake)
f61ffad53f: qemu-coroutine-sleep: Silence Coverity warning (Eric Blake)
a4d925f8f0: iotests: Test NBD client reconnection (Andrey Shinkevich)
29b95c992a: vfio: vfio-pci requires EDID (Paolo Bonzini)
ed92369a57: vfio: don't ignore return value of migrate_add_blocker (Jens 
Freimann)
1335d64323: hw/vfio/pci: Fix double free of migration_blocker (Michal Privoznik)
b1f6a8e180: iotests: Test multiple blockdev-snapshot calls (Kevin Wolf)
ae0f57f0aa: block: Remove 'backing': null from bs->{explicit_,}options (Kevin 
Wolf)
d44abcc0f7: iotests: Fix "no qualified output" error path (Kevin Wolf)
dbf231d7b4: qemu-iotests/iotests.py: improve assert_qmp message (Vladimir 
Sementsov-Ogievskiy)
0285747737: seabios: update to pre-1.13 snapshot again (Gerd Hoffmann)
cd8843ff25: mos6522: fix T1 and T2 timers (Laurent Vivier)
165dc3edd7: spapr/kvm: Set default cpu model for all machine classes (David 
Gibson)
a49f62b9fd: spapr: Add /chosen to FDT only at reset time to preserve kernel and 
initramdisk (Alexey Kardashevskiy)
0a83b47055: ppc: Skip partially initialized vCPUs in 'info pic' (Greg Kurz)
35886de140: xive, xics: Fix reference counting on CPU objects (Greg Kurz)
0990ce6a2e: ppc: Add intc_destroy() handlers to 
SpaprInterruptController/PnvChip (Greg Kurz)
369e8f5bbd: buildfix: update texinfo menu (Gerd Hoffmann)
6911fde410: riscv/virt: Increase flash size (Alistair Francis)
3158add2bd: opensbi: Upgrade from v0.4 to v0.5 (Alistair Francis)
7ec5d3030b: target/riscv: Remove atomic accesses to MIP CSR (Alistair Francis)
f480f6e8c5: remove unnecessary ifdef TARGET_RISCV64 (hiroyuki.obinata)
0221d73ce6: seabios: update to pre-1.13 snapshot (Gerd Hoffmann)

Re: [PATCH 2/5] hw/ppc/pnv_xscom: PBA bar mask values are incorrect with homer/occ sizes

[David Gibson]

On Tue, Nov 19, 2019 at 11:20:53PM +0530, Balamuruhan S wrote:
> homer/occ sizes are calculated in skiboot with `(mask | 0xf) + 1`,
> and from xscom access should return correct mask values instead of actual
> sizes.
> 
> Signed-off-by: Cédric Le Goater 
> Signed-off-by: Balamuruhan S 
> ---
>  hw/ppc/pnv_xscom.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/ppc/pnv_xscom.c b/hw/ppc/pnv_xscom.c
> index f01d788a65..cdd5fa356e 100644
> --- a/hw/ppc/pnv_xscom.c
> +++ b/hw/ppc/pnv_xscom.c
> @@ -46,6 +46,10 @@
>  #define P9_PBA_BARMASK0 0x5012b04
>  #define P9_PBA_BARMASK2 0x5012b06
>  
> +/* Mask to calculate Homer/Occ size */
> +#define HOMER_SIZE_MASK 0x0030ull
> +#define OCC_SIZE_MASK   0x0070ull

Uuuh... AFAICT these defines have identical values to
PNV_HOMER_SIZE and PNV_OCC_COMMON_AREA_SIZE, so I don't see what this
patch is actually changing.


>  static void xscom_complete(CPUState *cs, uint64_t hmer_bits)
>  {
>  /*
> @@ -90,9 +94,8 @@ static uint64_t xscom_read_default(PnvChip *chip, uint32_t 
> pcba)
>  return PNV_HOMER_BASE(chip);
>  
>  case P9_PBA_BARMASK0: /* P9 homer region size */
> -return PNV9_HOMER_SIZE;
>  case P8_PBA_BARMASK0: /* P8 homer region size */
> -return PNV_HOMER_SIZE;
> +return HOMER_SIZE_MASK;
>  
>  case P9_PBA_BAR2: /* P9 occ common area */
>  return PNV9_OCC_COMMON_AREA(chip);
> @@ -100,9 +103,8 @@ static uint64_t xscom_read_default(PnvChip *chip, 
> uint32_t pcba)
>  return PNV_OCC_COMMON_AREA(chip);
>  
>  case P9_PBA_BARMASK2: /* P9 occ common area size */
> -return PNV9_OCC_COMMON_AREA_SIZE;
>  case P8_PBA_BARMASK2: /* P8 occ common area size */
> -return PNV_OCC_COMMON_AREA_SIZE;
> +return OCC_SIZE_MASK;
>  
>  case 0x1010c00: /* PIBAM FIR */
>  case 0x1010c03: /* PIBAM FIR MASK */

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [PATCH for-5.0] xive/kvm: Trigger interrupts from userspace

[David Gibson]

On Tue, Nov 19, 2019 at 09:15:52AM +0100, Cédric Le Goater wrote:
> On 19/11/2019 01:47, David Gibson wrote:
> > On Mon, Nov 18, 2019 at 04:37:16PM +0100, Cédric Le Goater wrote:
> >> On 18/11/2019 16:12, Greg Kurz wrote:
> >>> When using the XIVE KVM device, the trigger page is directly accessible
> >>> in QEMU. Unlike with XICS, no need to ask KVM to fire the interrupt. A
> >>> simple store on the trigger page does the job.
> >>>
> >>> Just call xive_esb_trigger().
> >>
> >> Yes but the KVM XIVE device does a few other checks. 
> >>
> >> It checks that the interrupt was correctly initialized at the KVM device
> >> level. We should be fine in QEMU which has similar checks.
> >>
> >> It caches the LSI assertion level. We should be fine also because it is
> >> useless in KVM when using the XIVE native exploitation mode.
> >>
> >> It checks it is not a passthru interrupt. Any idea on how to check this 
> >> condition under QEMU ? 
> >>  
> >>> This may improve performance of emulated devices that go through
> >>> qemu_set_irq(), eg. virtio devices created with ioeventfd=off or
> >>> configured by the guest to use LSI interrupts, which aren't really
> >>> recommended setups.
> >>
> >> LGTM.
> > 
> > Ok, between the comments above and this, I'm not sure if this is ready
> > to merge or not.
> 
> I think it is. 
> 
> With this change, we are loosing a check on passthrough interrupts but 
> I am not sure how critical this is given that QEMU can anyhow bypass 
> KVM and trigger the interrupt using a store on the ESB page. 
> 
> >> Any figures to share ? 
> 
> I am torturing Greg to have numbers :) but he resisted well.
> 
> >> C.
> >>
> >>> Signed-off-by: Greg Kurz 
> 
> Let's move on.
> 
> Reviewed-by: Cédric Le Goater 

Works for me.  Applied.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [PATCH 2/5] hw/ppc/pnv_xscom: PBA bar mask values are incorrect with homer/occ sizes

[David Gibson]

On Wed, Nov 20, 2019 at 09:00:32AM +1100, David Gibson wrote:
> On Wed, Nov 20, 2019 at 08:56:18AM +1100, David Gibson wrote:
> > On Tue, Nov 19, 2019 at 11:20:53PM +0530, Balamuruhan S wrote:
> > > homer/occ sizes are calculated in skiboot with `(mask | 0xf) + 1`,
> > > and from xscom access should return correct mask values instead of actual
> > > sizes.
> > > 
> > > Signed-off-by: Cédric Le Goater 
> > > Signed-off-by: Balamuruhan S 
> > > ---
> > >  hw/ppc/pnv_xscom.c | 10 ++
> > >  1 file changed, 6 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/hw/ppc/pnv_xscom.c b/hw/ppc/pnv_xscom.c
> > > index f01d788a65..cdd5fa356e 100644
> > > --- a/hw/ppc/pnv_xscom.c
> > > +++ b/hw/ppc/pnv_xscom.c
> > > @@ -46,6 +46,10 @@
> > >  #define P9_PBA_BARMASK0 0x5012b04
> > >  #define P9_PBA_BARMASK2 0x5012b06
> > >  
> > > +/* Mask to calculate Homer/Occ size */
> > > +#define HOMER_SIZE_MASK 0x0030ull
> > > +#define OCC_SIZE_MASK   0x0070ull
> > 
> > Uuuh... AFAICT these defines have identical values to
> > PNV_HOMER_SIZE and PNV_OCC_COMMON_AREA_SIZE, so I don't see what this
> > patch is actually changing.
> 
> Oh, sorry, missed that the values were changed in 1/5.  Would have
> been easier to follow if the two patches were folded together, but
> never mind.  Applied.

Ugh.. or not.  The first patch doesn't apply for me, looks like it
needs a rebase (or you have something else in your tree I don't know
about).

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [PATCH 2/5] hw/ppc/pnv_xscom: PBA bar mask values are incorrect with homer/occ sizes

[David Gibson]

On Wed, Nov 20, 2019 at 08:56:18AM +1100, David Gibson wrote:
> On Tue, Nov 19, 2019 at 11:20:53PM +0530, Balamuruhan S wrote:
> > homer/occ sizes are calculated in skiboot with `(mask | 0xf) + 1`,
> > and from xscom access should return correct mask values instead of actual
> > sizes.
> > 
> > Signed-off-by: Cédric Le Goater 
> > Signed-off-by: Balamuruhan S 
> > ---
> >  hw/ppc/pnv_xscom.c | 10 ++
> >  1 file changed, 6 insertions(+), 4 deletions(-)
> > 
> > diff --git a/hw/ppc/pnv_xscom.c b/hw/ppc/pnv_xscom.c
> > index f01d788a65..cdd5fa356e 100644
> > --- a/hw/ppc/pnv_xscom.c
> > +++ b/hw/ppc/pnv_xscom.c
> > @@ -46,6 +46,10 @@
> >  #define P9_PBA_BARMASK0 0x5012b04
> >  #define P9_PBA_BARMASK2 0x5012b06
> >  
> > +/* Mask to calculate Homer/Occ size */
> > +#define HOMER_SIZE_MASK 0x0030ull
> > +#define OCC_SIZE_MASK   0x0070ull
> 
> Uuuh... AFAICT these defines have identical values to
> PNV_HOMER_SIZE and PNV_OCC_COMMON_AREA_SIZE, so I don't see what this
> patch is actually changing.

Oh, sorry, missed that the values were changed in 1/5.  Would have
been easier to follow if the two patches were folded together, but
never mind.  Applied.

> 
> 
> >  static void xscom_complete(CPUState *cs, uint64_t hmer_bits)
> >  {
> >  /*
> > @@ -90,9 +94,8 @@ static uint64_t xscom_read_default(PnvChip *chip, 
> > uint32_t pcba)
> >  return PNV_HOMER_BASE(chip);
> >  
> >  case P9_PBA_BARMASK0: /* P9 homer region size */
> > -return PNV9_HOMER_SIZE;
> >  case P8_PBA_BARMASK0: /* P8 homer region size */
> > -return PNV_HOMER_SIZE;
> > +return HOMER_SIZE_MASK;
> >  
> >  case P9_PBA_BAR2: /* P9 occ common area */
> >  return PNV9_OCC_COMMON_AREA(chip);
> > @@ -100,9 +103,8 @@ static uint64_t xscom_read_default(PnvChip *chip, 
> > uint32_t pcba)
> >  return PNV_OCC_COMMON_AREA(chip);
> >  
> >  case P9_PBA_BARMASK2: /* P9 occ common area size */
> > -return PNV9_OCC_COMMON_AREA_SIZE;
> >  case P8_PBA_BARMASK2: /* P8 occ common area size */
> > -return PNV_OCC_COMMON_AREA_SIZE;
> > +return OCC_SIZE_MASK;
> >  
> >  case 0x1010c00: /* PIBAM FIR */
> >  case 0x1010c03: /* PIBAM FIR MASK */
> 



-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [PULL for-4.2-rc2 0/2] Tracing patches

[Aleksandar Markovic]

On Tue, Nov 19, 2019 at 10:14 PM Aleksandar Markovic
 wrote:
>
> On Tue, Nov 19, 2019 at 9:46 PM Stefan Hajnoczi  wrote:
> >
> > The following changes since commit f086f22d6c068ba151b0f6e81e75a64f130df712:
> >
> >   Merge remote-tracking branch 
> > 'remotes/awilliam/tags/vfio-fixes-20191118.0' into staging (2019-11-18 
> > 21:35:48 +)
> >
> > are available in the Git repository at:
> >
> >   https://github.com/stefanha/qemu.git tags/tracing-pull-request
> >
> > for you to fetch changes up to 6b904f1a528a6d8c21f7fbdeab13b9603d1b6df7:
> >
> >   hw/mips/gt64xxx: Remove dynamic field width from trace events (2019-11-19 
> > 16:17:05 +)
> >
> > 
> > Pull request
> >
> > Tracing fixes for MIPS.
> >
> > 
> >
>
> Hello, Stefan, Philippe, Peter.
>
> This appears to be a duplicate of the pull request sent today by Philippe
> (and already applied by Peter just hours ago):
>
> https://lists.gnu.org/archive/html/qemu-devel/2019-11/msg02894.html
>
> The patches from the two pull requests appear to be identical, except
> some minor details in commit messages: Stefan's versions contain
> "Message-Id:" identifiers, while Philippe's don't (my suggestion to
> Philippe is to include "Message-Id:" for all patches that are part of any
> pull request in future; this can be achieved effortlessly/automatically
> by applying patches using patchwork).
>
> In summary, for this very situation, it looks to me we are all set, no need
> for Peter to process this pull request.
>

And just another really friendly advice for Philippe: When you apply
some patches or a series to your pull request, just inform others
about that by replying to the patches or a series: "I applied XXX to
my queue/pull request" - this helps avoiding duplicate efforts like
it happened here. This is also reminder to me too, I didn't do it in
all cases of my applying to my my pull requests, and I should have,
but I will improve too.

Thanks for these fixes!

Aleksandar

> Regards,
> Aleksandar
>
> > Philippe Mathieu-Daudé (2):
> >   hw/block/pflash: Remove dynamic field width from trace events
> >   hw/mips/gt64xxx: Remove dynamic field width from trace events
> >
> >  hw/block/pflash_cfi01.c |  8 
> >  hw/block/pflash_cfi02.c |  8 
> >  hw/block/trace-events   |  8 
> >  hw/mips/gt64xxx_pci.c   | 16 
> >  hw/mips/trace-events|  4 ++--
> >  5 files changed, 22 insertions(+), 22 deletions(-)
> >
> > --
> > 2.23.0
> >
> >

Re: [PATCH v35 05/13] target/avr: Add instruction translation - Arithmetic and Logic Instructions

[Michael Rolnik]

Sounds good, thanks!

On Tue, Nov 19, 2019 at 11:18 PM Aleksandar Markovic
 wrote:
>
> On Tue, Nov 19, 2019 at 9:09 PM Michael Rolnik  wrote:
> >
> > Hi Aleksandar et al.
> >
> > how is it going? should I rebase or not?
> >
> > Michael
> >
>
> I am just in the process of taking a detailed look to the whole series.
>
> I don't have any serious objection so far, I may just suggest a couple
> of things that will improve readability of the code - so nothing of some
> really serious nature.
>
> Stay tuned (and be patient). Will hear from me soon.
>
> Yours, Aleksandar



-- 
Best Regards,
Michael Rolnik

Re: [PATCH v35 05/13] target/avr: Add instruction translation - Arithmetic and Logic Instructions

[Aleksandar Markovic]

On Tue, Nov 19, 2019 at 9:09 PM Michael Rolnik  wrote:
>
> Hi Aleksandar et al.
>
> how is it going? should I rebase or not?
>
> Michael
>

I am just in the process of taking a detailed look to the whole series.

I don't have any serious objection so far, I may just suggest a couple
of things that will improve readability of the code - so nothing of some
really serious nature.

Stay tuned (and be patient). Will hear from me soon.

Yours, Aleksandar

Re: [PULL for-4.2-rc2 0/2] Tracing patches

[Aleksandar Markovic]

On Tue, Nov 19, 2019 at 9:46 PM Stefan Hajnoczi  wrote:
>
> The following changes since commit f086f22d6c068ba151b0f6e81e75a64f130df712:
>
>   Merge remote-tracking branch 'remotes/awilliam/tags/vfio-fixes-20191118.0' 
> into staging (2019-11-18 21:35:48 +)
>
> are available in the Git repository at:
>
>   https://github.com/stefanha/qemu.git tags/tracing-pull-request
>
> for you to fetch changes up to 6b904f1a528a6d8c21f7fbdeab13b9603d1b6df7:
>
>   hw/mips/gt64xxx: Remove dynamic field width from trace events (2019-11-19 
> 16:17:05 +)
>
> 
> Pull request
>
> Tracing fixes for MIPS.
>
> 
>

Hello, Stefan, Philippe, Peter.

This appears to be a duplicate of the pull request sent today by Philippe
(and already applied by Peter just hours ago):

https://lists.gnu.org/archive/html/qemu-devel/2019-11/msg02894.html

The patches from the two pull requests appear to be identical, except
some minor details in commit messages: Stefan's versions contain
"Message-Id:" identifiers, while Philippe's don't (my suggestion to
Philippe is to include "Message-Id:" for all patches that are part of any
pull request in future; this can be achieved effortlessly/automatically
by applying patches using patchwork).

In summary, for this very situation, it looks to me we are all set, no need
for Peter to process this pull request.

Regards,
Aleksandar

> Philippe Mathieu-Daudé (2):
>   hw/block/pflash: Remove dynamic field width from trace events
>   hw/mips/gt64xxx: Remove dynamic field width from trace events
>
>  hw/block/pflash_cfi01.c |  8 
>  hw/block/pflash_cfi02.c |  8 
>  hw/block/trace-events   |  8 
>  hw/mips/gt64xxx_pci.c   | 16 
>  hw/mips/trace-events|  4 ++--
>  5 files changed, 22 insertions(+), 22 deletions(-)
>
> --
> 2.23.0
>
>

Re: [PATCH] Fix incorrect int->float conversions caught by clang -Wimplicit-int-float-conversion

[Fangrui Song]

Fangrui Song  writes:

> The warning will be enabled by default in clang 10. It is not available for 
> clang <= 9.

>
> qemu/migration/migration.c:2038:24: error: implicit conversion from 'long' to 
> 'double' changes value from 9223372036854775807 to 9223372036854775808 
> [-Werror,-Wimplicit-int-float-conversion]

> ...
> qemu/util/cutils.c:245:23: error: implicit conversion from 'unsigned long' to 
> 'double' changes value from 18446744073709550592 to 18446744073709551616 
> [-Werror,-Wimplicit-int-float-conversion]

>
> Signed-off-by: Fangrui Song 
> ---
>   migration/migration.c | 4 ++--
>   util/cutils.c | 4 ++--
>   2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/migration/migration.c b/migration/migration.c
> index 354ad072fa..ac3ea2934a 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -53,6 +53,7 @@
>   #include "monitor/monitor.h"
>   #include "net/announce.h"
>   #include "qemu/queue.h"
> +#include 
>   
>   #define MAX_THROTTLE  (32 << 20)  /* Migration transfer speed 
> throttling */
>   
> @@ -2035,11 +2036,10 @@ void qmp_migrate_set_downtime(double value, Error 
> **errp)

if (value < 0 || value > MAX_MIGRATE_DOWNTIME_SECONDS) {
error_setg(errp, "Parameter 'downtime_limit' expects an integer in "
 "the range of 0 to %d seconds",
 MAX_MIGRATE_DOWNTIME_SECONDS);
return;
>   }

@value is now in [0,2000].

>   
>   value *= 1000; /* Convert to milliseconds */


@value is in [0,200]

> -value = MAX(0, MIN(INT64_MAX, value));

This does nothing.

>   
>   MigrateSetParameters p = {

>   .has_downtime_limit = true,
> -.downtime_limit = value,
> +.downtime_limit = (int64_t)fmin(value, nextafter(0x1p63, 0)),

This does nothing and is hard to read :)

Can we simply drop the offending line statement instead?


Fixed in the new patch.


>   };
>   
>   qmp_migrate_set_parameters(, errp);

> diff --git a/util/cutils.c b/util/cutils.c
> index fd591cadf0..2b4484c015 100644
> --- a/util/cutils.c
> +++ b/util/cutils.c
> @@ -239,10 +239,10 @@ static int do_strtosz(const char *nptr, const char 
> **end,

>   goto out;
>   }
>   /*
> - * Values >= 0xfc00 overflow uint64_t after their trip
> + * Values > nextafter(0x1p64, 0) overflow uint64_t after their trip
>* through double (53 bits of precision).
>*/
> -if ((val * mul >= 0xfc00) || val < 0) {
> +if ((val * mul > nextafter(0x1p64, 0)) || val < 0) {
>   retval = -ERANGE;
>   goto out;
>   }
*result = val * mul;

I figure this one is correct and hard to read.

0xfc00 is not representable exactly as double.  It's
half-way between the representable values 0xf800 and
0x1.  Which one we get is implementation-defined.  Bad.

nextafter(0x1p64, 0) is a clever way to write 0xf800, the
largest uint64_t exactly representable as double.

With your patch, val * mul in [0,0xf800] will be accepted.

The first val * mul above this range is 0x1p64.  Rejecting it is
correct, because it overflows yint64_t.


I am not subscribed, so apologize that this email may be off the thread.

(The binutils mailing list allows a user to download the raw email so I
can still reply to a specific email, but this list does not provide such
feature.)
>From 5f1c5a42794ddcbabb63d9af920d9f437ea90a9f Mon Sep 17 00:00:00 2001
From: Fangrui Song 
Date: Fri, 15 Nov 2019 16:27:47 -0800
Subject: [PATCH] Fix incorrect integer->float conversions caught by clang
 -Wimplicit-int-float-conversion
To: qemu-devel@nongnu.org

The warning will be enabled by default in clang 10. It is not available for clang <= 9.

qemu/migration/migration.c:2038:24: error: implicit conversion from 'long' to 'double' changes value from 9223372036854775807 to 9223372036854775808 [-Werror,-Wimplicit-int-float-conversion]
...
qemu/util/cutils.c:245:23: error: implicit conversion from 'unsigned long' to 'double' changes value from 18446744073709550592 to 18446744073709551616 [-Werror,-Wimplicit-int-float-conversion]

Signed-off-by: Fangrui Song 
---
 migration/migration.c | 3 +--
 util/cutils.c | 4 ++--
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/migration/migration.c b/migration/migration.c
index 354ad072fa..09b150663f 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -2035,11 +2035,10 @@ void qmp_migrate_set_downtime(double value, Error **errp)
 }
 
 value *= 1000; /* Convert to milliseconds */
-value = MAX(0, MIN(INT64_MAX, value));
 
 MigrateSetParameters p = {
 .has_downtime_limit = true,
-.downtime_limit = value,
+.downtime_limit = (int64_t)value,
 };
 
 qmp_migrate_set_parameters(, errp);
diff --git a/util/cutils.c b/util/cutils.c
index fd591cadf0..2b4484c015 100644
--- 

[PULL for-4.2-rc2 2/2] hw/mips/gt64xxx: Remove dynamic field width from trace events

[Stefan Hajnoczi]

From: Philippe Mathieu-Daudé 

Since not all trace backends support dynamic field width in
format (dtrace via stap does not), replace by a static field
width instead.

We previously passed to the trace API 'width << 1' as the number
of hex characters to display (the dynamic field width). We don't
need this anymore. Instead, display the size of bytes accessed.

Fixes: ab6bff424f (gt64xxx_pci: Convert debug printf to trace events)
Reported-by: Eric Blake 
Reviewed-by: Eric Blake 
Signed-off-by: Philippe Mathieu-Daudé 
Message-id: 20191118222746.31467-3-phi...@redhat.com
Buglink: https://bugs.launchpad.net/qemu/+bug/1844817
Signed-off-by: Philippe Mathieu-Daudé 
Message-Id: <20191118222746.31467-3-phi...@redhat.com>
Signed-off-by: Stefan Hajnoczi 
---
 hw/mips/gt64xxx_pci.c | 16 
 hw/mips/trace-events  |  4 ++--
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/hw/mips/gt64xxx_pci.c b/hw/mips/gt64xxx_pci.c
index 5cab9c1ee1..f1af840d8e 100644
--- a/hw/mips/gt64xxx_pci.c
+++ b/hw/mips/gt64xxx_pci.c
@@ -642,19 +642,19 @@ static void gt64120_writel(void *opaque, hwaddr addr,
 /* not really implemented */
 s->regs[saddr] = ~(~(s->regs[saddr]) | ~(val & 0xfffe));
 s->regs[saddr] |= !!(s->regs[saddr] & 0xfffe);
-trace_gt64120_write("INTRCAUSE", size << 1, val);
+trace_gt64120_write("INTRCAUSE", size, val);
 break;
 case GT_INTRMASK:
 s->regs[saddr] = val & 0x3c3e;
-trace_gt64120_write("INTRMASK", size << 1, val);
+trace_gt64120_write("INTRMASK", size, val);
 break;
 case GT_PCI0_ICMASK:
 s->regs[saddr] = val & 0x03fe;
-trace_gt64120_write("ICMASK", size << 1, val);
+trace_gt64120_write("ICMASK", size, val);
 break;
 case GT_PCI0_SERR0MASK:
 s->regs[saddr] = val & 0x003f;
-trace_gt64120_write("SERR0MASK", size << 1, val);
+trace_gt64120_write("SERR0MASK", size, val);
 break;
 
 /* Reserved when only PCI_0 is configured. */
@@ -930,19 +930,19 @@ static uint64_t gt64120_readl(void *opaque,
 /* Interrupts */
 case GT_INTRCAUSE:
 val = s->regs[saddr];
-trace_gt64120_read("INTRCAUSE", size << 1, val);
+trace_gt64120_read("INTRCAUSE", size, val);
 break;
 case GT_INTRMASK:
 val = s->regs[saddr];
-trace_gt64120_read("INTRMASK", size << 1, val);
+trace_gt64120_read("INTRMASK", size, val);
 break;
 case GT_PCI0_ICMASK:
 val = s->regs[saddr];
-trace_gt64120_read("ICMASK", size << 1, val);
+trace_gt64120_read("ICMASK", size, val);
 break;
 case GT_PCI0_SERR0MASK:
 val = s->regs[saddr];
-trace_gt64120_read("SERR0MASK", size << 1, val);
+trace_gt64120_read("SERR0MASK", size, val);
 break;
 
 /* Reserved when only PCI_0 is configured. */
diff --git a/hw/mips/trace-events b/hw/mips/trace-events
index 75d4c73f2e..321933283f 100644
--- a/hw/mips/trace-events
+++ b/hw/mips/trace-events
@@ -1,4 +1,4 @@
 # gt64xxx.c
-gt64120_read(const char *regname, int width, uint64_t value) "gt64120 read %s 
value:0x%0*" PRIx64
-gt64120_write(const char *regname, int width, uint64_t value) "gt64120 write 
%s value:0x%0*" PRIx64
+gt64120_read(const char *regname, unsigned size, uint64_t value) "gt64120 read 
%s size:%u value:0x%08" PRIx64
+gt64120_write(const char *regname, unsigned size, uint64_t value) "gt64120 
write %s size:%u value:0x%08" PRIx64
 gt64120_isd_remap(uint64_t from_length, uint64_t from_addr, uint64_t 
to_length, uint64_t to_addr) "ISD: 0x%08" PRIx64 "@0x%08" PRIx64 " -> 0x%08" 
PRIx64 "@0x%08" PRIx64
-- 
2.23.0

[PULL for-4.2-rc2 0/2] Tracing patches

[Stefan Hajnoczi]

The following changes since commit f086f22d6c068ba151b0f6e81e75a64f130df712:

  Merge remote-tracking branch 'remotes/awilliam/tags/vfio-fixes-20191118.0' 
into staging (2019-11-18 21:35:48 +)

are available in the Git repository at:

  https://github.com/stefanha/qemu.git tags/tracing-pull-request

for you to fetch changes up to 6b904f1a528a6d8c21f7fbdeab13b9603d1b6df7:

  hw/mips/gt64xxx: Remove dynamic field width from trace events (2019-11-19 
16:17:05 +)


Pull request

Tracing fixes for MIPS.



Philippe Mathieu-Daudé (2):
  hw/block/pflash: Remove dynamic field width from trace events
  hw/mips/gt64xxx: Remove dynamic field width from trace events

 hw/block/pflash_cfi01.c |  8 
 hw/block/pflash_cfi02.c |  8 
 hw/block/trace-events   |  8 
 hw/mips/gt64xxx_pci.c   | 16 
 hw/mips/trace-events|  4 ++--
 5 files changed, 22 insertions(+), 22 deletions(-)

-- 
2.23.0

[PULL for-4.2-rc2 1/2] hw/block/pflash: Remove dynamic field width from trace events

[Stefan Hajnoczi]

From: Philippe Mathieu-Daudé 

Since not all trace backends support dynamic field width in
format (dtrace via stap does not), replace by a static field
width instead.

We previously passed to the trace API 'width << 1' as the number
of hex characters to display (the dynamic field width). We don't
need this anymore. Instead, display the size of bytes accessed.

Fixes: e8aa2d95ea (pflash: Simplify trace_pflash_io_read/write)
Fixes: c1474acd5d (pflash: Simplify trace_pflash_data_read/write)
Reported-by: Eric Blake 
Reviewed-by: Eric Blake 
Signed-off-by: Philippe Mathieu-Daudé 
Message-id: 20191118222746.31467-2-phi...@redhat.com
Buglink: https://bugs.launchpad.net/qemu/+bug/1844817
Signed-off-by: Philippe Mathieu-Daudé 
Message-Id: <20191118222746.31467-2-phi...@redhat.com>
Signed-off-by: Stefan Hajnoczi 
---
 hw/block/pflash_cfi01.c | 8 
 hw/block/pflash_cfi02.c | 8 
 hw/block/trace-events   | 8 
 3 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/hw/block/pflash_cfi01.c b/hw/block/pflash_cfi01.c
index 566c0acb77..54e6ebd385 100644
--- a/hw/block/pflash_cfi01.c
+++ b/hw/block/pflash_cfi01.c
@@ -276,7 +276,7 @@ static uint32_t pflash_data_read(PFlashCFI01 *pfl, hwaddr 
offset,
 DPRINTF("BUG in %s\n", __func__);
 abort();
 }
-trace_pflash_data_read(offset, width << 1, ret);
+trace_pflash_data_read(offset, width, ret);
 return ret;
 }
 
@@ -389,7 +389,7 @@ static uint32_t pflash_read(PFlashCFI01 *pfl, hwaddr offset,
 
 break;
 }
-trace_pflash_io_read(offset, width, width << 1, ret, pfl->cmd, 
pfl->wcycle);
+trace_pflash_io_read(offset, width, ret, pfl->cmd, pfl->wcycle);
 
 return ret;
 }
@@ -414,7 +414,7 @@ static inline void pflash_data_write(PFlashCFI01 *pfl, 
hwaddr offset,
 {
 uint8_t *p = pfl->storage;
 
-trace_pflash_data_write(offset, width << 1, value, pfl->counter);
+trace_pflash_data_write(offset, width, value, pfl->counter);
 switch (width) {
 case 1:
 p[offset] = value;
@@ -453,7 +453,7 @@ static void pflash_write(PFlashCFI01 *pfl, hwaddr offset,
 
 cmd = value;
 
-trace_pflash_io_write(offset, width, width << 1, value, pfl->wcycle);
+trace_pflash_io_write(offset, width, value, pfl->wcycle);
 if (!pfl->wcycle) {
 /* Set the device in I/O access mode */
 memory_region_rom_device_set_romd(>mem, false);
diff --git a/hw/block/pflash_cfi02.c b/hw/block/pflash_cfi02.c
index 4baca701b7..c7d92c3e79 100644
--- a/hw/block/pflash_cfi02.c
+++ b/hw/block/pflash_cfi02.c
@@ -260,7 +260,7 @@ static uint64_t pflash_data_read(PFlashCFI02 *pfl, hwaddr 
offset,
 {
 uint8_t *p = (uint8_t *)pfl->storage + offset;
 uint64_t ret = pfl->be ? ldn_be_p(p, width) : ldn_le_p(p, width);
-trace_pflash_data_read(offset, width << 1, ret);
+trace_pflash_data_read(offset, width, ret);
 return ret;
 }
 
@@ -385,7 +385,7 @@ static uint64_t pflash_read(void *opaque, hwaddr offset, 
unsigned int width)
 }
 break;
 }
-trace_pflash_io_read(offset, width, width << 1, ret, pfl->cmd, 
pfl->wcycle);
+trace_pflash_io_read(offset, width, ret, pfl->cmd, pfl->wcycle);
 
 return ret;
 }
@@ -432,7 +432,7 @@ static void pflash_write(void *opaque, hwaddr offset, 
uint64_t value,
 uint8_t *p;
 uint8_t cmd;
 
-trace_pflash_io_write(offset, width, width << 1, value, pfl->wcycle);
+trace_pflash_io_write(offset, width, value, pfl->wcycle);
 cmd = value;
 if (pfl->cmd != 0xA0) {
 /* Reset does nothing during chip erase and sector erase. */
@@ -542,7 +542,7 @@ static void pflash_write(void *opaque, hwaddr offset, 
uint64_t value,
 }
 goto reset_flash;
 }
-trace_pflash_data_write(offset, width << 1, value, 0);
+trace_pflash_data_write(offset, width, value, 0);
 if (!pfl->ro) {
 p = (uint8_t *)pfl->storage + offset;
 if (pfl->be) {
diff --git a/hw/block/trace-events b/hw/block/trace-events
index 13d1b21dd4..c03e80c2c9 100644
--- a/hw/block/trace-events
+++ b/hw/block/trace-events
@@ -8,10 +8,10 @@ fdc_ioport_write(uint8_t reg, uint8_t value) "write reg 
0x%02x val 0x%02x"
 # pflash_cfi01.c
 pflash_reset(void) "reset"
 pflash_timer_expired(uint8_t cmd) "command 0x%02x done"
-pflash_io_read(uint64_t offset, int width, int fmt_width, uint32_t value, 
uint8_t cmd, uint8_t wcycle) "offset:0x%04"PRIx64" width:%d value:0x%0*x 
cmd:0x%02x wcycle:%u"
-pflash_io_write(uint64_t offset, int width, int fmt_width, uint32_t value, 
uint8_t wcycle) "offset:0x%04"PRIx64" width:%d value:0x%0*x wcycle:%u"
-pflash_data_read(uint64_t offset, int width, uint32_t value) "data 
offset:0x%04"PRIx64" value:0x%0*x"
-pflash_data_write(uint64_t offset, int width, uint32_t value, uint64_t 
counter) "data offset:0x%04"PRIx64" value:0x%0*x counter:0x%016"PRIx64
+pflash_io_read(uint64_t offset, unsigned size, uint32_t value, uint8_t cmd, 
uint8_t 

Re: [PATCH] linux-user/strace: Add missing signal strings

[Richard Henderson]

On 11/19/19 9:06 PM, Helge Deller wrote:
>>> +#ifdef SIGSTKFLT
>>> +    case TARGET_SIGSTKFLT: signal_name = "SIGSTKFLT"; break;
>>> +#endif
>>
>> Wrong ifdef.
> 
> Same here, see in linux-user/signal.c (line 50):
> #ifdef SIGSTKFLT
>     [SIGSTKFLT] = TARGET_SIGSTKFLT,
> #endif

But that one actually references SIGSTKFLT, but the case above does not.
You probably don't need the ifdef at all.


r~

Re: [PATCH v35 05/13] target/avr: Add instruction translation - Arithmetic and Logic Instructions

[Michael Rolnik]

Hi Aleksandar et al.

how is it going? should I rebase or not?

Michael

On Tue, Nov 5, 2019 at 4:38 PM Aleksandar Markovic
 wrote:
>
> On Tue, Nov 5, 2019 at 2:23 PM Richard Henderson
>  wrote:
> >
> > On 11/5/19 10:46 AM, Aleksandar Markovic wrote:
> > >
> > >
> > > On Tuesday, November 5, 2019, Aleksandar Markovic 
> > >  > > > wrote:
> > >
> > >
> > > +
> > > +/*
> > > + *  This instruction performs 8-bit x 8-bit -> 16-bit signed
> > > multiplication
> > > + *  and shifts the result one bit left.
> > > + */
> > > +static bool trans_FMULSU(DisasContext *ctx, arg_FMULSU *a)
> > > +{
> > > +if (!avr_have_feature(ctx, AVR_FEATURE_MUL)) {
> > > +return true;
> > > +}
> > > +
> > > +TCGv R0 = cpu_r[0];
> > > +TCGv R1 = cpu_r[1];
> > > +TCGv Rd = cpu_r[a->rd];
> > > +TCGv Rr = cpu_r[a->rr];
> > > +TCGv R = tcg_temp_new_i32();
> > > +TCGv t0 = tcg_temp_new_i32();
> > > +
> > > +tcg_gen_ext8s_tl(t0, Rd); /* make Rd full 32 bit signed */
> > > +tcg_gen_mul_tl(R, t0, Rr); /* R = Rd * Rr */
> > > +tcg_gen_andi_tl(R, R, 0x); /* make it 16 bits */
> > > +
> > > +tcg_gen_shri_tl(cpu_Cf, R, 15); /* Cf = R(15) */
> > > +tcg_gen_setcondi_tl(TCG_COND_EQ, cpu_Zf, R, 0); /* Zf = R == 
> > > 0 */
> > > +
> > > +tcg_gen_shli_tl(R, R, 1);
> > > +
> > > +tcg_gen_andi_tl(R0, R, 0xff);
> > > +tcg_gen_shri_tl(R1, R, 8);
> > > +tcg_gen_andi_tl(R1, R1, 0xff);
> > > +
> > > +tcg_temp_free_i32(t0);
> > > +tcg_temp_free_i32(R);
> > > +
> > > +return true;
> > > +}
> > > +
> > >
> > >
> > > Hi, Michael.
> > >
> > > The way I understand the spec is that a->rd and a->rd must be between 
> > > 16
> > > and 23:
> > >
> > > 
> > > https://www.microchip.com/webdoc/avrassembler/avrassembler.wb_FMULSU.html
> > > 
> > > 
> > >
> > > Is my interpretation right? If yes, where is the corresponding part 
> > > in the
> > > implementation?
> > >
> > >
> > > Or, perhaps,
> > >
> > > TCGv Rd = cpu_r[a->rd];
> > >
> > > should be
> > >
> > > TCGv Rd = cpu_r[a->rd + 16];
> > >
> > > (and the same for rs)
> >
> > This happens during decode:
> >
> > +%rd_b   4:3 !function=to_B
> > +%rr_b   0:3 !function=to_B
> > +@fmul     . ... . ...   _rr  rd=%rd_b rr=%rr_b
> > +FMUL 0011 0 ... 1 ...   @fmul
> > +FMULS    0011 1 ... 0 ...   @fmul
> > +FMULSU   0011 1 ... 1 ...   @fmul
> >
> > This means that a->rd = to_B(extract32(insn, 4, 3)), and
> >
> > > +static int to_B(DisasContext *ctx, int indx) { return 16 + (indx % 8); }
> >
> > et voila.
> >
>
> OK. Thanks for clarification.
>
> >
> > r~



-- 
Best Regards,
Michael Rolnik

Re: [PATCH] linux-user/strace: Add missing signal strings

[Helge Deller]

On 19.11.19 21:06, Helge Deller wrote:

On 19.11.19 20:56, Richard Henderson wrote:

On 11/19/19 7:51 PM, Helge Deller wrote:

Add the textual representations of some missing target signals.

Signed-off-by: Helge Deller 

diff --git a/linux-user/strace.c b/linux-user/strace.c
index 3d4d684450..18b57a9ef9 100644
--- a/linux-user/strace.c
+++ b/linux-user/strace.c
@@ -146,6 +146,22 @@ print_signal(abi_ulong arg, int last)
  case TARGET_SIGSTOP: signal_name = "SIGSTOP"; break;
  case TARGET_SIGTTIN: signal_name = "SIGTTIN"; break;
  case TARGET_SIGTTOU: signal_name = "SIGTTOU"; break;
+    case TARGET_SIGIO: signal_name = "SIGIO"; break;
+    case TARGET_SIGTRAP: signal_name = "SIGTRAP"; break;
+    /* case TARGET_SIGIOT: signal_name = "SIGIOT"; break; */


Unused commented code.


True, but I kept it intentionally the same as it's currently in
linux-user/signal.c (line 40) so it's not forgotten if that changes:
/*    [SIGIOT] = TARGET_SIGIOT,*/


+#ifdef SIGSTKFLT
+    case TARGET_SIGSTKFLT: signal_name = "SIGSTKFLT"; break;
+#endif


Wrong ifdef.


Same here, see in linux-user/signal.c (line 50):
#ifdef SIGSTKFLT
     [SIGSTKFLT] = TARGET_SIGSTKFLT,
#endif


OIC!
My code should to be:
#ifdef TARGET_SIGSTKFLT

Will resubmit after getting suggestions for the unused commented code.

Helge

Re: [PATCH] linux-user/strace: Add missing signal strings

[Helge Deller]

On 19.11.19 20:56, Richard Henderson wrote:

On 11/19/19 7:51 PM, Helge Deller wrote:

Add the textual representations of some missing target signals.

Signed-off-by: Helge Deller 

diff --git a/linux-user/strace.c b/linux-user/strace.c
index 3d4d684450..18b57a9ef9 100644
--- a/linux-user/strace.c
+++ b/linux-user/strace.c
@@ -146,6 +146,22 @@ print_signal(abi_ulong arg, int last)
  case TARGET_SIGSTOP: signal_name = "SIGSTOP"; break;
  case TARGET_SIGTTIN: signal_name = "SIGTTIN"; break;
  case TARGET_SIGTTOU: signal_name = "SIGTTOU"; break;
+case TARGET_SIGIO: signal_name = "SIGIO"; break;
+case TARGET_SIGTRAP: signal_name = "SIGTRAP"; break;
+/* case TARGET_SIGIOT: signal_name = "SIGIOT"; break; */


Unused commented code.


True, but I kept it intentionally the same as it's currently in
linux-user/signal.c (line 40) so it's not forgotten if that changes:
/*[SIGIOT] = TARGET_SIGIOT,*/


+#ifdef SIGSTKFLT
+case TARGET_SIGSTKFLT: signal_name = "SIGSTKFLT"; break;
+#endif


Wrong ifdef.


Same here, see in linux-user/signal.c (line 50):
#ifdef SIGSTKFLT
[SIGSTKFLT] = TARGET_SIGSTKFLT,
#endif

Suggestions?

Helge

Re: [PATCH v2 08/20] nvme: add support for the get log page command

[Klaus Birkelund]

On Tue, Nov 12, 2019 at 03:04:52PM +, Beata Michalska wrote:
> Hi Klaus,
> 
> 
> On Tue, 15 Oct 2019 at 11:45, Klaus Jensen  wrote:
> > +if (!nsid || (nsid != 0x && nsid > n->num_namespaces)) {
> > +trace_nvme_err_invalid_ns(nsid, n->num_namespaces);
> > +return NVME_INVALID_NSID | NVME_DNR;
> > +}
> > +
> The LAP '0' bit is cleared now - which means there is no support
> for per-namespace data. So in theory, if that was the aim, this condition
> should check for the values different than 0x0 and 0x and either
> abort the command or treat that as request for controller specific data.
> 

This is fixed in v3 (that is, it just checks for values different from
0x0 and 0x).

> > +switch (lid) {
> > +case NVME_LOG_ERROR_INFO:
> > +return nvme_error_info(n, cmd, len, off, req);
> > +case NVME_LOG_SMART_INFO:
> > +return nvme_smart_info(n, cmd, len, off, req);
> > +case NVME_LOG_FW_SLOT_INFO:
> > +return nvme_fw_log_info(n, cmd, len, off, req);
> > +default:
> > +trace_nvme_err_invalid_log_page(req->cid, lid);
> > +return NVME_INVALID_LOG_ID | NVME_DNR;
> 
> The spec mentions the Invalid Field in Command  case processing
> command with an unsupported log id.
> 

Thanks. Fixed!

> > +}
> > +}
> > +
> >  static void nvme_free_cq(NvmeCQueue *cq, NvmeCtrl *n)
> >  {
> >  n->cq[cq->cqid] = NULL;
> > @@ -812,6 +944,9 @@ static uint16_t nvme_get_feature(NvmeCtrl *n, NvmeCmd 
> > *cmd, NvmeRequest *req)
> >  uint32_t result;
> >
> >  switch (dw10) {
> > +case NVME_TEMPERATURE_THRESHOLD:
> > +result = cpu_to_le32(n->features.temp_thresh);
> > +break;
> >  case NVME_VOLATILE_WRITE_CACHE:
> >  result = blk_enable_write_cache(n->conf.blk);
> >  trace_nvme_getfeat_vwcache(result ? "enabled" : "disabled");
> > @@ -856,6 +991,10 @@ static uint16_t nvme_set_feature(NvmeCtrl *n, NvmeCmd 
> > *cmd, NvmeRequest *req)
> >  uint32_t dw11 = le32_to_cpu(cmd->cdw11);
> >
> >  switch (dw10) {
> > +case NVME_TEMPERATURE_THRESHOLD:
> > +n->features.temp_thresh = dw11;
> > +break;
> > +
> >  case NVME_VOLATILE_WRITE_CACHE:
> >  blk_set_enable_write_cache(n->conf.blk, dw11 & 1);
> >  break;
> > @@ -884,6 +1023,8 @@ static uint16_t nvme_admin_cmd(NvmeCtrl *n, NvmeCmd 
> > *cmd, NvmeRequest *req)
> >  return nvme_del_sq(n, cmd);
> >  case NVME_ADM_CMD_CREATE_SQ:
> >  return nvme_create_sq(n, cmd);
> > +case NVME_ADM_CMD_GET_LOG_PAGE:
> > +return nvme_get_log(n, cmd, req);
> >  case NVME_ADM_CMD_DELETE_CQ:
> >  return nvme_del_cq(n, cmd);
> >  case NVME_ADM_CMD_CREATE_CQ:
> > @@ -923,6 +1064,7 @@ static void nvme_process_sq(void *opaque)
> >  QTAILQ_INSERT_TAIL(>out_req_list, req, entry);
> >  memset(>cqe, 0, sizeof(req->cqe));
> >  req->cqe.cid = cmd.cid;
> > +req->cid = le16_to_cpu(cmd.cid);
> 
> If I haven't missed anything this is being used only in one place
> for tracing - is it really worth to duplicate the cid here ?
> 

At this point in the series, yes - it is only used once. But it will be
used extensively for tracing in the later patches.

> > -id->lpa = 1 << 0;
> > +id->lpa = 1 << 2;
> 
> This sets the bit that states support for GLP command but clears the one
> that states support for per-namespace SMART/Heatld data - is that expected ?
> 

Yes, clearing the bit for per-namespace SMART/Health log page
information is intentional. There is no namespace specific information
defined in the namespace so the global and per-namespace log page
contains the same information.

Re: [PATCH] linux-user/strace: Add missing signal strings

[Richard Henderson]

On 11/19/19 7:51 PM, Helge Deller wrote:
> Add the textual representations of some missing target signals.
> 
> Signed-off-by: Helge Deller 
> 
> diff --git a/linux-user/strace.c b/linux-user/strace.c
> index 3d4d684450..18b57a9ef9 100644
> --- a/linux-user/strace.c
> +++ b/linux-user/strace.c
> @@ -146,6 +146,22 @@ print_signal(abi_ulong arg, int last)
>  case TARGET_SIGSTOP: signal_name = "SIGSTOP"; break;
>  case TARGET_SIGTTIN: signal_name = "SIGTTIN"; break;
>  case TARGET_SIGTTOU: signal_name = "SIGTTOU"; break;
> +case TARGET_SIGIO: signal_name = "SIGIO"; break;
> +case TARGET_SIGTRAP: signal_name = "SIGTRAP"; break;
> +/* case TARGET_SIGIOT: signal_name = "SIGIOT"; break; */

Unused commented code.

> +#ifdef SIGSTKFLT
> +case TARGET_SIGSTKFLT: signal_name = "SIGSTKFLT"; break;
> +#endif

Wrong ifdef.


r~

Re: [PATCH v2 09/20] nvme: add support for the asynchronous event request command

[Klaus Birkelund]

On Tue, Nov 12, 2019 at 03:04:59PM +, Beata Michalska wrote:
> Hi Klaus,
> 
> On Tue, 15 Oct 2019 at 11:49, Klaus Jensen  wrote:
> > @@ -1188,6 +1326,9 @@ static int nvme_start_ctrl(NvmeCtrl *n)
> >
> >  nvme_set_timestamp(n, 0ULL);
> >
> > +n->aer_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, nvme_process_aers, n);
> > +QTAILQ_INIT(>aer_queue);
> > +
> 
> Is the timer really needed here ? The CEQ can be posted either when requested
> by host through AER, if there are any pending events, or once the
> event is triggered
> and there are active AER's.
> 

I guess you are right. I mostly cribbed this from Keith's tree, but I
see no reason to keep the timer.

Keith, do you have any comments on this?

> > @@ -1380,6 +1521,13 @@ static void nvme_process_db(NvmeCtrl *n, hwaddr 
> > addr, int val)
> > "completion queue doorbell write"
> > " for nonexistent queue,"
> > " sqid=%"PRIu32", ignoring", qid);
> > +
> > +if (n->outstanding_aers) {
> > +nvme_enqueue_event(n, NVME_AER_TYPE_ERROR,
> > +NVME_AER_INFO_ERR_INVALID_DB_REGISTER,
> > +NVME_LOG_ERROR_INFO);
> > +}
> > +
> This one (as well as cases below) might not be entirely right
> according to the spec. If given event is enabled for asynchronous
> reporting the controller should retain that even. In this case, the event
> will be ignored as there is no pending request.
> 

I understand these notifications to be special cases (i.e. they cannot
be enabled/disabled through the Asynchronous Event Configuration
feature). See Section 4.1 of NVM Express 1.2.1. The spec specifically
says that "... and an Asynchronous Event Request command is outstanding,
...).

> > @@ -1591,6 +1759,7 @@ static void nvme_init_ctrl(NvmeCtrl *n)
> >  id->ver = cpu_to_le32(0x00010201);
> >  id->oacs = cpu_to_le16(0);
> >  id->acl = 3;
> > +id->aerl = n->params.aerl;
> 
> What about the configuration for the asynchronous events ?
> 

It will default to an AEC vector of 0 (everything disabled).


K

Re: [PATCH] audio: fix audio recording

[Richard Henderson]

On 11/19/19 9:01 AM, Philippe Mathieu-Daudé wrote:
> Cc'ing Zoltán.
> 
> On 11/19/19 7:58 AM, Volker Rümelin wrote:
>> With current code audio recording with all audio backends
>> except PulseAudio and DirectSound is broken. The generic audio
>> recording buffer management forgot to update the current read
>> position after a read.
>>
>> Fixes: ff095e5231 "audio: api for mixeng code free backends"
>>
>> Signed-off-by: Volker Rümelin 
>> ---
>>   audio/audio.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/audio/audio.c b/audio/audio.c
>> index 7fc3aa9d16..56fae55047 100644
>> --- a/audio/audio.c
>> +++ b/audio/audio.c
>> @@ -1390,6 +1390,7 @@ void *audio_generic_get_buffer_in(HWVoiceIn *hw, size_t
>> *size)
>>   size_t read = hw->pcm_ops->read(hw, hw->buf_emul + hw->pos_emul,
>>   read_len);
>>   hw->pending_emul += read;
>> +    hw->pos_emul = (hw->pos_emul + read) % hw->size_emul;
> 
> Anyway since read() can return a negative value, both previous assignments
> should go after this if/break check...

This isn't read(2).

size_t (*read)(HWVoiceIn *hw, void *buf, size_t size);

Since this isn't ssize_t, no negative return value possible.


r~

Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants

[Eduardo Habkost]

On Tue, Nov 19, 2019 at 12:00:14PM +0100, David Hildenbrand wrote:
> On 19.11.19 11:36, Peter Maydell wrote:
> > On Tue, 19 Nov 2019 at 09:59, David Hildenbrand  wrote:
> > > 
> > > On 19.11.19 10:22, Peter Maydell wrote:
> > > > I don't hugely care about query-cpu-model-expansion. I
> > > > just don't want it to have bad effects on the semantics
> > > > of user-facing stuff like x- properties.
> > > 
> > > IMHO, max should really include all features (yes, also the bad
> > > x-features on arm :) ) and we should have a way to give users the
> > > opportunity to specify "just give me the best model independent of the
> > > accelerator" - something like a "best" model, but I don't care about the
> > > name.

I'm in agreement with Peter, here: if "max" is user-visible, it's
better to make it provide more usable defaults.


> > 
> > How would "max includes all features" work if we have two
> > x- features (or even two normal features!) which are incompatible
> > with each other? How does it work for features which are
> 
> I assume the "max" model should at least be consistent, see below.
> 
> > valid for some other CPU type but not for 'max'? The design
> > seems to assume a rather simplified system where every
> > feature is independent and can always be applied to every
> > CPU, which I don't think is guaranteed to be the case.
> 
> I do agree that the use case of "max" for detecting which features can be
> enabled for any CPU model is quite simplified and would also not work like
> this on s390x. It really means "give me the maximum/latest/greatest you
> can". Some examples on s390x:
> 
> On s390x, we don't allow to enable new features for older CPU generation.
> "vx" was introduced with a z13. If "max" is a z13, it can include "vx", if
> available. However, if you select a z12 (zEC12), you cannot enable "vx":
> 
> "Feature '%s' is not available for CPU model '%s', it was introduced with
> later models."
> 
> Also, we have dependency checks
> (target/s390x/cpu_models.c:check_consistency()), that at least warn on
> inconsistencies between features (feature X requires feature Y).
> 
> We would need more fine-grained "max" models. E.g., z13-max vs. z13-best vs.
> z13-base.
> 
> - z13-max: Maximum features that can be enabled on the current
>accel/host for a z13.
> - z13-best: Best features that can be enabled on the current
>accel/host for a z13.
> - z13-base: base feature set, independent of current
>accel/host for a z13. (we do have this already on s390x)

We don't need to create new CPU types for that, do we?  These
different modes could be configured by a CPU option (e.g.
"z13,features=max"[1], "z13,features=best").

If we do add new CPU options to tune feature defaults, libvirt
can start using these options on query-cpu-model-expansion, and
everybody will be happy.  No need to change defaults in the "max"
CPU model in a way that makes it less usable just to make
query-cpu-model-expansion work.

[1] Probably we need to call it something else instead of
"features=max", just to avoid confusion with the "max" CPU
model.  Maybe "experimental-features=on",
"recommended-features=on"?

-- 
Eduardo

Re: [PATCH] Add minimal Hexagon target - First in a series of patches - linux-user changes + linux-user/hexagon + skeleton of target/hexagon - Files in target/hexagon/imported are from another project

[Richard Henderson]

On 11/19/19 6:22 PM, Taylor Simpson wrote:
> - Laurent suggested I split the patch into two parts: linux-user and 
> target/hexagon.  If I do that, which one should contain the changes to common 
> files (e.g., configure)?  Also, note that we won't be able to build until 
> both patches are merged.  Is that OK?

The configure parts should be a third, last, patch.

The series is bisectable, because before the configure patch,
none of the hexagon code is compiled at all.


r~

Re: [PATCH] Add minimal Hexagon target - First in a series of patches - linux-user changes + linux-user/hexagon + skeleton of target/hexagon - Files in target/hexagon/imported are from another project

[Richard Henderson]

On 11/19/19 12:58 AM, Taylor Simpson wrote:
> +static abi_ulong get_sigframe(struct target_sigaction *ka,
> +  CPUHexagonState *regs, size_t framesize)
> +{
> +abi_ulong sp = get_sp_from_cpustate(regs);
> +
> +/* This is the X/Open sanctioned signal stack switching.  */
> +sp = target_sigsp(sp, ka) - framesize;
> +
> +sp &= ~7UL; /* align sp on 8-byte boundary */

QEMU_ALIGN_DOWN.

> diff --git a/linux-user/hexagon/sockbits.h b/linux-user/hexagon/sockbits.h
> new file mode 100644
> index 000..85bd64a
> --- /dev/null
> +++ b/linux-user/hexagon/sockbits.h
> @@ -0,0 +1,3 @@
> +/* Copyright (c) 2019 Qualcomm Innovation Center, Inc. All Rights Reserved. 
> */
> +
> +#include "../generic/sockbits.h"

All new files should have denote their license.

> +static inline const char *cpu_get_model(uint32_t eflags)
> +{
> +/* For now, treat anything newer than v60 as a v67 */
> +/* FIXME - Disable instructions that are newer than the specified arch */
> +if (eflags == 0x04 ||/* v5  */
> +eflags == 0x05 ||/* v55 */
> +eflags == 0x60 ||/* v60 */
> +eflags == 0x61 ||/* v61 */
> +eflags == 0x62 ||/* v62 */
> +eflags == 0x65 ||/* v65 */
> +eflags == 0x66 ||/* v66 */
> +eflags == 0x67) {/* v67 */
> +return "v67";
> +}
> +printf("eflags = 0x%x\n", eflags);

Left over debug.

> diff --git a/target/hexagon/Makefile.objs b/target/hexagon/Makefile.objs
> new file mode 100644
> index 000..dfab6ee
> --- /dev/null
> +++ b/target/hexagon/Makefile.objs
> @@ -0,0 +1,6 @@
> +obj-y += \
> +cpu.o \
> +translate.o \
> +op_helper.o
> +
> +CFLAGS += -I$(SRC_PATH)/target/hexagon/imported

Is this really better than

#include "imported/global_types.h"

etc?

> +++ b/target/hexagon/cpu-param.h
> @@ -0,0 +1,11 @@
> +/* Copyright (c) 2019 Qualcomm Innovation Center, Inc. All Rights Reserved. 
> */
> +
> +
> +#ifndef HEXAGON_CPU_PARAM_H
> +#define HEXAGON_CPU_PARAM_H
> +
> +# define TARGET_PHYS_ADDR_SPACE_BITS 36

Watch your spacing.

Does this really compile without TARGET_VIRT_ADDR_SPACE_BITS?

It's used in linux-user/main.c, but I suppose in a way that
the preprocessor interprets it as 0.

> +const char * const hexagon_prednames[] = {
> +  "p0 ", "p1 ", "p2 ", "p3 "
> +};

Inter-string spacing probably belongs to the format not the name.

> +static inline target_ulong hack_stack_ptrs(CPUHexagonState *env,
> +   target_ulong addr)
> +{
> +target_ulong stack_start = env->stack_start;
> +target_ulong stack_size = 0x1;
> +target_ulong stack_adjust = env->stack_adjust;
> +
> +if (stack_start + 0x1000 >= addr && addr >= (stack_start - stack_size)) {
> +return addr - stack_adjust;
> +}
> +return addr;
> +}

An explanation would be welcome here.

> +static void hexagon_dump(CPUHexagonState *env, FILE *f)
> +{
> +static target_ulong last_pc;
> +int i;
> +
> +/*
> + * When comparing with LLDB, it doesn't step through single-cycle
> + * hardware loops the same way.  So, we just skip them here
> + */
> +if (env->gpr[HEX_REG_PC] == last_pc) {
> +return;
> +}

This seems mis-placed.

> +#ifdef FIXME
> +/*
> + * LLDB bug swaps gp and ugp
> + * FIXME when the LLDB bug is fixed
> + */
> +print_reg(f, env, HEX_REG_GP);
> +print_reg(f, env, HEX_REG_UGP);
> +#else
> +fprintf(f, "  %s = 0x" TARGET_FMT_lx "\n",
> +hexagon_regnames[HEX_REG_GP],
> +hack_stack_ptrs(env, env->gpr[HEX_REG_UGP]));
> +fprintf(f, "  %s = 0x" TARGET_FMT_lx "\n",
> +hexagon_regnames[HEX_REG_UGP],
> +hack_stack_ptrs(env, env->gpr[HEX_REG_GP]));
> +#endif
> +print_reg(f, env, HEX_REG_PC);
> +#ifdef FIXME
> +/*
> + * Not modelled in qemu, print junk to minimize the diff's
> + * with LLDB output
> + */
> +print_reg(f, env, HEX_REG_CAUSE);
> +print_reg(f, env, HEX_REG_BADVA);
> +print_reg(f, env, HEX_REG_CS0);
> +print_reg(f, env, HEX_REG_CS1);
> +#else
> +fprintf(f, "  cause = 0x00db\n");
> +fprintf(f, "  badva = 0x\n");
> +fprintf(f, "  cs0 = 0x\n");
> +fprintf(f, "  cs1 = 0x\n");
> +#endif

Need we retain the fixme?

> +void hexagon_debug(CPUHexagonState *env)
> +{
> +hexagon_dump(env, stdout);
> +}

Is this to be called from the debugger?  From what location did you find it
useful?  There are only certain locations in tcg that are self-consistent...

> +DEFINE_CPU(TYPE_HEXAGON_CPU_V67,  hexagon_v67_cpu_init),

Spacing?

> +#ifndef HEXAGON_CPU_H
> +#define HEXAGON_CPU_H
> +
> +/* FIXME - Change this to a command-line option */
> +#ifdef FIXME
> +#define DEBUG_HEX
> +#endif
> +#ifdef FIXME
> +#define COUNT_HEX_HELPERS
> +#endif

Eh?

> +
> +/* Forward declaration needed by some of the header files */
> +typedef struct CPUHexagonState 

Re: [PATCH] Hexagon: Swap SIGRGMAX-1 and SIGRTMIN+1

[Peter Maydell]

On Tue, 19 Nov 2019 at 19:07, Taylor Simpson  wrote:
>
> Signed-off-by: Taylor Simpson 
> ---
>  linux-user/signal.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/linux-user/signal.c b/linux-user/signal.c
> index 5ca6d62..ce3d27f 100644
> --- a/linux-user/signal.c
> +++ b/linux-user/signal.c
> @@ -72,6 +72,14 @@ static uint8_t host_to_target_signal_table[_NSIG] = {
> over a single host signal.  */
>  [__SIGRTMIN] = __SIGRTMAX,
>  [__SIGRTMAX] = __SIGRTMIN,
> +#ifdef TARGET_HEXAGON
> +/*
> + * Hexagon uses the same signal for pthread cancel as the host pthreads,
> + * so cannot be overridden.
> + * Therefore, we map Hexagon signal to a different host signal.
> + */
> +[__SIGRTMAX - 1] = __SIGRTMIN + 1,
> +#endif
>  };

This breaks other stuff, unfortunately, like Go binaries.
(Also, you now have two host signals mapped to the same
target signal; notice that the existing RTMAX/RTMIN
is a swap of the two slots.)

We need a generic solution for this, Hexagon is not the
only one with the problem. There's a patchset on list
from ages back that had a suggested approach, but
it needed review and work.

thanks
-- PMM

[PATCH] Hexagon: Swap SIGRGMAX-1 and SIGRTMIN+1

[Taylor Simpson]

Signed-off-by: Taylor Simpson 
---
 linux-user/signal.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/linux-user/signal.c b/linux-user/signal.c
index 5ca6d62..ce3d27f 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -72,6 +72,14 @@ static uint8_t host_to_target_signal_table[_NSIG] = {
over a single host signal.  */
 [__SIGRTMIN] = __SIGRTMAX,
 [__SIGRTMAX] = __SIGRTMIN,
+#ifdef TARGET_HEXAGON
+/*
+ * Hexagon uses the same signal for pthread cancel as the host pthreads,
+ * so cannot be overridden.
+ * Therefore, we map Hexagon signal to a different host signal.
+ */
+[__SIGRTMAX - 1] = __SIGRTMIN + 1,
+#endif
 };
 static uint8_t target_to_host_signal_table[_NSIG];
 
-- 
2.7.4

[PATCH] linux-user/strace: Improve output of various syscalls

[Helge Deller]

Improve strace output of various syscalls which either have none
or only int-type parameters.

Signed-off-by: Helge Deller 

diff --git a/linux-user/strace.list b/linux-user/strace.list
index 1de4319dcf..5163717087 100644
--- a/linux-user/strace.list
+++ b/linux-user/strace.list
@@ -26,7 +26,7 @@
 { TARGET_NR_afs_syscall, "afs_syscall" , NULL, NULL, NULL },
 #endif
 #ifdef TARGET_NR_alarm
-{ TARGET_NR_alarm, "alarm" , NULL, NULL, NULL },
+{ TARGET_NR_alarm, "alarm" , "%s(%d)", NULL, NULL },
 #endif
 #ifdef TARGET_NR_aplib
 { TARGET_NR_aplib, "aplib" , NULL, NULL, NULL },
@@ -116,13 +116,13 @@
 { TARGET_NR_dipc, "dipc" , NULL, NULL, NULL },
 #endif
 #ifdef TARGET_NR_dup
-{ TARGET_NR_dup, "dup" , NULL, NULL, NULL },
+{ TARGET_NR_dup, "dup" , "%s(%d)", NULL, NULL },
 #endif
 #ifdef TARGET_NR_dup2
-{ TARGET_NR_dup2, "dup2" , NULL, NULL, NULL },
+{ TARGET_NR_dup2, "dup2" , "%s(%d,%d)", NULL, NULL },
 #endif
 #ifdef TARGET_NR_dup3
-{ TARGET_NR_dup3, "dup3" , NULL, NULL, NULL },
+{ TARGET_NR_dup3, "dup3" , "%s(%d,%d,%d)", NULL, NULL },
 #endif
 #ifdef TARGET_NR_epoll_create
 { TARGET_NR_epoll_create, "epoll_create" , NULL, NULL, NULL },
@@ -191,7 +191,7 @@
 { TARGET_NR_fanotify_mark, "fanotify_mark" , NULL, NULL, NULL },
 #endif
 #ifdef TARGET_NR_fchdir
-{ TARGET_NR_fchdir, "fchdir" , NULL, NULL, NULL },
+{ TARGET_NR_fchdir, "fchdir" , "%s(%d)", NULL, NULL },
 #endif
 #ifdef TARGET_NR_fchmod
 { TARGET_NR_fchmod, "fchmod" , "%s(%d,%#o)", NULL, NULL },
@@ -287,7 +287,7 @@
 { TARGET_NR_getdtablesize, "getdtablesize" , NULL, NULL, NULL },
 #endif
 #ifdef TARGET_NR_getegid
-{ TARGET_NR_getegid, "getegid" , NULL, NULL, NULL },
+{ TARGET_NR_getegid, "getegid" , "%s()", NULL, NULL },
 #endif
 #ifdef TARGET_NR_getegid32
 { TARGET_NR_getegid32, "getegid32" , NULL, NULL, NULL },
@@ -299,7 +299,7 @@
 { TARGET_NR_geteuid32, "geteuid32" , NULL, NULL, NULL },
 #endif
 #ifdef TARGET_NR_getgid
-{ TARGET_NR_getgid, "getgid" , NULL, NULL, NULL },
+{ TARGET_NR_getgid, "getgid" , "%s()", NULL, NULL },
 #endif
 #ifdef TARGET_NR_getgid32
 { TARGET_NR_getgid32, "getgid32" , NULL, NULL, NULL },
@@ -329,10 +329,10 @@
 { TARGET_NR_getpeername, "getpeername" , NULL, NULL, NULL },
 #endif
 #ifdef TARGET_NR_getpgid
-{ TARGET_NR_getpgid, "getpgid" , NULL, NULL, NULL },
+{ TARGET_NR_getpgid, "getpgid" , "%s(%u)", NULL, NULL },
 #endif
 #ifdef TARGET_NR_getpgrp
-{ TARGET_NR_getpgrp, "getpgrp" , NULL, NULL, NULL },
+{ TARGET_NR_getpgrp, "getpgrp" , "%s()", NULL, NULL },
 #endif
 #ifdef TARGET_NR_getpid
 { TARGET_NR_getpid, "getpid" , "%s()", NULL, NULL },
@@ -432,7 +432,7 @@
 { TARGET_NR_io_cancel, "io_cancel" , NULL, NULL, NULL },
 #endif
 #ifdef TARGET_NR_ioctl
-{ TARGET_NR_ioctl, "ioctl" , NULL, NULL, NULL },
+{ TARGET_NR_ioctl, "ioctl" , "%s(%d,%#x,%#x,%#x,%#x,%#x)", NULL, NULL },
 #endif
 #ifdef TARGET_NR_io_destroy
 { TARGET_NR_io_destroy, "io_destroy" , NULL, NULL, NULL },
@@ -1257,22 +1257,22 @@
 { TARGET_NR_setdomainname, "setdomainname" , NULL, NULL, NULL },
 #endif
 #ifdef TARGET_NR_setfsgid
-{ TARGET_NR_setfsgid, "setfsgid" , NULL, NULL, NULL },
+{ TARGET_NR_setfsgid, "setfsgid" , "%s(%u)", NULL, NULL },
 #endif
 #ifdef TARGET_NR_setfsgid32
-{ TARGET_NR_setfsgid32, "setfsgid32" , NULL, NULL, NULL },
+{ TARGET_NR_setfsgid32, "setfsgid32" , "%s(%u)" , NULL, NULL },
 #endif
 #ifdef TARGET_NR_setfsuid
-{ TARGET_NR_setfsuid, "setfsuid" , NULL, NULL, NULL },
+{ TARGET_NR_setfsuid, "setfsuid" , "%s(%u)" , NULL, NULL },
 #endif
 #ifdef TARGET_NR_setfsuid32
 { TARGET_NR_setfsuid32, "setfsuid32" , NULL, NULL, NULL },
 #endif
 #ifdef TARGET_NR_setgid
-{ TARGET_NR_setgid, "setgid" , NULL, NULL, NULL },
+{ TARGET_NR_setgid, "setgid" , "%s(%u)", NULL, NULL },
 #endif
 #ifdef TARGET_NR_setgid32
-{ TARGET_NR_setgid32, "setgid32" , NULL, NULL, NULL },
+{ TARGET_NR_setgid32, "setgid32" , "%s(%u)", NULL, NULL },
 #endif
 #ifdef TARGET_NR_setgroups
 { TARGET_NR_setgroups, "setgroups" , NULL, NULL, NULL },
@@ -1296,7 +1296,7 @@
 { TARGET_NR_setns, "setns" , NULL, NULL, NULL },
 #endif
 #ifdef TARGET_NR_setpgid
-{ TARGET_NR_setpgid, "setpgid" , NULL, NULL, NULL },
+{ TARGET_NR_setpgid, "setpgid" , "%s(%u,%u)", NULL, NULL },
 #endif
 #ifdef TARGET_NR_setpgrp
 { TARGET_NR_setpgrp, "setpgrp" , NULL, NULL, NULL },
@@ -1311,22 +1311,22 @@
 { TARGET_NR_setregid32, "setregid32" , NULL, NULL, NULL },
 #endif
 #ifdef TARGET_NR_setresgid
-{ TARGET_NR_setresgid, "setresgid" , NULL, NULL, NULL },
+{ TARGET_NR_setresgid, "setresgid" , "%s(%u,%u,%u)", NULL, NULL },
 #endif
 #ifdef TARGET_NR_setresgid32
 { TARGET_NR_setresgid32, "setresgid32" , NULL, NULL, NULL },
 #endif
 #ifdef TARGET_NR_setresuid
-{ TARGET_NR_setresuid, "setresuid" , NULL, NULL, NULL },
+{ TARGET_NR_setresuid, "setresuid" , "%s(%u,%u,%u)", NULL, NULL },
 #endif
 #ifdef TARGET_NR_setresuid32
-{ TARGET_NR_setresuid32, "setresuid32" , NULL, NULL, NULL },
+{ TARGET_NR_setresuid32, "setresuid32" , "%s(%u,%u,%u)", NULL, NULL },
 #endif
 #ifdef TARGET_NR_setreuid
-{ TARGET_NR_setreuid, "setreuid" , NULL, 

[PATCH] linux-user/strace: Add missing signal strings

[Helge Deller]

Add the textual representations of some missing target signals.

Signed-off-by: Helge Deller 

diff --git a/linux-user/strace.c b/linux-user/strace.c
index 3d4d684450..18b57a9ef9 100644
--- a/linux-user/strace.c
+++ b/linux-user/strace.c
@@ -146,6 +146,22 @@ print_signal(abi_ulong arg, int last)
 case TARGET_SIGSTOP: signal_name = "SIGSTOP"; break;
 case TARGET_SIGTTIN: signal_name = "SIGTTIN"; break;
 case TARGET_SIGTTOU: signal_name = "SIGTTOU"; break;
+case TARGET_SIGIO: signal_name = "SIGIO"; break;
+case TARGET_SIGTRAP: signal_name = "SIGTRAP"; break;
+/* case TARGET_SIGIOT: signal_name = "SIGIOT"; break; */
+#ifdef SIGSTKFLT
+case TARGET_SIGSTKFLT: signal_name = "SIGSTKFLT"; break;
+#endif
+case TARGET_SIGBUS: signal_name = "SIGBUS"; break;
+case TARGET_SIGPWR: signal_name = "SIGPWR"; break;
+case TARGET_SIGURG: signal_name = "SIGURG"; break;
+case TARGET_SIGSYS: signal_name = "SIGSYS"; break;
+case TARGET_SIGXCPU: signal_name = "SIGXCPU"; break;
+case TARGET_SIGPROF: signal_name = "SIGPROF"; break;
+case TARGET_SIGTSTP: signal_name = "SIGTSTP"; break;
+case TARGET_SIGXFSZ: signal_name = "SIGXFSZ"; break;
+case TARGET_SIGWINCH: signal_name = "SIGWINCH"; break;
+case TARGET_SIGVTALRM: signal_name = "SIGVTALRM"; break;
 }
 if (signal_name == NULL) {
 print_raw_param("%ld", arg, last);

Re: [PATCH 2/6] iotests: Skip test 079 if it is not possible to create large files

[Thomas Huth]

On 19/11/2019 18.50, Daniel P. Berrangé wrote:
> On Tue, Nov 19, 2019 at 06:38:20PM +0100, Philippe Mathieu-Daudé wrote:
>> On 11/19/19 6:34 PM, Thomas Huth wrote:
>>> On 19/11/2019 18.29, Philippe Mathieu-Daudé wrote:
 On 11/19/19 6:08 PM, Thomas Huth wrote:
> Test 079 fails in the arm64, s390x and ppc64le LXD containers, which
> apparently do not allow large files to be created. Test 079 tries to
> create a 4G sparse file, so check first whether we can really create
> such files before executing the test.
>
> Signed-off-by: Thomas Huth 
> ---
>    tests/qemu-iotests/079 | 6 ++
>    1 file changed, 6 insertions(+)
>
> diff --git a/tests/qemu-iotests/079 b/tests/qemu-iotests/079
> index 81f0c21f53..e9b81419b7 100755
> --- a/tests/qemu-iotests/079
> +++ b/tests/qemu-iotests/079
> @@ -39,6 +39,12 @@ trap "_cleanup; exit \$status" 0 1 2 3 15
>    _supported_fmt qcow2
>    _supported_proto file nfs
>    +# Some containers (e.g. non-x86 on Travis) do not allow large files
> +if ! truncate --size=4G "$TEST_IMG"; then

 Shouldn't we restrict that to Travis-CI by checking some environment var?
>>>
>>> I'd rather like to keep it independent from Travis environment
>>> variables, since somebody might want to run "make check" in other
>>> non-Travis containers or on weird filesystems, and then the test should
>>> ideally not fail, but simply skip, too.
>>
>> I see. But it would be bad if we stop catching normal bugs with this test
>> because we restricted it to contained environments.
>>
>> Maybe we can add a generic is_contained() routine that only checks for
>> TRAVIS env var, and people using other containers can expand it.
> 
> "is_contained" is still expressing the environment.
> 
> What we need is a way to express features, and be able to switch beteen
> autodetecting features & mandatory enablement.
> 
> eg
> 
>if has_feature "large_file"
>then
>...stuff using large files...
>fi
> 
> The "has_feature" helper would by default call out to
> "has_feature_large_file" todo automatic probing so that things
> "just work" according to whatever env the tests are run inside.
> 
> There should, however, be a flag to "./check" which force enables
> the feature eg  "./check --require-feature large_file" will force
> execution and not attempt to probe for it.
> 
> We could have "--require-feature :all" to force enable all optional
> bits.
> 
> Any formal CI systems should use --require-feature to explicitly
> force testing of features that are expected to always work.
> 
> so Travis x86 would use "--require-feature large_large", but
> the arch64 version would not pass this flag and so do probing
> which will auto-skip.

Maybe a nice idea, but I think this is out of scope for this patch
series. We're using the "if ! truncate --size=4G" check in some other
tests already, so I'm not adding some new mechanism here.
If you want to see some more fine-grained control for the iotests,
please send some patches to rework these other tests first.

 Thomas

Re: [PULL 00/12] Misc patches for QEMU 4.2-rc

[Peter Maydell]

On Tue, 19 Nov 2019 at 16:10, Paolo Bonzini  wrote:
>
> The following changes since commit 369e8f5bbd8a5301bde6fae22b93fe9288c552a5:
>
>   buildfix: update texinfo menu (2019-11-18 10:33:29 +)
>
> are available in the git repository at:
>
>   git://github.com/bonzini/qemu.git tags/for-upstream
>
> for you to fetch changes up to 7a3e29b12f5afe0106a5713bb4db6e23dc66ef91:
>
>   mc146818rtc: fix timer interrupt reinjection again (2019-11-19 10:02:13 
> +0100)
>
> 
> * microvm docs and fixes (Sergio, Liam)
> * New processor features for Intel errata (myself, Pawan)
> * Kconfig fixes (myself, Thomas)
> * Revert mc146818rtc change (myself)
> * Deprecate scsi-disk (myself)
> * RTC fix (myself, Marcelo)


Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/4.2
for any user-visible changes.

-- PMM

Re: [RFC v5 065/126] XIVE: introduce ERRP_AUTO_PROPAGATE

[Greg Kurz]

On Fri, 11 Oct 2019 19:04:51 +0300
Vladimir Sementsov-Ogievskiy  wrote:

> If we want to add some info to errp (by error_prepend() or
> error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
> Otherwise, this info will not be added when errp == _err
> (the program will exit prior to the error_append_hint() or
> error_prepend() call).  Fix such cases.
> 
> If we want to check error after errp-function call, we need to
> introduce local_err and than propagate it to errp. Instead, use
> ERRP_AUTO_PROPAGATE macro, benefits are:
> 1. No need of explicit error_propagate call
> 2. No need of explicit local_err variable: use errp directly
> 3. ERRP_AUTO_PROPAGATE leaves errp as is if it's not NULL or
>_fatel, this means that we don't break error_abort
>(we'll abort on error_set, not on error_propagate)
> 
> This commit (together with its neighbors) was generated by
> 
> for f in $(git grep -l errp \*.[ch]); do \
> spatch --sp-file scripts/coccinelle/auto-propagated-errp.cocci \
> --macro-file scripts/cocci-macro-file.h --in-place --no-show-diff $f; \
> done;
> 
> then fix a bit of compilation problems: coccinelle for some reason
> leaves several
> f() {
> ...
> goto out;
> ...
> out:
> }
> patterns, with "out:" at function end.
> 
> then
> ./python/commit-per-subsystem.py MAINTAINERS "$(< auto-msg)"
> 
> (auto-msg was a file with this commit message)
> 
> Still, for backporting it may be more comfortable to use only the first
> command and then do one huge commit.
> 
> Reported-by: Kevin Wolf 
> Reported-by: Greg Kurz 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> ---
>  hw/intc/spapr_xive.c | 12 -
>  hw/intc/spapr_xive_kvm.c | 55 ++--
>  hw/intc/xive.c   | 27 
>  3 files changed, 40 insertions(+), 54 deletions(-)
> 

We did a huge cleanup recently in this area so this patch doesn't apply
anymore. Ideally it should be based on David Gibson's ppc-for-5.0 branch
available at https://github.com/dgibson/qemu .

Same goes for the PowerPC patch 035/126 actually.

> diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
> index 04879abf2e..b25c9ef9ea 100644
> --- a/hw/intc/spapr_xive.c
> +++ b/hw/intc/spapr_xive.c
> @@ -273,10 +273,10 @@ static void spapr_xive_instance_init(Object *obj)
>  
>  static void spapr_xive_realize(DeviceState *dev, Error **errp)
>  {
> +ERRP_AUTO_PROPAGATE();
>  SpaprXive *xive = SPAPR_XIVE(dev);
>  XiveSource *xsrc = >source;
>  XiveENDSource *end_xsrc = >end_source;
> -Error *local_err = NULL;
>  
>  if (!xive->nr_irqs) {
>  error_setg(errp, "Number of interrupt needs to be greater 0");
> @@ -295,9 +295,8 @@ static void spapr_xive_realize(DeviceState *dev, Error 
> **errp)
>  _fatal);
>  object_property_add_const_link(OBJECT(xsrc), "xive", OBJECT(xive),
> _fatal);
> -object_property_set_bool(OBJECT(xsrc), true, "realized", _err);
> -if (local_err) {
> -error_propagate(errp, local_err);
> +object_property_set_bool(OBJECT(xsrc), true, "realized", errp);
> +if (*errp) {
>  return;
>  }
>  sysbus_init_mmio(SYS_BUS_DEVICE(xive), >esb_mmio);
> @@ -309,9 +308,8 @@ static void spapr_xive_realize(DeviceState *dev, Error 
> **errp)
>  _fatal);
>  object_property_add_const_link(OBJECT(end_xsrc), "xive", OBJECT(xive),
> _fatal);
> -object_property_set_bool(OBJECT(end_xsrc), true, "realized", _err);
> -if (local_err) {
> -error_propagate(errp, local_err);
> +object_property_set_bool(OBJECT(end_xsrc), true, "realized", errp);
> +if (*errp) {
>  return;
>  }
>  sysbus_init_mmio(SYS_BUS_DEVICE(xive), _xsrc->esb_mmio);
> diff --git a/hw/intc/spapr_xive_kvm.c b/hw/intc/spapr_xive_kvm.c
> index 51b334b676..02243537e6 100644
> --- a/hw/intc/spapr_xive_kvm.c
> +++ b/hw/intc/spapr_xive_kvm.c
> @@ -186,6 +186,7 @@ void kvmppc_xive_cpu_connect(XiveTCTX *tctx, Error **errp)
>  void kvmppc_xive_set_source_config(SpaprXive *xive, uint32_t lisn, XiveEAS 
> *eas,
> Error **errp)
>  {
> +ERRP_AUTO_PROPAGATE();
>  uint32_t end_idx;
>  uint32_t end_blk;
>  uint8_t priority;
> @@ -193,7 +194,6 @@ void kvmppc_xive_set_source_config(SpaprXive *xive, 
> uint32_t lisn, XiveEAS *eas,
>  bool masked;
>  uint32_t eisn;
>  uint64_t kvm_src;
> -Error *local_err = NULL;
>  
>  assert(xive_eas_is_valid(eas));
>  
> @@ -214,9 +214,8 @@ void kvmppc_xive_set_source_config(SpaprXive *xive, 
> uint32_t lisn, XiveEAS *eas,
>  KVM_XIVE_SOURCE_EISN_MASK;
>  
>  kvm_device_access(xive->fd, KVM_DEV_XIVE_GRP_SOURCE_CONFIG, lisn,
> -  _src, true, _err);
> -if (local_err) {
> -error_propagate(errp, local_err);
> +  _src, true, errp);
> +if 

Re: [PATCH] Add minimal Hexagon target - First in a series of patches - linux-user changes + linux-user/hexagon + skeleton of target/hexagon - Files in target/hexagon/imported are from another project

[Laurent Vivier]

Le 19/11/2019 à 18:22, Taylor Simpson a écrit :
> Thanks for all the feedback on the patch.  I'll summarize my TODO list here.  
> Please let me know if there's anything I missed.
> - Add a README file in the imported directory to make it clear that the code 
> comes from another project.  Personally, I prefer keeping the name as 
> "imported".  It was suggested by Richard at the meeting.  Also as a heads-up, 
> that is a small subset of the files that will be in that directory 
> eventually.  Right now, it is the minimum needed to build the skeleton target.
> - Work on the .checkpatchignore as Philippe suggested.
> - Split out the "[__SIGRTMAX - 1] = __SIGRTMIN + 1" into a separate patch.
> - Clean up the long subject line.
> - Add license text to the new files.
> - Remove the DEBUG_HEX blocks.  In general the DEBUG_HEX macro controls a 
> bunch of debugging output as you'll see in later patches.  In the long run, I 
> think it should be replaces with a macro that is defined when configured with 
> --enable-debug and then an additional command-line argument.  I haven't 
> looked into this, so any pointers would be appreciated.

You can have a look to the trace infrastructure
(docs/devel/tracing.txt). We have also some qemu_log() macros for low
level debugging.

> - Laurent suggested I split the patch into two parts: linux-user and 
> target/hexagon.  If I do that, which one should contain the changes to common 
> files (e.g., configure)?  Also, note that we won't be able to build until 
> both patches are merged.  Is that OK?

You should add target/hexagon first, and it should not be build as we
don't have any target (hexagon-linux-user or hexagon-softmmu),
then you can add linux-user part that will be built and use the
target/hexagone CPU. I think the configure part should go to the
linux-user part as it enables the build.

I asked to split the patch for review purpose, but this should not break
anything (to allow bisect).

Thanks,
Laurent

> 
> Thanks,
> Taylor
> 
> 
> -Original Message-
> From: Philippe Mathieu-Daudé 
> Sent: Tuesday, November 19, 2019 9:19 AM
> To: Taylor Simpson ; laur...@vivier.eu; 
> riku.voi...@iki.fi; qemu-devel@nongnu.org
> Subject: Re: [PATCH] Add minimal Hexagon target - First in a series of 
> patches - linux-user changes + linux-user/hexagon + skeleton of 
> target/hexagon - Files in target/hexagon/imported are from another project 
> and therefore do not conform to qemu coding standards
> 
> -
> CAUTION: This email originated from outside of the organization.
> -
> 
> On 11/19/19 12:58 AM, Taylor Simpson wrote:
>> Signed-off-by: Taylor Simpson 
>> ---
> [...]
>>   target/hexagon/imported/global_types.h  |  25 +++
>>   target/hexagon/imported/iss_ver_registers.h | 183 +++
>>   target/hexagon/imported/max.h   |  78 +++
>>   target/hexagon/imported/regs.h  |  19 ++
> 
> Maybe you can rename this directory as:
> 
> target/hexagon/dsp-sdk/
> 
> and add a README "Files under this directory are imported from the SDK 
> available once registered on developer.qualcomm.com ..."
> 
> 

Re: test-aio-multithread assertion

[Peter Maydell]

On Tue, 19 Nov 2019 at 17:55, Peter Maydell  wrote:
> Here's a gdb backtrace from as assertion failure under NetBSD
> when running ./tests/test-aio-multithread -p /aio/multi/mutex/contended
> (which is pretty replicable for me); does it look like the same
> thing as the commit 2362a28ea1 issue? (Apologies for all the
> "optimized out" stuff in the backtraces; I'll try to rerun with
> a --enable-debug build.)

...that was easier than I thought it might be. Here's the
--enable-debug version:

Thread 7 (LWP 2):
#0  0x78b302099c0a in ___lwp_park60 () from /usr/lib/libc.so.12
#1  0x78b302409ee3 in pthread_cond_timedwait () from
/usr/lib/libpthread.so.1
#2  0x00519388 in qemu_futex_wait (ev=0x7d26e0
, val=4294967295)
at /home/qemu/qemu-test.0WfUNX/src/util/qemu-thread-posix.c:364
#3  0x0051959d in qemu_event_wait (ev=0x7d26e0 )
at /home/qemu/qemu-test.0WfUNX/src/util/qemu-thread-posix.c:459
#4  0x005305db in call_rcu_thread (opaque=0x0)
at /home/qemu/qemu-test.0WfUNX/src/util/rcu.c:260
#5  0x0051969f in qemu_thread_start (args=0x78b305722c00)
at /home/qemu/qemu-test.0WfUNX/src/util/qemu-thread-posix.c:519
#6  0x78b30240b8b5 in ?? () from /usr/lib/libpthread.so.1
#7  0x78b302081e20 in ?? () from /usr/lib/libc.so.12
#8  0x00010102464c457f in ?? ()
#9  0x in ?? ()

Thread 6 (LWP 3):
#0  0x78b30203e02a in write () from /usr/lib/libc.so.12
#1  0x78b302407561 in write () from /usr/lib/libpthread.so.1
#2  0x00516e26 in event_notifier_set (e=0x78b304701284)
at /home/qemu/qemu-test.0WfUNX/src/util/event_notifier-posix.c:100
#3  0x00511ccb in aio_notify (ctx=0x78b304701180)
at /home/qemu/qemu-test.0WfUNX/src/util/async.c:350
#4  0x0051183d in qemu_bh_schedule (bh=0x78b304717050)
at /home/qemu/qemu-test.0WfUNX/src/util/async.c:167
#5  0x00512100 in aio_co_schedule (ctx=0x78b304701180,
co=0x78b303701280)
at /home/qemu/qemu-test.0WfUNX/src/util/async.c:473
#6  0x00512180 in aio_co_enter (ctx=0x78b304701180, co=0x78b303701280)
at /home/qemu/qemu-test.0WfUNX/src/util/async.c:494
#7  0x0051214f in aio_co_wake (co=0x78b303701280)
at /home/qemu/qemu-test.0WfUNX/src/util/async.c:488
#8  0x00531b3e in qemu_co_mutex_wake (mutex=0x7d1700
, co=0x78b303701280)
at /home/qemu/qemu-test.0WfUNX/src/util/qemu-coroutine-lock.c:198
#9  0x00531eb2 in qemu_co_mutex_unlock (mutex=0x7d1700 )
at /home/qemu/qemu-test.0WfUNX/src/util/qemu-coroutine-lock.c:301
#10 0x0040b8b5 in test_multi_co_mutex_entry (opaque=0x0)
at /home/qemu/qemu-test.0WfUNX/src/tests/test-aio-multithread.c:208
#11 0x00532bc1 in coroutine_trampoline (i0=57676000, i1=30899)
at /home/qemu/qemu-test.0WfUNX/src/util/coroutine-ucontext.c:115
#12 0x78b30205dba0 in ?? () from /usr/lib/libc.so.12
#13 0x00010102464c457f in ?? ()
#14 0x in ?? ()

Thread 5 (LWP 5):
#0  0x78b30203e02a in write () from /usr/lib/libc.so.12
#1  0x78b302407561 in write () from /usr/lib/libpthread.so.1
#2  0x00516e26 in event_notifier_set (e=0x78b305316284)
at /home/qemu/qemu-test.0WfUNX/src/util/event_notifier-posix.c:100
#3  0x00511ccb in aio_notify (ctx=0x78b305316180)
at /home/qemu/qemu-test.0WfUNX/src/util/async.c:350
#4  0x0051183d in qemu_bh_schedule (bh=0x78b305301080)
at /home/qemu/qemu-test.0WfUNX/src/util/async.c:167
#5  0x00512100 in aio_co_schedule (ctx=0x78b305316180,
co=0x78b303701350)
at /home/qemu/qemu-test.0WfUNX/src/util/async.c:473
#6  0x00512180 in aio_co_enter (ctx=0x78b305316180, co=0x78b303701350)
at /home/qemu/qemu-test.0WfUNX/src/util/async.c:494
#7  0x0051214f in aio_co_wake (co=0x78b303701350)
at /home/qemu/qemu-test.0WfUNX/src/util/async.c:488
#8  0x00531b3e in qemu_co_mutex_wake (mutex=0x7d1700
, co=0x78b303701350)
at /home/qemu/qemu-test.0WfUNX/src/util/qemu-coroutine-lock.c:198
#9  0x00531eb2 in qemu_co_mutex_unlock (mutex=0x7d1700 )
at /home/qemu/qemu-test.0WfUNX/src/util/qemu-coroutine-lock.c:301
#10 0x0040b8b5 in test_multi_co_mutex_entry (opaque=0x0)
at /home/qemu/qemu-test.0WfUNX/src/tests/test-aio-multithread.c:208
#11 0x00532bc1 in coroutine_trampoline (i0=57676416, i1=30899)
at /home/qemu/qemu-test.0WfUNX/src/util/coroutine-ucontext.c:115

#12 0x78b30205dba0 in ?? () from /usr/lib/libc.so.12
#13 0x00010102464c457f in ?? ()
#14 0x in ?? ()

Thread 4 (LWP 6):
#0  0x78b30203e28a in poll () from /usr/lib/libc.so.12
#1  0x78b3024072d0 in poll () from /usr/lib/libpthread.so.1
#2  0x00513bf9 in qemu_poll_ns (fds=0x78b3053050c0, nfds=1, timeout=-1)
at /home/qemu/qemu-test.0WfUNX/src/util/qemu-timer.c:351
#3  0x0051665a in aio_poll (ctx=0x78b305316180, blocking=true)
at /home/qemu/qemu-test.0WfUNX/src/util/aio-posix.c:669
#4  0x004ddf5c in iothread_run 

Re: [RFC v5 035/126] PowerPC Machines: introduce ERRP_AUTO_PROPAGATE

[Greg Kurz]

On Fri, 11 Oct 2019 19:04:21 +0300
Vladimir Sementsov-Ogievskiy  wrote:

> If we want to add some info to errp (by error_prepend() or
> error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
> Otherwise, this info will not be added when errp == _err
> (the program will exit prior to the error_append_hint() or
> error_prepend() call).  Fix such cases.
> 
> If we want to check error after errp-function call, we need to
> introduce local_err and than propagate it to errp. Instead, use
> ERRP_AUTO_PROPAGATE macro, benefits are:
> 1. No need of explicit error_propagate call
> 2. No need of explicit local_err variable: use errp directly
> 3. ERRP_AUTO_PROPAGATE leaves errp as is if it's not NULL or
>_fatel, this means that we don't break error_abort
>(we'll abort on error_set, not on error_propagate)
> 
> This commit (together with its neighbors) was generated by
> 
> for f in $(git grep -l errp \*.[ch]); do \
> spatch --sp-file scripts/coccinelle/auto-propagated-errp.cocci \
> --macro-file scripts/cocci-macro-file.h --in-place --no-show-diff $f; \
> done;
> 
> then fix a bit of compilation problems: coccinelle for some reason
> leaves several
> f() {
> ...
> goto out;
> ...
> out:
> }
> patterns, with "out:" at function end.
> 
> then
> ./python/commit-per-subsystem.py MAINTAINERS "$(< auto-msg)"
> 
> (auto-msg was a file with this commit message)
> 
> Still, for backporting it may be more comfortable to use only the first
> command and then do one huge commit.
> 
> Reported-by: Kevin Wolf 
> Reported-by: Greg Kurz 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> ---

Reviewing such a big patch looks a frightening... PowerPC Machines covers
a lot of files. If this has to be automated, it would be better to split
according to each individual machine type IMHO. Or alternatively, come up
with a manual split, eg. sPAPR machine, PowerNV machine, XICS stuff, other
PowerPC machines.

>  hw/intc/pnv_xive.c  |  15 ++---

This gets caught because of hw/intc/pnv* but it would probably better
placed in the XIVE patch (065/126 in this series). Maybe we should
patch MAINTAINERS to be more precise.

>  hw/intc/xics.c  |  28 -
>  hw/intc/xics_kvm.c  |  30 +
>  hw/intc/xics_pnv.c  |   7 +--
>  hw/intc/xics_spapr.c|   7 +--
>  hw/isa/pc87312.c|   7 +--
>  hw/misc/macio/macio.c   |  68 +---
>  hw/ppc/e500.c   |   7 +--
>  hw/ppc/mac_newworld.c   |   1 +
>  hw/ppc/pnv.c| 109 ++--
>  hw/ppc/pnv_core.c   |  23 +++
>  hw/ppc/pnv_homer.c  |   5 +-
>  hw/ppc/pnv_lpc.c|  26 
>  hw/ppc/pnv_occ.c|   5 +-
>  hw/ppc/pnv_psi.c|  23 +++
>  hw/ppc/spapr.c  | 133 ++--
>  hw/ppc/spapr_caps.c |  57 -
>  hw/ppc/spapr_cpu_core.c |  36 +--
>  hw/ppc/spapr_drc.c  |  48 ++-
>  hw/ppc/spapr_irq.c  |  98 +
>  hw/ppc/spapr_pci.c  |  97 +
>  hw/ppc/spapr_vio.c  |  12 ++--
>  22 files changed, 364 insertions(+), 478 deletions(-)
> 
> diff --git a/hw/intc/pnv_xive.c b/hw/intc/pnv_xive.c
> index ed6e9d71bb..05acec9b91 100644
> --- a/hw/intc/pnv_xive.c
> +++ b/hw/intc/pnv_xive.c
> @@ -1659,15 +1659,14 @@ static void pnv_xive_init(Object *obj)
>  
>  static void pnv_xive_realize(DeviceState *dev, Error **errp)
>  {
> +ERRP_AUTO_PROPAGATE();
>  PnvXive *xive = PNV_XIVE(dev);
>  XiveSource *xsrc = >ipi_source;
>  XiveENDSource *end_xsrc = >end_source;
> -Error *local_err = NULL;
>  Object *obj;
>  
> -obj = object_property_get_link(OBJECT(dev), "chip", _err);
> +obj = object_property_get_link(OBJECT(dev), "chip", errp);
>  if (!obj) {
> -error_propagate(errp, local_err);
>  error_prepend(errp, "required link 'chip' not found: ");
>  return;
>  }
> @@ -1685,9 +1684,8 @@ static void pnv_xive_realize(DeviceState *dev, Error 
> **errp)
>  _fatal);
>  object_property_add_const_link(OBJECT(xsrc), "xive", OBJECT(xive),
> _fatal);
> -object_property_set_bool(OBJECT(xsrc), true, "realized", _err);
> -if (local_err) {
> -error_propagate(errp, local_err);
> +object_property_set_bool(OBJECT(xsrc), true, "realized", errp);
> +if (*errp) {
>  return;
>  }
>  
> @@ -1695,9 +1693,8 @@ static void pnv_xive_realize(DeviceState *dev, Error 
> **errp)
>  _fatal);
>  object_property_add_const_link(OBJECT(end_xsrc), "xive", OBJECT(xive),
> _fatal);
> -object_property_set_bool(OBJECT(end_xsrc), true, "realized", _err);
> -if (local_err) {
> -error_propagate(errp, local_err);
> +object_property_set_bool(OBJECT(end_xsrc), true, "realized", errp);
> +if (*errp) {
>  

Re: [RFC PATCH v1 1/8] vfio-ccw: Return IOINST_CC_NOT_OPERATIONAL for EIO

[Halil Pasic]

On Tue, 19 Nov 2019 13:02:20 +0100
Cornelia Huck  wrote:

> On Tue, 19 Nov 2019 12:23:40 +0100
> Halil Pasic  wrote:
> 
> > On Mon, 18 Nov 2019 19:13:34 +0100
> > Cornelia Huck  wrote:
> > 
> > > > EIO is returned by vfio-ccw mediated device when the backing
> > > > host subchannel is not operational anymore. So return cc=3
> > > > back to the guest, rather than returning a unit check.
> > > > This way the guest can take appropriate action such as
> > > > issue an 'stsch'.
> > > 
> > > Hnm, I'm trying to recall whether that was actually a conscious choice,
> > > but I can't quite remember... the change does make sense at a glance,
> > > however.  
> > 
> > Is EIO returned if and only if the host subchannel/device is not
> > operational any more, or are there cases as well? 
> 
> Ok, I walked through the kernel code, and it seems -EIO can happen

Thanks Connie for having a look.

> - when we try to do I/O while in the NOT_OPER or STANDBY states... cc 3
>   makes sense in those cases

I do understand NOT_OPER, but I'm not sure about STANDBY.

Here is what the PoP says about cc 3 for SSCH.
"""
Condition code 3 is set, and no other action is
taken, when the subchannel is not operational for
START SUBCHANNEL. A subchannel is not opera-
tional for START SUBCHANNEL if the subchannel is
not provided in the channel subsystem, has no valid
device number associated with it, or is not enabled.
"""

Are we guaranteed to reflect one of these conditions back?

Under what circumstances do we expect that our request will
find the device in STANDBY?

> - when the cp is not initialized when trying to fetch the orb... which
>   is an internal vfio-ccw kernel module error


So the answer seems to be, no EIO is also used for something else than
'device not operational' in a sense of the s390 IO architecture (cc=3
and stuff).

AFAIR the idea was that EIO means something is broken, and we decided
to reflect that as an unit check (because the broader device -- the
actual device + our pass-through code == device for the guest) is broken.
So I think it was a conscious choice.

Regards,
Halil

> 
> Btw., this patch only changes one of the handlers; I think you have to
> change all of start/halt/clear?
> 
> [Might also be good to double-check the handling for the different
> instructions.]
> 
> > Is the mapping
> > (cc to condition) documented? By the QEMU code I would think that
> > we already have ENODEV and EACCESS for 'not operational' -- no idea
> > why we need two codes though.
> 
> -ENODEV: device gone
> -EACCES: no path operational
> 
> We should be able to distinguish between the two; in the 'no path
> operational' case, the device may still be accessible with a different
> path mask in the request.
> 

Re: [PATCH] misc/pca9552: Add qom set and get

[Philippe Mathieu-Daudé]

On 11/19/19 5:27 PM, Cédric Le Goater wrote:

On 18/11/2019 18:48, Philippe Mathieu-Daudé wrote:

Odd... I only received Cédric answer, not Joel patch.

On 11/18/19 11:00 AM, Cédric Le Goater wrote:

On 18/11/2019 07:17, Joel Stanley wrote:

Following the pattern of the work recently done with the ASPEED GPIO
model, this adds support for inspecting and modifying the PCA9552 LEDs
from the monitor.

   (qemu) qom-set  /machine/unattached/device[17] led0 on
   (qemu) qom-get  /machine/unattached/device[17] led0
   "on"

   (qemu) qom-set  /machine/unattached/device[17] led0 off
   (qemu) qom-get  /machine/unattached/device[17] led0
   "off"

   (qemu) qom-set  /machine/unattached/device[17] led0 pwm0
   (qemu) qom-get  /machine/unattached/device[17] led0
   "pwm0"

   (qemu) qom-set  /machine/unattached/device[17] led0 pwm1
   (qemu) qom-get  /machine/unattached/device[17] led0
   "pwm1"


It would be nice to revive the QOM get patchset from David.

 http://patchwork.ozlabs.org/patch/666458/

Did we reach some consensus ?


Signed-off-by: Joel Stanley 


Some comments below.


---
The qom device in mainline qemu is a different path. Using the monitor
examine `info qom-tree /machine/unattached/` to discover it.

This can be tested with a Witherspoon image.

$ wget 
https://openpower.xyz/job/openbmc-build/distro=ubuntu,label=builder,target=witherspoon/lastSuccessfulBuild/artifact/deploy/images/witherspoon/obmc-phosphor-image-witherspoon.ubi.mtd

$ qemu-system-arm -M witherspoon-bmc -serial pty -monitor pty -nographic \
   -drive file=obmc-phosphor-image-witherspoon.ubi.mtd,format=raw,if=mtd
char device redirected to /dev/pts/5 (label compat_monitor0)
char device redirected to /dev/pts/10 (label serial0)

$ screen /dev/pts/5
QEMU 4.1.91 monitor - type 'help' for more information
(qemu) qom-get  /machine/unattached/device[17] led0
"off"

$ screen /dev/pts/19
root@witherspoon:~# cd /sys/class/gpio/
root@witherspoon:/sys/class/gpio# echo 248 > export
root@witherspoon:/sys/class/gpio# cat gpio248/value
0

(qemu) qom-set  /machine/unattached/device[17] led0 on

root@witherspoon:/sys/class/gpio# echo out > gpio248/direction
root@witherspoon:/sys/class/gpio# cat gpio248/value
1

(qemu) qom-get  /machine/unattached/device[17] led0
"on"

(qemu) qom-set  /machine/unattached/device[17] led0 off
(qemu) qom-get  /machine/unattached/device[17] led0
"off"

root@witherspoon:/sys/class/gpio# cat gpio248/value
0


I am assuming this is 5.0 material.

This is a good starting point, and is useful.

However this would be useful for other boards/devices too.

What about defining a InterfaceInfo[] for external GPIOs?


The code below is very specific to pca9552.


Yes, sorry if I was unclear, I don't want to delay this series, I was 
just thinking about other uses.



What kind of interface do you have in mind more precisely ?
which handlers ?


Here we expose the devices GPIOs (as output) so they can be modified via 
QMP.


A QMP client could subscribe to GPIOs input events (or IRQ triggered).

(The PCA9552 can also use the 16 lines as input, but Joel added a "input 
line behaviour not modeled" comment below).


Maybe the PCA9552 isn't the best example for my generic use case, 
because it is already "out of the soc/board" being on a bus.


I'm more concerned about a generic QMP way to access GPIOs from a SoC 
exposed to a physical user of a board.



Shouldn't we use the qemu_irq type for that then?



Signed-off-by: Joel Stanley 
---
   hw/misc/pca9552.c | 91 +++
   1 file changed, 91 insertions(+)

diff --git a/hw/misc/pca9552.c b/hw/misc/pca9552.c
index 73be28d9369c..0362aac8c862 100644
--- a/hw/misc/pca9552.c
+++ b/hw/misc/pca9552.c
@@ -15,12 +15,16 @@
   #include "hw/misc/pca9552.h"
   #include "hw/misc/pca9552_regs.h"
   #include "migration/vmstate.h"
+#include "qapi/error.h"
+#include "qapi/visitor.h"
     #define PCA9552_LED_ON   0x0
   #define PCA9552_LED_OFF  0x1
   #define PCA9552_LED_PWM0 0x2
   #define PCA9552_LED_PWM1 0x3
   +static const char *led_state[] = {"on", "off", "pwm0", "pwm1"};


BTW "pwm0/pwm1" as "state" is confuse, but I understand this is how the PCA9552 
datasheet describes it.


+
   static uint8_t pca9552_pin_get_config(PCA9552State *s, int pin)
   {
   uint8_t reg   = PCA9552_LS0 + (pin / 4);
@@ -169,6 +173,84 @@ static int pca9552_event(I2CSlave *i2c, enum i2c_event 
event)
   return 0;
   }
   +static void pca9552_get_led(Object *obj, Visitor *v, const char *name,
+    void *opaque, Error **errp)
+{
+    PCA9552State *s = PCA9552(obj);
+    int led, rc, reg;
+    char *str;
+    uint8_t state;
+
+    rc = sscanf(name, "led%2d", );
+    if (rc != 1) {
+    error_setg(errp, "%s: error reading %s", __func__, name);
+    return;
+    }
+    if (led < 0 || led > s->nr_leds) {
+    error_setg(errp, "%s invalid led %s", __func__, name);
+    return;
+    }
+    /*
+ * Get the LSx register as the qom 

[PATCH 3/5] hw/ppc/pnv_xscom: Power8 occ common area is in PBA BAR 3

[Balamuruhan S]

Fix incorrect PBA BAR and BARMASK value for Power8 occ common area
region where skiboot enum declaration have it in BAR 3 and BARMASK
is calculated BARMASK0 + BAR,

enum P8_BAR {
P8_BAR_HOMER = 0,
P8_BAR_CENTAUR = 1,
P8_BAR_SLW = 2,
P8_BAR_OCC_COMMON = 3,
};

Signed-off-by: Cédric Le Goater 
Signed-off-by: Balamuruhan S 
---
 hw/ppc/pnv_xscom.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/hw/ppc/pnv_xscom.c b/hw/ppc/pnv_xscom.c
index cdd5fa356e..cb6d6bbcfc 100644
--- a/hw/ppc/pnv_xscom.c
+++ b/hw/ppc/pnv_xscom.c
@@ -38,9 +38,9 @@
 
 /* PBA BARs */
 #define P8_PBA_BAR0 0x2013f00
-#define P8_PBA_BAR2 0x2013f02
+#define P8_PBA_BAR3 0x2013f03
 #define P8_PBA_BARMASK0 0x2013f04
-#define P8_PBA_BARMASK2 0x2013f06
+#define P8_PBA_BARMASK3 0x2013f07
 #define P9_PBA_BAR0 0x5012b00
 #define P9_PBA_BAR2 0x5012b02
 #define P9_PBA_BARMASK0 0x5012b04
@@ -99,11 +99,11 @@ static uint64_t xscom_read_default(PnvChip *chip, uint32_t 
pcba)
 
 case P9_PBA_BAR2: /* P9 occ common area */
 return PNV9_OCC_COMMON_AREA(chip);
-case P8_PBA_BAR2: /* P8 occ common area */
+case P8_PBA_BAR3: /* P8 occ common area */
 return PNV_OCC_COMMON_AREA(chip);
 
 case P9_PBA_BARMASK2: /* P9 occ common area size */
-case P8_PBA_BARMASK2: /* P8 occ common area size */
+case P8_PBA_BARMASK3: /* P8 occ common area size */
 return OCC_SIZE_MASK;
 
 case 0x1010c00: /* PIBAM FIR */
@@ -126,9 +126,9 @@ static uint64_t xscom_read_default(PnvChip *chip, uint32_t 
pcba)
 case 0x202000f: /* ADU stuff, receive status register*/
 return 0;
 case 0x2013f01: /* PBA stuff */
-case 0x2013f03: /* PBA stuff */
+case 0x2013f02: /* PBA stuff */
 case 0x2013f05: /* PBA stuff */
-case 0x2013f07: /* PBA stuff */
+case 0x2013f06: /* PBA stuff */
 return 0;
 case 0x2013028: /* CAPP stuff */
 case 0x201302a: /* CAPP stuff */
-- 
2.14.5

Re: test-aio-multithread assertion

[Peter Maydell]

On Mon, 14 Oct 2019 at 11:50, Paolo Bonzini  wrote:
>
> On 14/10/19 12:26, Peter Maydell wrote:
> > On Thu, 5 Sep 2019 at 14:17, Peter Maydell  wrote:
> >> Here's a different intermittent assertion on Netbsd from 
> >> test-aio-multithread:
> >>
> >> MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}
> >> tests/test-aio-multithread -m=quick
> >> -k --tap < /dev/null | ./scripts/tap-driver.pl
> >> --test-name="test-aio-multithread"
> >> PASS 1 test-aio-multithread /aio/multi/lifecycle
> >> PASS 2 test-aio-multithread /aio/multi/schedule
> >> assertion "QSLIST_EMPTY(>scheduled_coroutines)" failed: file
> >> "util/async.c", line 279, function "
> >> aio_ctx_finalize"
> >> ERROR - too few tests run (expected 5, got 2)
> >
> > Just saw this QSLIST_EMPTY(>scheduled_coroutines) assertion
> > from FreeBSD as well, so it's still around as a definite
> > intermittent.
>
> This could be similar to what Stefan fixed in commit 2362a28ea1, only in
> the test infrastructure.

Here's a gdb backtrace from as assertion failure under NetBSD
when running ./tests/test-aio-multithread -p /aio/multi/mutex/contended
(which is pretty replicable for me); does it look like the same
thing as the commit 2362a28ea1 issue? (Apologies for all the
"optimized out" stuff in the backtraces; I'll try to rerun with
a --enable-debug build.)

Thread 7 (LWP 2):
#0  0x7e4b44499c0a in ___lwp_park60 () from /usr/lib/libc.so.12
#1  0x7e4b44809ee3 in pthread_cond_timedwait () from
/usr/lib/libpthread.so.1
#2  0x004c0862 in qemu_futex_wait (val=4294967295, ev=0x760c00
)
at /home/qemu/qemu-test.0WfUNX/src/util/qemu-thread-posix.c:364
#3  qemu_event_wait (ev=ev@entry=0x760c00 )
at /home/qemu/qemu-test.0WfUNX/src/util/qemu-thread-posix.c:459
#4  0x004ce825 in call_rcu_thread (opaque=opaque@entry=0x0)
at /home/qemu/qemu-test.0WfUNX/src/util/rcu.c:260
#5  0x004bfd17 in qemu_thread_start (args=0x7e4b47b22c00)
at /home/qemu/qemu-test.0WfUNX/src/util/qemu-thread-posix.c:519
#6  0x7e4b4480b8b5 in ?? () from /usr/lib/libpthread.so.1
#7  0x7e4b44481e20 in ?? () from /usr/lib/libc.so.12
#8  0x00010102464c457f in ?? ()
#9  0x in ?? ()

Thread 6 (LWP 3):
#0  0x7e4b4443e02a in write () from /usr/lib/libc.so.12
#1  0x7e4b44807561 in write () from /usr/lib/libpthread.so.1
#2  0x004beae0 in event_notifier_set (e=e@entry=0x7e4b46f01214)
at /home/qemu/qemu-test.0WfUNX/src/util/event_notifier-posix.c:100
#3  0x004bb66c in aio_notify (ctx=0x7e4b46f01120)
at /home/qemu/qemu-test.0WfUNX/src/util/async.c:350
#4  0x004bb936 in aio_co_schedule (ctx=0x7e4b46f01120,
co=0x7e4b46b01280)
at /home/qemu/qemu-test.0WfUNX/src/util/async.c:473
#5  0x004cf226 in qemu_co_mutex_wake (mutex=0x75fc00
, co=)
at /home/qemu/qemu-test.0WfUNX/src/util/qemu-coroutine-lock.c:198
#6  qemu_co_mutex_unlock (mutex=mutex@entry=0x75fc00 )
at /home/qemu/qemu-test.0WfUNX/src/util/qemu-coroutine-lock.c:301
#7  0x0040b33b in test_multi_co_mutex_entry (opaque=)
at /home/qemu/qemu-test.0WfUNX/src/tests/test-aio-multithread.c:208
#8  0x004cff6b in coroutine_trampoline (i0=,
i1=)
at /home/qemu/qemu-test.0WfUNX/src/util/coroutine-ucontext.c:115
#9  0x7e4b4445dba0 in ?? () from /usr/lib/libc.so.12
#10 0x00010102464c457f in ?? ()
#11 0x in ?? ()

Thread 5 (LWP 4):
#0  0x0040b34a in test_multi_co_mutex_entry (opaque=)
at /home/qemu/qemu-test.0WfUNX/src/tests/test-aio-multithread.c:205
#1  0x004cff6b in coroutine_trampoline (i0=,
i1=)
at /home/qemu/qemu-test.0WfUNX/src/util/coroutine-ucontext.c:115
#2  0x7e4b4445dba0 in ?? () from /usr/lib/libc.so.12
#3  0x00010102464c457f in ?? ()
#4  0x in ?? ()

Thread 4 (LWP 5):
#0  0x7e4b4443e02a in write () from /usr/lib/libc.so.12
#1  0x7e4b44807561 in write () from /usr/lib/libpthread.so.1
#2  0x004beae0 in event_notifier_set (e=e@entry=0x7e4b47701384)
at /home/qemu/qemu-test.0WfUNX/src/util/event_notifier-posix.c:100
#3  0x004bb66c in aio_notify (ctx=0x7e4b47701290)
at /home/qemu/qemu-test.0WfUNX/src/util/async.c:350
#4  0x004bb936 in aio_co_schedule (ctx=0x7e4b47701290,
co=0x7e4b46b01420)
at /home/qemu/qemu-test.0WfUNX/src/util/async.c:473
#5  0x004cf226 in qemu_co_mutex_wake (mutex=0x75fc00
, co=)
at /home/qemu/qemu-test.0WfUNX/src/util/qemu-coroutine-lock.c:198
#6  qemu_co_mutex_unlock (mutex=mutex@entry=0x75fc00 )
at /home/qemu/qemu-test.0WfUNX/src/util/qemu-coroutine-lock.c:301
#7  0x0040b33b in test_multi_co_mutex_entry (opaque=)
at /home/qemu/qemu-test.0WfUNX/src/tests/test-aio-multithread.c:208
#8  0x004cff6b in coroutine_trampoline (i0=,
i1=)
at /home/qemu/qemu-test.0WfUNX/src/util/coroutine-ucontext.c:115
#9  0x7e4b4445dba0 in ?? () from /usr/lib/libc.so.12
#10 0x00010102464c457f in ?? ()
#11 0x in ?? ()

Thread 3 (LWP 7):
#0  

[PATCH 1/5] hw/ppc/pnv: incorrect homer and occ common area size

[Balamuruhan S]

Homer size is 4MB and OCC common area size is 8MB, but currently
it is assigned with bar mask value. Also pass on the occ sram
size 3 bits right shifted to initialize the size appropriately.

Signed-off-by: Cédric Le Goater 
Signed-off-by: Balamuruhan S 
---
 hw/ppc/pnv_occ.c | 2 +-
 include/hw/ppc/pnv.h | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/hw/ppc/pnv_occ.c b/hw/ppc/pnv_occ.c
index 785653bb67..05c51c9de0 100644
--- a/hw/ppc/pnv_occ.c
+++ b/hw/ppc/pnv_occ.c
@@ -276,7 +276,7 @@ static void pnv_occ_realize(DeviceState *dev, Error **errp)
 
 /* XScom region for OCC SRAM registers */
 pnv_xscom_region_init(>sram_regs, OBJECT(dev), poc->sram_ops,
-  occ, "occ-common-area", poc->sram_size);
+  occ, "occ-common-area", poc->sram_size >> 3);
 }
 
 static void pnv_occ_class_init(ObjectClass *klass, void *data)
diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
index 0b4c722e6b..e9ed8b928a 100644
--- a/include/hw/ppc/pnv.h
+++ b/include/hw/ppc/pnv.h
@@ -203,12 +203,12 @@ void pnv_bmc_powerdown(IPMIBmc *bmc);
 #define PNV_XSCOM_BASE(chip)\
 (0x0003fc00ull + ((uint64_t)(chip)->chip_id) * PNV_XSCOM_SIZE)
 
-#define PNV_OCC_COMMON_AREA_SIZE0x0070ull
+#define PNV_OCC_COMMON_AREA_SIZE0x0080ull
 #define PNV_OCC_COMMON_AREA(chip)   \
 (0x7fff80ull + ((uint64_t)PNV_CHIP_INDEX(chip) * \
  PNV_OCC_COMMON_AREA_SIZE))
 
-#define PNV_HOMER_SIZE  0x0030ull
+#define PNV_HOMER_SIZE  0x0040ull
 #define PNV_HOMER_BASE(chip)\
 (0x7ffd80ull + ((uint64_t)PNV_CHIP_INDEX(chip)) * PNV_HOMER_SIZE)
 
@@ -271,12 +271,12 @@ void pnv_bmc_powerdown(IPMIBmc *bmc);
 #define PNV9_XSCOM_SIZE  0x0004ull
 #define PNV9_XSCOM_BASE(chip)PNV9_CHIP_BASE(chip, 0x00603fcull)
 
-#define PNV9_OCC_COMMON_AREA_SIZE0x0070ull
+#define PNV9_OCC_COMMON_AREA_SIZE0x0080ull
 #define PNV9_OCC_COMMON_AREA(chip)  \
 (0x203fff80ull + ((uint64_t)PNV_CHIP_INDEX(chip) * \
PNV9_OCC_COMMON_AREA_SIZE))
 
-#define PNV9_HOMER_SIZE  0x0030ull
+#define PNV9_HOMER_SIZE  0x0040ull
 #define PNV9_HOMER_BASE(chip)   \
 (0x203ffd80ull + ((uint64_t)PNV_CHIP_INDEX(chip)) * PNV9_HOMER_SIZE)
 #endif /* PPC_PNV_H */
-- 
2.14.5

[PATCH 4/5] hw/ppc/pnv_xscom: occ common area to be mapped only once

[Balamuruhan S]

occ common area should be mapped once and disable it for every
other chip.

Signed-off-by: Cédric Le Goater 
Signed-off-by: Balamuruhan S 
---
 hw/ppc/pnv_xscom.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/hw/ppc/pnv_xscom.c b/hw/ppc/pnv_xscom.c
index cb6d6bbcfc..f797a5ec7d 100644
--- a/hw/ppc/pnv_xscom.c
+++ b/hw/ppc/pnv_xscom.c
@@ -98,13 +98,22 @@ static uint64_t xscom_read_default(PnvChip *chip, uint32_t 
pcba)
 return HOMER_SIZE_MASK;
 
 case P9_PBA_BAR2: /* P9 occ common area */
-return PNV9_OCC_COMMON_AREA(chip);
+if (!PNV_CHIP_INDEX(chip)) {
+return PNV9_OCC_COMMON_AREA(chip);
+}
+return 0;
 case P8_PBA_BAR3: /* P8 occ common area */
-return PNV_OCC_COMMON_AREA(chip);
+if (!PNV_CHIP_INDEX(chip)) {
+return PNV_OCC_COMMON_AREA(chip);
+}
+return 0;
 
 case P9_PBA_BARMASK2: /* P9 occ common area size */
 case P8_PBA_BARMASK3: /* P8 occ common area size */
-return OCC_SIZE_MASK;
+if (!PNV_CHIP_INDEX(chip)) {
+return OCC_SIZE_MASK;
+}
+return 0;
 
 case 0x1010c00: /* PIBAM FIR */
 case 0x1010c03: /* PIBAM FIR MASK */
-- 
2.14.5

[PATCH 2/5] hw/ppc/pnv_xscom: PBA bar mask values are incorrect with homer/occ sizes

[Balamuruhan S]

homer/occ sizes are calculated in skiboot with `(mask | 0xf) + 1`,
and from xscom access should return correct mask values instead of actual
sizes.

Signed-off-by: Cédric Le Goater 
Signed-off-by: Balamuruhan S 
---
 hw/ppc/pnv_xscom.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/hw/ppc/pnv_xscom.c b/hw/ppc/pnv_xscom.c
index f01d788a65..cdd5fa356e 100644
--- a/hw/ppc/pnv_xscom.c
+++ b/hw/ppc/pnv_xscom.c
@@ -46,6 +46,10 @@
 #define P9_PBA_BARMASK0 0x5012b04
 #define P9_PBA_BARMASK2 0x5012b06
 
+/* Mask to calculate Homer/Occ size */
+#define HOMER_SIZE_MASK 0x0030ull
+#define OCC_SIZE_MASK   0x0070ull
+
 static void xscom_complete(CPUState *cs, uint64_t hmer_bits)
 {
 /*
@@ -90,9 +94,8 @@ static uint64_t xscom_read_default(PnvChip *chip, uint32_t 
pcba)
 return PNV_HOMER_BASE(chip);
 
 case P9_PBA_BARMASK0: /* P9 homer region size */
-return PNV9_HOMER_SIZE;
 case P8_PBA_BARMASK0: /* P8 homer region size */
-return PNV_HOMER_SIZE;
+return HOMER_SIZE_MASK;
 
 case P9_PBA_BAR2: /* P9 occ common area */
 return PNV9_OCC_COMMON_AREA(chip);
@@ -100,9 +103,8 @@ static uint64_t xscom_read_default(PnvChip *chip, uint32_t 
pcba)
 return PNV_OCC_COMMON_AREA(chip);
 
 case P9_PBA_BARMASK2: /* P9 occ common area size */
-return PNV9_OCC_COMMON_AREA_SIZE;
 case P8_PBA_BARMASK2: /* P8 occ common area size */
-return PNV_OCC_COMMON_AREA_SIZE;
+return OCC_SIZE_MASK;
 
 case 0x1010c00: /* PIBAM FIR */
 case 0x1010c03: /* PIBAM FIR MASK */
-- 
2.14.5

[PATCH 5/5] hw/ppc/pnv_xscom: add PBA BARs for Power8 slw image

[Balamuruhan S]

slw base and size mask are accessed during boot in homer_init_chip(),
so include BAR2 and BARMASK2 for Power8.

Signed-off-by: Balamuruhan S 
---
 hw/ppc/pnv_xscom.c   | 10 --
 include/hw/ppc/pnv.h |  4 
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/hw/ppc/pnv_xscom.c b/hw/ppc/pnv_xscom.c
index f797a5ec7d..828a2e2a5a 100644
--- a/hw/ppc/pnv_xscom.c
+++ b/hw/ppc/pnv_xscom.c
@@ -38,8 +38,10 @@
 
 /* PBA BARs */
 #define P8_PBA_BAR0 0x2013f00
+#define P8_PBA_BAR2 0x2013f02
 #define P8_PBA_BAR3 0x2013f03
 #define P8_PBA_BARMASK0 0x2013f04
+#define P8_PBA_BARMASK2 0x2013f06
 #define P8_PBA_BARMASK3 0x2013f07
 #define P9_PBA_BAR0 0x5012b00
 #define P9_PBA_BAR2 0x5012b02
@@ -49,6 +51,7 @@
 /* Mask to calculate Homer/Occ size */
 #define HOMER_SIZE_MASK 0x0030ull
 #define OCC_SIZE_MASK   0x0070ull
+#define SLW_SIZE_MASK   0x0
 
 static void xscom_complete(CPUState *cs, uint64_t hmer_bits)
 {
@@ -115,6 +118,11 @@ static uint64_t xscom_read_default(PnvChip *chip, uint32_t 
pcba)
 }
 return 0;
 
+case P8_PBA_BAR2: /* P8 slw image */
+return PNV_SLW_IMAGE_BASE(chip);
+case P8_PBA_BARMASK2: /* P8 slw image size is 1MB and mask is zero*/
+return SLW_SIZE_MASK;
+
 case 0x1010c00: /* PIBAM FIR */
 case 0x1010c03: /* PIBAM FIR MASK */
 
@@ -135,9 +143,7 @@ static uint64_t xscom_read_default(PnvChip *chip, uint32_t 
pcba)
 case 0x202000f: /* ADU stuff, receive status register*/
 return 0;
 case 0x2013f01: /* PBA stuff */
-case 0x2013f02: /* PBA stuff */
 case 0x2013f05: /* PBA stuff */
-case 0x2013f06: /* PBA stuff */
 return 0;
 case 0x2013028: /* CAPP stuff */
 case 0x201302a: /* CAPP stuff */
diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
index e9ed8b928a..bd22dbf8a9 100644
--- a/include/hw/ppc/pnv.h
+++ b/include/hw/ppc/pnv.h
@@ -212,6 +212,10 @@ void pnv_bmc_powerdown(IPMIBmc *bmc);
 #define PNV_HOMER_BASE(chip)\
 (0x7ffd80ull + ((uint64_t)PNV_CHIP_INDEX(chip)) * PNV_HOMER_SIZE)
 
+#define PNV_SLW_SIZE0x0010ull
+#define PNV_SLW_IMAGE_BASE(chip)\
+(0x2ffda0ull + ((uint64_t)PNV_CHIP_INDEX(chip)) * PNV_SLW_SIZE)
+
 
 /*
  * XSCOM 0x20109CA defines the ICP BAR:
-- 
2.14.5

Re: [PATCH 2/6] iotests: Skip test 079 if it is not possible to create large files

[Daniel P . Berrangé]

On Tue, Nov 19, 2019 at 06:38:20PM +0100, Philippe Mathieu-Daudé wrote:
> On 11/19/19 6:34 PM, Thomas Huth wrote:
> > On 19/11/2019 18.29, Philippe Mathieu-Daudé wrote:
> > > On 11/19/19 6:08 PM, Thomas Huth wrote:
> > > > Test 079 fails in the arm64, s390x and ppc64le LXD containers, which
> > > > apparently do not allow large files to be created. Test 079 tries to
> > > > create a 4G sparse file, so check first whether we can really create
> > > > such files before executing the test.
> > > > 
> > > > Signed-off-by: Thomas Huth 
> > > > ---
> > > >    tests/qemu-iotests/079 | 6 ++
> > > >    1 file changed, 6 insertions(+)
> > > > 
> > > > diff --git a/tests/qemu-iotests/079 b/tests/qemu-iotests/079
> > > > index 81f0c21f53..e9b81419b7 100755
> > > > --- a/tests/qemu-iotests/079
> > > > +++ b/tests/qemu-iotests/079
> > > > @@ -39,6 +39,12 @@ trap "_cleanup; exit \$status" 0 1 2 3 15
> > > >    _supported_fmt qcow2
> > > >    _supported_proto file nfs
> > > >    +# Some containers (e.g. non-x86 on Travis) do not allow large files
> > > > +if ! truncate --size=4G "$TEST_IMG"; then
> > > 
> > > Shouldn't we restrict that to Travis-CI by checking some environment var?
> > 
> > I'd rather like to keep it independent from Travis environment
> > variables, since somebody might want to run "make check" in other
> > non-Travis containers or on weird filesystems, and then the test should
> > ideally not fail, but simply skip, too.
> 
> I see. But it would be bad if we stop catching normal bugs with this test
> because we restricted it to contained environments.
> 
> Maybe we can add a generic is_contained() routine that only checks for
> TRAVIS env var, and people using other containers can expand it.

"is_contained" is still expressing the environment.

What we need is a way to express features, and be able to switch beteen
autodetecting features & mandatory enablement.

eg

   if has_feature "large_file"
   then
   ...stuff using large files...
   fi

The "has_feature" helper would by default call out to
"has_feature_large_file" todo automatic probing so that things
"just work" according to whatever env the tests are run inside.

There should, however, be a flag to "./check" which force enables
the feature eg  "./check --require-feature large_file" will force
execution and not attempt to probe for it.

We could have "--require-feature :all" to force enable all optional
bits.

Any formal CI systems should use --require-feature to explicitly
force testing of features that are expected to always work.

so Travis x86 would use "--require-feature large_large", but
the arch64 version would not pass this flag and so do probing
which will auto-skip.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

[PATCH 0/5] ppc/pnv: fix Homer/Occ mappings on multichip systems

[Balamuruhan S]

Hi All,

PowerNV fails to boot in multichip systems due to some misinterpretation
and mapping in Homer/Occ device models, this patchset fixes the
following,

 - Homer size is 4MB per chip and Occ common area size is 8MB
 - Bar masks are used to calculate sizes of Homer/Occ in skiboot so
   return appropriate value
 - Occ common area is in BAR 3 on Power8 but wrongly mapped to BAR 2
   currently
 - OCC common area is shared across chips and should be mapped only once
   for multichip systems

Request for your review and suggestions to make it better. I would like to
thank Cedric for his time and help to figure out the issues.

Balamuruhan S (5):
  hw/ppc/pnv: incorrect homer and occ common area size
  hw/ppc/pnv_xscom: PBA bar mask values are incorrect with homer/occ
sizes
  hw/ppc/pnv_xscom: Power8 occ common area is in PBA BAR 3
  hw/ppc/pnv_xscom: occ common area to be mapped only once
  hw/ppc/pnv_xscom: add PBA BARs for Power8 slw image

 hw/ppc/pnv_occ.c |  2 +-
 hw/ppc/pnv_xscom.c   | 37 +++--
 include/hw/ppc/pnv.h | 12 
 3 files changed, 36 insertions(+), 15 deletions(-)

-- 
2.14.5

[Bug 1844817] Re: trace: dynamic width format syntax not validated

[Philippe Mathieu-Daudé]

** Changed in: qemu
   Status: New => Fix Committed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1844817

Title:
  trace: dynamic width format syntax not validated

Status in QEMU:
  Fix Committed

Bug description:
  The dtrace via stap backend cannot support the dynamic '*' width
  format.

  Eric noted in https://lists.gnu.org/archive/html/qemu-
  devel/2019-09/msg04720.html:

https://sourceware.org/systemtap/langref.pdf

section 9.2 printf, states:

"The printf formatting directives are similar to those of C, except that
they are fully checked for type by the translator."

and does NOT list handling for '*' under precision or width.

  Some trace events have been merged without checking this:

  $ git ls-files|fgrep trace-event|xargs git grep '*\("\|x\)'
  hw/block/trace-events:11:pflash_io_read(uint64_t offset, int width, int 
fmt_width, uint32_t value, uint8_t cmd, uint8_t wcycle) "offset:0x%04"PRIx64" 
width:%d value:0x%0*x cmd:0x%02x wcycle:%u"
  hw/block/trace-events:12:pflash_io_write(uint64_t offset, int width, int 
fmt_width, uint32_t value, uint8_t wcycle) "offset:0x%04"PRIx64" width:%d 
value:0x%0*x wcycle:%u"
  hw/block/trace-events:13:pflash_data_read(uint64_t offset, int width, 
uint32_t value) "data offset:0x%04"PRIx64" value:0x%0*x"
  hw/block/trace-events:14:pflash_data_write(uint64_t offset, int width, 
uint32_t value, uint64_t counter) "data offset:0x%04"PRIx64" value:0x%0*x 
counter:0x%016"PRIx64
  hw/mips/trace-events:2:gt64120_read(const char *regname, int width, uint64_t 
value) "gt64120 read %s value:0x%0*" PRIx64
  hw/mips/trace-events:3:gt64120_write(const char *regname, int width, uint64_t 
value) "gt64120 write %s value:0x%0*" PRIx64

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1844817/+subscriptions

Re: [PATCH 2/6] iotests: Skip test 079 if it is not possible to create large files

[Philippe Mathieu-Daudé]

On 11/19/19 6:34 PM, Thomas Huth wrote:

On 19/11/2019 18.29, Philippe Mathieu-Daudé wrote:

On 11/19/19 6:08 PM, Thomas Huth wrote:

Test 079 fails in the arm64, s390x and ppc64le LXD containers, which
apparently do not allow large files to be created. Test 079 tries to
create a 4G sparse file, so check first whether we can really create
such files before executing the test.

Signed-off-by: Thomas Huth 
---
   tests/qemu-iotests/079 | 6 ++
   1 file changed, 6 insertions(+)

diff --git a/tests/qemu-iotests/079 b/tests/qemu-iotests/079
index 81f0c21f53..e9b81419b7 100755
--- a/tests/qemu-iotests/079
+++ b/tests/qemu-iotests/079
@@ -39,6 +39,12 @@ trap "_cleanup; exit \$status" 0 1 2 3 15
   _supported_fmt qcow2
   _supported_proto file nfs
   +# Some containers (e.g. non-x86 on Travis) do not allow large files
+if ! truncate --size=4G "$TEST_IMG"; then


Shouldn't we restrict that to Travis-CI by checking some environment var?


I'd rather like to keep it independent from Travis environment
variables, since somebody might want to run "make check" in other
non-Travis containers or on weird filesystems, and then the test should
ideally not fail, but simply skip, too.


I see. But it would be bad if we stop catching normal bugs with this 
test because we restricted it to contained environments.


Maybe we can add a generic is_contained() routine that only checks for 
TRAVIS env var, and people using other containers can expand it.

Re: [PATCH] Add minimal Hexagon target - First in a series of patches - linux-user changes + linux-user/hexagon + skeleton of target/hexagon - Files in target/hexagon/imported are from another project

[Peter Maydell]

On Tue, 19 Nov 2019 at 17:23, Taylor Simpson  wrote:
> - Laurent suggested I split the patch into two parts: linux-user and 
> target/hexagon.  If I do that, which one should contain the changes to common 
> files (e.g., configure)?  Also, note that we won't be able to build until 
> both patches are merged.  Is that OK?

Rule of thumb -- patches should generally be 200 lines
or less (less is good!), with exceptions where something
is very mechanical/repetitive and there's no point
splitting it up (eg there's no need to have the new
syscall_nr.h additions split into multiple patches).
Judging purely by the "2184 insertions" summary you
should probably be looking to split this into somewhere
between 5 and 10 patches, where each patch is a coherent
chunk with a commit message describing it.

Typically a new port is a complete patchset consisting
of multiple patches which are intended to be applied in
sequence. (They should be sent to the mailing list so
they appear as a cover letter plus a set of patch
emails each of which is a follow-up/reply to the cover
letter. git-send-email can do this kind of thing for you.)

The requirement for a patch series like that is that
at each intermediate point QEMU should still build
and pass 'make check'; but the new port will obviously
not be completely functional until all the parts are
present. You can probably look at how the initial
commits for various other recent ports were structured
to see the general idea.

thanks
-- PMM

Re: [PATCH 2/6] iotests: Skip test 079 if it is not possible to create large files

[Thomas Huth]

On 19/11/2019 18.29, Philippe Mathieu-Daudé wrote:
> On 11/19/19 6:08 PM, Thomas Huth wrote:
>> Test 079 fails in the arm64, s390x and ppc64le LXD containers, which
>> apparently do not allow large files to be created. Test 079 tries to
>> create a 4G sparse file, so check first whether we can really create
>> such files before executing the test.
>>
>> Signed-off-by: Thomas Huth 
>> ---
>>   tests/qemu-iotests/079 | 6 ++
>>   1 file changed, 6 insertions(+)
>>
>> diff --git a/tests/qemu-iotests/079 b/tests/qemu-iotests/079
>> index 81f0c21f53..e9b81419b7 100755
>> --- a/tests/qemu-iotests/079
>> +++ b/tests/qemu-iotests/079
>> @@ -39,6 +39,12 @@ trap "_cleanup; exit \$status" 0 1 2 3 15
>>   _supported_fmt qcow2
>>   _supported_proto file nfs
>>   +# Some containers (e.g. non-x86 on Travis) do not allow large files
>> +if ! truncate --size=4G "$TEST_IMG"; then
> 
> Shouldn't we restrict that to Travis-CI by checking some environment var?

I'd rather like to keep it independent from Travis environment
variables, since somebody might want to run "make check" in other
non-Travis containers or on weird filesystems, and then the test should
ideally not fail, but simply skip, too.

 Thomas

Re: [PATCH 4/6] tests/test-util-filemonitor: Skip test on non-x86 Travis containers

[Philippe Mathieu-Daudé]

On 11/19/19 6:08 PM, Thomas Huth wrote:

test-util-filemonitor fails in restricted non-x86 Travis containers
since they apparently blacklisted some required system calls there.
Let's simply skip the test if we detect such an environment.

Signed-off-by: Thomas Huth 
---
  tests/test-util-filemonitor.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/tests/test-util-filemonitor.c b/tests/test-util-filemonitor.c
index 301cd2db61..45009c69f4 100644
--- a/tests/test-util-filemonitor.c
+++ b/tests/test-util-filemonitor.c
@@ -406,10 +406,21 @@ test_file_monitor_events(void)
  char *pathdst = NULL;
  QFileMonitorTestData data;
  GHashTable *ids = g_hash_table_new(g_int64_hash, g_int64_equal);
+char *travis_arch;
  
  qemu_mutex_init();

  data.records = NULL;
  
+/*

+ * This test does not work on Travis LXD containers since some
+ * syscalls are blocked in that environment.
+ */
+travis_arch = getenv("TRAVIS_ARCH");
+if (travis_arch && !g_str_equal(travis_arch, "x86_64")) {
+g_test_skip("Test does not work on non-x86 Travis containers.");


We might need to refactor this hunk to a more generic place some day.

Reviewed-by: Philippe Mathieu-Daudé 


+return;
+}
+
  /*
   * The file monitor needs the main loop running in
   * order to receive events from inotify. We must