Re: [Qemu-devel] Converting host virtual addresses to guest physical

[Stefan Hajnoczi]

On Thu, Sep 07, 2017 at 01:02:59PM +, Padmanabhan S N via Qemu-devel wrote:
> I'm developing a new block backend driver. Since my Guest RAM is coming out 
> of shared memory (memory-backend-file,mem-path=/dev/shmem/foo), while 
> performing the IO I would like to pass QEMUIOVector buffers directly to 
> another user-space process running on the same host to enable zerocopy. Can 
> someone help me understand the different memory regions that are mapped in 
> the qemu process address space and how they map to each other ?
> 1. My guest is configured with 1G RAM. /proc//maps on the qemu process 
> shows two 1G regions that are mapped. One of them is /dev/shmem/foo, which I 
> believe corresponds to the guest physical memory. What is the other 1G region 
> ? 
> 2. The QEMUIOVector buffers point to this 'other' 1G region that I referred 
> above. How do I convert these pointers to locations in the /dev/shmem/foo 
> region ? My plan is to convert the QEMUIOVector buffer pointer to a region in 
> /dev/shmem/foo and pass that pointer to another userspace process that also 
> has the /dev/shmem/foo region mapped.

Please post the full QEMU command-line and /proc//maps.

> I understand vhost-user might be the right way to approach this problem. 
> However I'm currently working with qemu-2.8 and it looks neither 
> vhost-user-scsi nor vhost-user-blk are available in that version. If you 
> believe there is a better approach to solve this problem, let me know.

Are you sure that QEMU 2.8 will still be relevant by the time your block
driver is production-ready?

Stefan

Re: [Qemu-devel] [PATCH v7 33/38] libqtest: Merge qtest_{in, out}[bwl]() with {in, out}[bwl]()

[Thomas Huth]

On 11.09.2017 19:20, Eric Blake wrote:
> Maintaining two layers of libqtest APIs, one that takes an explicit
> QTestState object, and the other that uses the implicit global_qtest,
> is annoying.  In the interest of getting rid of global implicit
> state and having less code to maintain, merge:
>  qtest_outb()
>  qtest_outw()
>  qtest_outl()
>  qtest_inb()
>  qtest_inw()
>  qtest_inl()
> with their short counterparts.  All callers that previously
> used the short form now make it explicit that they are relying on
> global_qtest, and later patches can then clean things up to remove
> the global variable.
> 
> Signed-off-by: Eric Blake 
> ---
>  tests/libqtest.h| 99 
> ++---
>  tests/multiboot/libc.h  |  2 +-
>  tests/libqtest.c| 14 +++
>  tests/boot-order-test.c |  4 +-
>  tests/endianness-test.c | 12 +++---
>  tests/fdc-test.c| 77 --
>  tests/hd-geo-test.c |  4 +-
>  tests/ipmi-bt-test.c| 12 +++---
>  tests/ipmi-kcs-test.c   |  8 ++--
>  tests/libqos/fw_cfg.c   |  4 +-
>  tests/libqos/pci-pc.c   | 44 +++---
>  tests/libqos/pci.c  |  2 +-
>  tests/m48t59-test.c |  8 ++--
>  tests/multiboot/libc.c  |  2 +-
>  tests/pvpanic-test.c|  4 +-
>  tests/rtc-test.c|  8 ++--
>  tests/wdt_ib700-test.c  |  8 ++--
>  17 files changed, 120 insertions(+), 192 deletions(-)
> 
> diff --git a/tests/libqtest.h b/tests/libqtest.h
> index 8398c0fd07..520f745e7b 100644
> --- a/tests/libqtest.h
> +++ b/tests/libqtest.h
> @@ -205,61 +205,61 @@ void irq_intercept_in(QTestState *s, const char 
> *string);
>  void irq_intercept_out(QTestState *s, const char *string);
> 
>  /**
> - * qtest_outb:
> + * outb:
>   * @s: #QTestState instance to operate on.
>   * @addr: I/O port to write to.
>   * @value: Value being written.
>   *
>   * Write an 8-bit value to an I/O port.
>   */
> -void qtest_outb(QTestState *s, uint16_t addr, uint8_t value);
> +void outb(QTestState *s, uint16_t addr, uint8_t value);

Could we please also keep the qtest prefix here? ... same applies for
all your other following "Merge ..." patches in this series...

 Thomas

Re: [Qemu-devel] Suggested Wiki Update

[Thomas Huth]

On 12.09.2017 13:18, Cornelia Huck wrote:
> On Tue, 12 Sep 2017 10:57:14 +0200
> Viktor Mihajlovski  wrote:
> 
>> Hi,
>>
>> the content of https://wiki.qemu.org/index.php/Features/S390xNetworkBoot
>> is slightly outdated since proper DHCP based netboot support for s390x
>> has been implemented by the series ending with commit 29d1221.
>>
>> As it is still desirable to provide some instructions on building
>> network bootable images for the s390x architecture, I'd like to suggest
>> that the text is replaced (see proposal below). Conny, could I once more
>> request your help in that matter?
>>
>> == Building a s390 network bootable binary ==
>>
>> Since 2.10 QEMU offers network boot support which allows to load a
>> binary from a TFTP server and boot it. As s390 network bootable images
>> are not very common, this document gives a brief overview on how to
>> build one.
>>
>> A s390 network bootable image can be built by bundling some shell
>> scripts, busybox and the kexec binary bundled into an initial ramdisk
>> and append that to a kernel image. An existing s390 system can be used
>> as source.
>>
>> One way to do that is to take a kernel and an installer initial ramdisk
>> from a distribution's DVD/ISO and concatenate them. Some fixups are
>> necessary int the new binary, which can be done by using the script in
>> [https://github.com/ibm-s390-tools/s390-tools/blob/master/netboot/mk-s390image].
>> Booting this image would then start the installation process as if
>> booted from the DVD.
>>
>> Another possible way is to build a binary that behaves similar to the
>> PXELINUX boot loader. In this case an initial ramdisk with an init
>> process triggering the PXELINUX-like processing has to be built as
>> described in
>> [https://github.com/ibm-s390-tools/s390-tools/tree/master/netboot]. The
>> site also contains a script assisting in the creation of such an initial
>> ramdisk.
>>
> 
> Looks good.
> 
> Can you perhaps add a sentence that the base support is available with
> 2.9 and netboot with 2.10? ('Overview' looks like a good place for
> that.)

FWIW, I think it would also be good to add a sentence about the need to
specify "bootindex" somewhere (I remember trying to use "-boot n" the
first time I wanted to use it) ...

 Thomas

Re: [Qemu-devel] [PATCH for-2.10] qemu-options: Document the -drive locking parameter.

[Kevin Wolf]

Am 12.09.2017 um 11:45 hat Richard W.M. Jones geschrieben:
> On Wed, Sep 06, 2017 at 01:38:45PM +0200, Kevin Wolf wrote:
> > This command line fragment looks correct to me. For me, it seems to
> > work. I'm starting a first qemu in the background with default locking
> > options:
> > 
> > $ x86_64-softmmu/qemu-system-x86_64 -hda /tmp/test.qcow2
> > 
> > And then starting a second one with a command line resembling yours:
> > 
> > $ x86_64-softmmu/qemu-system-x86_64 -device virtio-scsi \
> >   -drive 
> > file=/tmp/test.qcow2,cache=unsafe,format=qcow2,file.locking=off,id=hd0,if=none
> >  \
> >   -device scsi-hd,drive=hd0
> 
> The problem is with overlays, where file.locking doesn't propagate to
> the backing file.  Thus:
> 
>   $ qemu-system-x86_64 -drive file=backing,format=raw
> 
> while in another terminal:
> 
>   $ qemu-img create -b backing -f qcow2 overlay
>   $ qemu-system-x86_64 -drive file=overlay,format=qcow2,file.locking=off
>   qemu-system-x86_64: Failed to get shared "write" lock
>   Is another process using the image?

locking=off isn't the right tool for the case. Try this:

$ qemu-system-x86_64 -drive file=overlay,if=none -device 
virtio-blk-pci,drive=none0,share-rw=on

Unless you're doing really evil things, just telling qemu that your
guest can cope with concurrent writers to the same image is enough. This
propagates through the whole chain as appropriate.

Kevin

Re: [Qemu-devel] question： I found a bug which will lead to qemu crash

[Kevin Wolf]

Am 12.09.2017 um 13:17 hat WangJie (Captain) geschrieben:
> Hi, Kevin.
> 
> I found a bug about qemu-kvm(version 2.7.0-rc0 adn 2.8.1). but qemu 2.6.0 and 
> current master is OK.
> So I git-bisect the master branch，and I found the patch you commited (block: 
> Decouple throttling from BlockDriverState) lead the bug into qemu.
> 
> The patch which lead the bug into qemu: 
> (https://github.com/qemu/qemu/commit/7ca7f0f6db1fedd28d490795d778cf23979a2aa7#diff-ea36ba0f79150cc299732696a069caba)
> 
> Because the current master is OK. So I think you had fixed it , can you tell 
> me which patch fixed the bug?Thank you :>

I can't tell offhand which fix this was, but you can use 'git bisect'
not only to find which commit introduced the bug, but also to find the
fix. You just bisect between a broken commit and master, and then use
the reversed meaning of 'good' and 'bad' (i.e. 'good' means that the bug
is still there, 'bad' means it is already fixed).

Kevin

[Qemu-devel] [Bug 1135567] Re: QXL crashes a Windows 7 guest if host goes into screensaver

[Philosophish]

Hello,

Obviously my hardware configuration and versions etc. have changed.

Also, I have taken to not using screensavers in the virtual machines
anymore i.e. disabled.

BUT: I have set it up as similarly as possible and the crash/freeze/hang
up with current versions of the drivers seems to be gone.

So I guess the ticket can be closed.

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

Title:
  QXL crashes a Windows 7 guest if host goes into screensaver

Status in QEMU:
  Incomplete

Bug description:
  Note: if further information is required, I'll be glad to supply it.

  I am using on the host
  - HP z800 with 72GB RAM and 2x x5680
  - Gentoo 64-bit host (3.7.9 kernel, FGLRX RADEON driver 13.1)
  - LIBVIRT 1.0.2 with QEMU(-KVM) 1.4.0

  The guest:
  - Windows 7 32-bit
  - 2GB allocated
  - 2 CPU
  - using virtio for everything (disk,net,memballoon)
  - Display = SPICE with spice channel
  - Video driver is qxl (ram says 64MB)
  - Spice-guest-tools 0.52 installed

  When I use QXL and  have the guest open in Virt-Manager/Virt-Viewer
  and let the host go into screensaver mode, the Win7 crashes hard.

  When I change video to VGA, it survives the screen saver,  no problem
  at all ,smooth sailing.

  regards

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

Re: [Qemu-devel] [PATCH] dump: do not dump non-existent guest memory

[Marc-André Lureau]

Hi Peter

On Tue, Sep 12, 2017 at 5:33 AM, Peter Xu  wrote:
> On Mon, Sep 11, 2017 at 03:26:27PM +0200, Cornelia Huck wrote:
>> It does not really make sense to dump memory that is not there.
>>
>> Moreover, that fixes a segmentation fault when calling dump-guest-memory
>> with no filter for a machine with no memory defined.
>>
>> New behaviour is:
>>
>> (qemu) dump-guest-memory /dev/null
>> dump: no guest memory to dump
>> (qemu) dump-guest-memory /dev/null 0 4096
>> dump: no guest memory to dump
>>
>> Signed-off-by: Cornelia Huck 
>> ---
>>
>> Another unmaintained file. Joy. cc:ing some more-or-less random folks.
>
> I thought Marc-André had proposed to be the maintainer? But indeed I
> didn't see the line in maintainer file.
>
> Anyway, if anyone think I am ok to maintain this single file
> (considering that I haven't posted patches on it for 2 years, and I
> haven't been working on any kind of maintainer job), please let me
> know. I'm glad to start with it (or with Marc-André).
>

That would be great!
thanks



-- 
Marc-André Lureau

Re: [Qemu-devel] [PATCH v7 29/38] libqtest: Merge qtest_init() into qtest_start()

[Thomas Huth]

On 11.09.2017 19:20, Eric Blake wrote:
> Remove the trivial wrapper qtest_init(), and change qtest_start()
> to no longer implicitly set global_qtest, to make it obvious in the
> rest of the testsuite where we are still relying on global_qtest.
> Everything now uses qtest_start() (and friends) and qtest_quit(),
> and explicitly tracks the QTestState between the two (although in
> many cases, this tracking is still done through global_qtest).
> Doing this makes it easier to see what remaining cleanups will be
> needed if we don't want an implicit dependency on global state.
[...]
> diff --git a/tests/libqtest.h b/tests/libqtest.h
> index 817e3a5580..2a21bf4605 100644
> --- a/tests/libqtest.h
> +++ b/tests/libqtest.h
> @@ -27,7 +27,7 @@ extern QTestState *global_qtest;
>   * qtest_start_without_qmp_handshake:
>   * @extra_args: other arguments to pass to QEMU.
>   *
> - * Returns: #QTestState instance.  Does not affect #global_qtest.
> + * Returns: #QTestState instance, handshaking not yet completed.

I'd rather add a description a la:

  * Start QEMU, but do not execute the QMP handshake yet.
  *
  * Returns: #QTestState instance

>   */
>  QTestState *qtest_start_without_qmp_handshake(const char *extra_args);
> 
> @@ -35,10 +35,7 @@ QTestState *qtest_start_without_qmp_handshake(const char 
> *extra_args);
>   * qtest_start:
>   * @args: other arguments to pass to QEMU
>   *
> - * Start QEMU and assign the resulting #QTestState to #global_qtest.
> - * The global variable is used by "shortcut" functions documented below.
>   *
> - * Returns: #QTestState instance.
> + * Returns: #QTestState instance, handshaking completed.

I'd rather change the description instead of removing it:

  * Start QEMU and execute the initial QMP handshake
  *
  * Returns: #QTestState instance.

>   */
>  QTestState *qtest_start(const char *args);
> 
> @@ -47,10 +44,7 @@ QTestState *qtest_start(const char *args);
>   * @fmt...: Format for creating other arguments to pass to QEMU, formatted
>   * like sprintf().
>   *
> - * Start QEMU and return the resulting #QTestState (but unlike qtest_start(),
> - * #global_qtest is left at NULL).
> - *
> - * Returns: #QTestState instance.
> + * Returns: #QTestState instance, handshaking completed.

dito

>   */
>  QTestState *qtest_startf(const char *fmt, ...) GCC_FMT_ATTR(1, 2);
> 
> @@ -60,30 +54,11 @@ QTestState *qtest_startf(const char *fmt, ...) 
> GCC_FMT_ATTR(1, 2);
>   * like vsprintf().
>   * @ap: Format arguments.
>   *
> - * Start QEMU and return the resulting #QTestState (but unlike qtest_start(),
> - * #global_qtest is left at NULL).
> - *
> - * Returns: #QTestState instance.
> + * Returns: #QTestState instance, handshaking completed.

dito

>   */
>  QTestState *qtest_vstartf(const char *fmt, va_list ap) GCC_FMT_ATTR(1, 0);
> 
>  /**
> - * qtest_init:
> - * @extra_args: other arguments to pass to QEMU.
> - *
> - * Returns: #QTestState instance.  Does not affect #global_qtest.
> - */
> -static inline QTestState *qtest_init(const char *extra_args)
> -{
> -QTestState *s;
> -
> -assert(!global_qtest);
> -s = qtest_start(extra_args);
> -global_qtest = NULL;
> -return s;
> -}
[...]
> diff --git a/tests/display-vga-test.c b/tests/display-vga-test.c
> index 8667330e3c..d638f15ec3 100644
> --- a/tests/display-vga-test.c
> +++ b/tests/display-vga-test.c
> @@ -12,39 +12,33 @@
> 
>  static void pci_cirrus(void)
>  {
> -qtest_start("-vga none -device cirrus-vga");
> -qtest_quit(global_qtest);
> +qtest_quit(qtest_start("-vga none -device cirrus-vga"));

I'd prefer to keep this on separate lines ... but that's again just my
personal taste. (also for the othe changes below)

>  }
> 
>  static void pci_stdvga(void)
>  {
> -qtest_start("-vga none -device VGA");
> -qtest_quit(global_qtest);
> +qtest_quit(qtest_start("-vga none -device VGA"));
>  }
> 
>  static void pci_secondary(void)
>  {
> -qtest_start("-vga none -device secondary-vga");
> -qtest_quit(global_qtest);
> +qtest_quit(qtest_start("-vga none -device secondary-vga"));
>  }
> 
>  static void pci_multihead(void)
>  {
> -qtest_start("-vga none -device VGA -device secondary-vga");
> -qtest_quit(global_qtest);
> +qtest_quit(qtest_start("-vga none -device VGA -device secondary-vga"));
>  }
> 
>  static void pci_virtio_gpu(void)
>  {
> -qtest_start("-vga none -device virtio-gpu-pci");
> -qtest_quit(global_qtest);
> +qtest_quit(qtest_start("-vga none -device virtio-gpu-pci"));
>  }
> 
>  #ifdef CONFIG_VIRTIO_VGA
>  static void pci_virtio_vga(void)
>  {
> -qtest_start("-vga none -device virtio-vga");
> -qtest_quit(global_qtest);
> +qtest_quit(qtest_start("-vga none -device virtio-vga"));
>  }
>  #endif
[...]
> diff --git a/tests/ne2000-test.c b/tests/ne2000-test.c
> index cae83c5c4c..8e6f7b07c6 100644
> --- a/tests/ne2000-test.c
> +++ b/tests/ne2000-test.c
> @@ -22,7 +22,7 @@ int main(int argc, char **argv)
>  g_test_init(, , NULL);
>  

Re: [Qemu-devel] [PATCH 6/6] arm: drop intermadiate cpu_model -> cpu type parsing and use cpu type directly

[Igor Mammedov]

On Tue, 5 Sep 2017 19:12:26 -0300
Eduardo Habkost  wrote:

> On Tue, Sep 05, 2017 at 02:47:52PM -0700, Alistair Francis wrote:
> > On Tue, Sep 5, 2017 at 2:31 PM, Eduardo Habkost  
> > wrote:  
> [...]
> > >> diff --git a/hw/arm/stm32f205_soc.c b/hw/arm/stm32f205_soc.c
> > >> index f61e735..1cd6374 100644
> > >> --- a/hw/arm/stm32f205_soc.c
> > >> +++ b/hw/arm/stm32f205_soc.c
> > >> @@ -112,7 +112,7 @@ static void stm32f205_soc_realize(DeviceState 
> > >> *dev_soc, Error **errp)
> > >>
> > >>  armv7m = DEVICE(>armv7m);
> > >>  qdev_prop_set_uint32(armv7m, "num-irq", 96);
> > >> -qdev_prop_set_string(armv7m, "cpu-model", s->cpu_model);
> > >> +qdev_prop_set_string(armv7m, "cpu-type", s->cpu_type);
> > >>  object_property_set_link(OBJECT(>armv7m), 
> > >> OBJECT(get_system_memory()),
> > >>   "memory", _abort);
> > >>  object_property_set_bool(OBJECT(>armv7m), true, "realized", 
> > >> );
> > >> @@ -200,7 +200,7 @@ static void stm32f205_soc_realize(DeviceState 
> > >> *dev_soc, Error **errp)
> > >>  }
> > >>
> > >>  static Property stm32f205_soc_properties[] = {
> > >> -DEFINE_PROP_STRING("cpu-model", STM32F205State, cpu_model),
> > >> +DEFINE_PROP_STRING("cpu-type", STM32F205State, cpu_type),  
> > >
> > > Same as armv7m: are we 100% sure users are not setting this
> > > manually?  
> > 
> > In an embedded board like this it really doesn't make sense to let the
> > user overwrite the CPU. The SoC will take it as an option, but the
> > board (which creates the SoC) just blindly always uses the same CPU.
> > That feature is more for QOMificatoion then any real reason though.
> >   
> 
> I'm not talking about -cpu (no user-visible change in the
> handling of -cpu should result from this patch), but about
> possible cases where the user set the "cpu-model" property using
> another mechanism, like -global.  Probably it's impossible for an
> user to override the property successfully, but I would like to
> be sure.
> 
> 
> > In saying that I think a warning if the user tries to set the CPU
> > would make sense. I know that this issues comes up in other ARM boards
> > (Zynq-7000 has the same issue as well) so maybe a machine property
> > saying that the board doesn't accept custom CPUs would be a good idea.
Agreed, it would be useful, however goal of the patch to drop
cpu_generic_init() preferably without changing behavior

so I'd leave extra stuff you mention upto board maintainers
to fix up on top.


> Yeah, there are multiple cases in this patch where boards are
> validating the CPU model, but not all boards do that.  A generic
> MachineClass::valid_cpu_types[] field would be useful.
so far I've met 3 use cases for valid_cpu_types
 * no check - just try to use whatever user provided
 * check for concrete cpu models (leaf classes)
 * check for super-class based in partial cpu_model match

it is nice to have valid_cpu_types[] /I recall even trying out something 
similar/
but then series turns into mess where one tries to fix several things
and on top of it in all targets, hence I've decided first to get rid of
all cpu_model handling in boards and only then think about valid_cpus using cpu 
types.

I'd gladly give up 'valid cpus' to someone else more interested in it,
there are other users beside of ARM boards for it.
/seems Alistair is interested in it, at least in ARM part/


> > Overall I think this patch is moving in the right direction though and
> > this CPU option being ignored existed before this series.  
> 
> I agree this is going on the right direction.  However, I don't
> see any board that ignore the CPU option: all of them seem to use
> cpu_model when creating the CPUs, already.
in ARM case there are boards that use
 * '-cpu' provided model
 * '-cpu' provided model with valid cpu checks
 * 'hardcoded' cpu model ignoring '-cpu'/-global

I've thought commit message sufficiently described current situation and 
changes.

[Qemu-devel] [PATCH v3 5/7] block: convert crypto driver to bdrv_co_preadv|pwritev

[Daniel P. Berrange]

Make the crypto driver implement the bdrv_co_preadv|pwritev
callbacks, and also use bdrv_co_preadv|pwritev for I/O
with the protocol driver beneath.

Signed-off-by: Daniel P. Berrange 
---
 block/crypto.c | 104 +++--
 1 file changed, 56 insertions(+), 48 deletions(-)

diff --git a/block/crypto.c b/block/crypto.c
index 49d6d4c058..d004e9cef4 100644
--- a/block/crypto.c
+++ b/block/crypto.c
@@ -383,19 +383,23 @@ static void block_crypto_close(BlockDriverState *bs)
 #define BLOCK_CRYPTO_MAX_SECTORS 2048
 
 static coroutine_fn int
-block_crypto_co_readv(BlockDriverState *bs, int64_t sector_num,
-  int remaining_sectors, QEMUIOVector *qiov)
+block_crypto_co_preadv(BlockDriverState *bs, uint64_t offset, uint64_t bytes,
+   QEMUIOVector *qiov, int flags)
 {
 BlockCrypto *crypto = bs->opaque;
-int cur_nr_sectors; /* number of sectors in current iteration */
+uint64_t cur_bytes; /* number of bytes in current iteration */
 uint64_t bytes_done = 0;
 uint8_t *cipher_data = NULL;
 QEMUIOVector hd_qiov;
 int ret = 0;
 uint64_t sector_size = qcrypto_block_get_sector_size(crypto->block);
-uint64_t payload_offset =
-qcrypto_block_get_payload_offset(crypto->block) / sector_size;
-assert(payload_offset < (INT64_MAX / 512));
+size_t payload_offset = qcrypto_block_get_payload_offset(crypto->block);
+uint64_t sector_num = offset / sector_size;
+
+assert(!flags);
+assert(payload_offset < INT64_MAX);
+assert(QEMU_IS_ALIGNED(offset, sector_size));
+assert(QEMU_IS_ALIGNED(bytes, sector_size));
 
 qemu_iovec_init(_qiov, qiov->niov);
 
@@ -410,37 +414,33 @@ block_crypto_co_readv(BlockDriverState *bs, int64_t 
sector_num,
 goto cleanup;
 }
 
-while (remaining_sectors) {
-cur_nr_sectors = remaining_sectors;
+while (bytes) {
+cur_bytes = bytes;
 
-if (cur_nr_sectors > BLOCK_CRYPTO_MAX_SECTORS) {
-cur_nr_sectors = BLOCK_CRYPTO_MAX_SECTORS;
+if (cur_bytes > (BLOCK_CRYPTO_MAX_SECTORS * sector_size)) {
+cur_bytes = BLOCK_CRYPTO_MAX_SECTORS * sector_size;
 }
 
 qemu_iovec_reset(_qiov);
-qemu_iovec_add(_qiov, cipher_data, cur_nr_sectors * sector_size);
+qemu_iovec_add(_qiov, cipher_data, cur_bytes);
 
-ret = bdrv_co_readv(bs->file,
-payload_offset + sector_num,
-cur_nr_sectors, _qiov);
+ret = bdrv_co_preadv(bs->file, payload_offset + offset + bytes_done,
+ cur_bytes, _qiov, 0);
 if (ret < 0) {
 goto cleanup;
 }
 
-if (qcrypto_block_decrypt(crypto->block,
-  sector_num,
-  cipher_data, cur_nr_sectors * sector_size,
-  NULL) < 0) {
+if (qcrypto_block_decrypt(crypto->block, sector_num, cipher_data,
+  cur_bytes, NULL) < 0) {
 ret = -EIO;
 goto cleanup;
 }
 
-qemu_iovec_from_buf(qiov, bytes_done,
-cipher_data, cur_nr_sectors * sector_size);
+qemu_iovec_from_buf(qiov, bytes_done, cipher_data, cur_bytes);
 
-remaining_sectors -= cur_nr_sectors;
-sector_num += cur_nr_sectors;
-bytes_done += cur_nr_sectors * sector_size;
+sector_num += cur_bytes / sector_size;
+bytes -= cur_bytes;
+bytes_done += cur_bytes;
 }
 
  cleanup:
@@ -452,19 +452,23 @@ block_crypto_co_readv(BlockDriverState *bs, int64_t 
sector_num,
 
 
 static coroutine_fn int
-block_crypto_co_writev(BlockDriverState *bs, int64_t sector_num,
-   int remaining_sectors, QEMUIOVector *qiov)
+block_crypto_co_pwritev(BlockDriverState *bs, uint64_t offset, uint64_t bytes,
+QEMUIOVector *qiov, int flags)
 {
 BlockCrypto *crypto = bs->opaque;
-int cur_nr_sectors; /* number of sectors in current iteration */
+uint64_t cur_bytes; /* number of bytes in current iteration */
 uint64_t bytes_done = 0;
 uint8_t *cipher_data = NULL;
 QEMUIOVector hd_qiov;
 int ret = 0;
 uint64_t sector_size = qcrypto_block_get_sector_size(crypto->block);
-uint64_t payload_offset =
-qcrypto_block_get_payload_offset(crypto->block) / sector_size;
-assert(payload_offset < (INT64_MAX / 512));
+uint64_t payload_offset = qcrypto_block_get_payload_offset(crypto->block);
+uint64_t sector_num = offset / sector_size;
+
+assert(!flags);
+assert(payload_offset < INT64_MAX);
+assert(QEMU_IS_ALIGNED(offset, sector_size));
+assert(QEMU_IS_ALIGNED(bytes, sector_size));
 
 qemu_iovec_init(_qiov, qiov->niov);
 
@@ -479,37 +483,33 @@ block_crypto_co_writev(BlockDriverState *bs, int64_t 
sector_num,
 goto cleanup;
 }
 
-while 

[Qemu-devel] [PATCH v3 1/7] block: use 1 MB bounce buffers for crypto instead of 16KB

[Daniel P. Berrange]

Using 16KB bounce buffers creates a significant performance
penalty for I/O to encrypted volumes on storage which high
I/O latency (rotating rust & network drives), because it
triggers lots of fairly small I/O operations.

On tests with rotating rust, and cache=none|directsync,
write speed increased from 2MiB/s to 32MiB/s, on a par
with that achieved by the in-kernel luks driver. With
other cache modes the in-kernel driver is still notably
faster because it is able to report completion of the
I/O request before any encryption is done, while the
in-QEMU driver must encrypt the data before completion.

Reviewed-by: Eric Blake 
Reviewed-by: Stefan Hajnoczi 
Signed-off-by: Daniel P. Berrange 
---
 block/crypto.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/block/crypto.c b/block/crypto.c
index 58ef6f2f52..cc8afe0e0d 100644
--- a/block/crypto.c
+++ b/block/crypto.c
@@ -379,7 +379,7 @@ static void block_crypto_close(BlockDriverState *bs)
 }
 
 
-#define BLOCK_CRYPTO_MAX_SECTORS 32
+#define BLOCK_CRYPTO_MAX_SECTORS 2048
 
 static coroutine_fn int
 block_crypto_co_readv(BlockDriverState *bs, int64_t sector_num,
@@ -396,9 +396,8 @@ block_crypto_co_readv(BlockDriverState *bs, int64_t 
sector_num,
 
 qemu_iovec_init(_qiov, qiov->niov);
 
-/* Bounce buffer so we have a linear mem region for
- * entire sector. XXX optimize so we avoid bounce
- * buffer in case that qiov->niov == 1
+/* Bounce buffer because we don't wish to expose cipher text
+ * in qiov which points to guest memory.
  */
 cipher_data =
 qemu_try_blockalign(bs->file->bs, MIN(BLOCK_CRYPTO_MAX_SECTORS * 512,
@@ -464,9 +463,8 @@ block_crypto_co_writev(BlockDriverState *bs, int64_t 
sector_num,
 
 qemu_iovec_init(_qiov, qiov->niov);
 
-/* Bounce buffer so we have a linear mem region for
- * entire sector. XXX optimize so we avoid bounce
- * buffer in case that qiov->niov == 1
+/* Bounce buffer because we're not permitted to touch
+ * contents of qiov - it points to guest memory.
  */
 cipher_data =
 qemu_try_blockalign(bs->file->bs, MIN(BLOCK_CRYPTO_MAX_SECTORS * 512,
-- 
2.13.5

Re: [Qemu-devel] [PATCH v3] spapr_cpu_core: cleaning up qdev_get_machine() calls

[David Gibson]

On Tue, Sep 12, 2017 at 08:51:21AM +0200, Greg Kurz wrote:
> This patch removes the qdev_get_machine() calls that are made
> in spapr_cpu_core.c in situations where we can get an existing
> pointer for the MachineState by either passing it as an argument
> to the function or by using other already available pointers.
> 
> Credits to Daniel Henrique Barboza for the idea and the changelog
> text.
> 
> Signed-off-by: Greg Kurz 

Applied to ppc-for-2.11.

> ---
> v3: - dropped spapr_cpu_reset() hunk
> ---
>  hw/ppc/spapr_cpu_core.c |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
> index dc9df0d393d1..dea298a796c4 100644
> --- a/hw/ppc/spapr_cpu_core.c
> +++ b/hw/ppc/spapr_cpu_core.c
> @@ -162,10 +162,10 @@ static void spapr_cpu_core_unrealizefn(DeviceState 
> *dev, Error **errp)
>  g_free(sc->threads);
>  }
>  
> -static void spapr_cpu_core_realize_child(Object *child, Error **errp)
> +static void spapr_cpu_core_realize_child(Object *child,
> + sPAPRMachineState *spapr, Error 
> **errp)
>  {
>  Error *local_err = NULL;
> -sPAPRMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());
>  CPUState *cs = CPU(child);
>  PowerPCCPU *cpu = POWERPC_CPU(cs);
>  Object *obj;
> @@ -254,7 +254,7 @@ static void spapr_cpu_core_realize(DeviceState *dev, 
> Error **errp)
>  for (j = 0; j < cc->nr_threads; j++) {
>  obj = sc->threads + j * size;
>  
> -spapr_cpu_core_realize_child(obj, _err);
> +spapr_cpu_core_realize_child(obj, spapr, _err);
>  if (local_err) {
>  goto err;
>  }
> 

-- 
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: [Qemu-devel] [PATCH v7 30/38] qtest: Avoid passing raw strings through hmp()

[Thomas Huth]

On 11.09.2017 19:20, Eric Blake wrote:
> hmp() passes its string argument through the sprintf() family;
> with a proper attribute, gcc -Wformat warns us when we do something
> dangerous like passing a non-constant format string.  Fortunately,
> all our strings were safe, but checking whether the string can
> contain an unintended % is easy to avoid and therefore worth doing.
> 
> Signed-off-by: Eric Blake 
> 
> ---
> v7: add GCC_FMT_ATTR here, drop R-b
> ---
>  tests/libqtest.h | 8 
>  tests/test-hmp.c | 4 ++--
>  2 files changed, 6 insertions(+), 6 deletions(-)

Reviewed-by: Thomas Huth 

[Qemu-devel] [PATCH] scripts: let checkpatch.pl process an entire GIT branch

[Daniel P. Berrange]

Currently before submitting a series, devs should run checkpatch.pl
across each patch to be submitted. This can be automated using a
command such as:

  git rebase -i master -x 'git show | ./scripts/checkpatch.pl -'

This is rather long winded to type, so this patch introduces a new
flag '--branch' to checkpatch.pl which instructs it to check every
patch on the current GIT branch.

For example:

$ ./scripts/checkpatch.pl --branch
total: 0 errors, 0 warnings, 297 lines checked

b886d352a2bf58f0996471fb3991a138373a2957 has no obvious style problems and 
is ready for submission.
total: 0 errors, 0 warnings, 182 lines checked

2a731f9a9ce145e0e0df6d42dd2a3ce4dfc543fa has no obvious style problems and 
is ready for submission.
total: 0 errors, 0 warnings, 102 lines checked

11844169bcc0c8ed4449eb3744a69877ed329dd7 has no obvious style problems and 
is ready for submission.

By default it checks every patch identified by 'master..', however,
an alternative origin can be given if desired, if the current branch
is rebased to another non-master branch:

$ ./scripts/checkpatch.pl --branch somebranch..

Signed-off-by: Daniel P. Berrange 
---
 scripts/checkpatch.pl | 97 +--
 1 file changed, 71 insertions(+), 26 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index fa478074b8..f8d080441f 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -19,6 +19,8 @@ my $quiet = 0;
 my $tree = 1;
 my $chk_signoff = 1;
 my $chk_patch = 1;
+my $chk_branch = 0;
+my $revlist = "master..";
 my $tst_only;
 my $emacs = 0;
 my $terse = 0;
@@ -43,6 +45,7 @@ Options:
   --no-tree  run without a kernel tree
   --no-signoff   do not check for 'Signed-off-by' line
   --patchtreat FILE as patchfile (default)
+  --branch   check all patches on branch since master
   --emacsemacs compile window format
   --terseone line per report
   -f, --file treat FILE as regular source file
@@ -69,6 +72,7 @@ GetOptions(
'tree!' => \$tree,
'signoff!'  => \$chk_signoff,
'patch!'=> \$chk_patch,
+   'branch'=> \$chk_branch,
'emacs!'=> \$emacs,
'terse!'=> \$terse,
'f|file!'   => \$file,
@@ -88,9 +92,19 @@ help(0) if ($help);
 
 my $exit = 0;
 
-if ($#ARGV < 0) {
-   print "$P: no input files\n";
-   exit(1);
+if ($chk_branch) {
+   if ($#ARGV > 0) {
+   print "$P: expected zero or one origni revisions\n";
+   exit(1);
+   }
+   if ($#ARGV == 0) {
+   $revlist = shift @ARGV;
+   }
+} else {
+   if ($#ARGV < 0) {
+   print "$P: no input files\n";
+   exit(1);
+   }
 }
 
 my $dbg_values = 0;
@@ -251,32 +265,63 @@ $chk_signoff = 0 if ($file);
 my @rawlines = ();
 my @lines = ();
 my $vname;
-for my $filename (@ARGV) {
-   my $FILE;
-   if ($file) {
-   open($FILE, '-|', "diff -u /dev/null $filename") ||
-   die "$P: $filename: diff failed - $!\n";
-   } elsif ($filename eq '-') {
-   open($FILE, '<');
-   } else {
-   open($FILE, '<', "$filename") ||
-   die "$P: $filename: open failed - $!\n";
-   }
-   if ($filename eq '-') {
-   $vname = 'Your patch';
-   } else {
-   $vname = $filename;
-   }
-   while (<$FILE>) {
+if ($chk_branch) {
+   my @patches;
+   my $HASH;
+   open($HASH, "-|", "git", "log", "--format=%H", $revlist) ||
+   die "$P: git log --format=%H $revlist failed - $!\n";
+
+   while (<$HASH>) {
chomp;
-   push(@rawlines, $_);
+   push @patches, $_;
}
-   close($FILE);
-   if (!process($filename)) {
-   $exit = 1;
+
+   close $HASH;
+
+   for my $hash (@patches) {
+   my $FILE;
+   open($FILE, '-|', "git", "show", $hash) ||
+   die "$P: git show $hash - $!\n";
+   $vname = $hash;
+   while (<$FILE>) {
+   chomp;
+   push(@rawlines, $_);
+   }
+   close($FILE);
+   if (!process($hash)) {
+   $exit = 1;
+   }
+   @rawlines = ();
+   @lines = ();
+   }
+} else {
+   for my $filename (@ARGV) {
+   my $FILE;
+   if ($file) {
+   open($FILE, '-|', "diff -u /dev/null $filename") ||
+   die "$P: $filename: diff failed - $!\n";
+   } elsif ($filename eq '-') {
+   open($FILE, '<');
+   } else {
+   open($FILE, '<', "$filename") ||
+   

Re: [Qemu-devel] [PATCH v7 32/38] libqtest: Merge qtest_irq*() with irq*()

[Thomas Huth]

On 11.09.2017 19:20, Eric Blake wrote:
> Maintaining two layers of libqtest APIs, one that takes an explicit
> QTestState object, and the other that uses the implicit global_qtest,
> is annoying.  In the interest of getting rid of global implicit
> state and having less code to maintain, merge:
>  qtest_get_irq()
>  qtest_irq_intercept_in()
>  qtest_irq_intercept_out()
> with their short counterparts.  All callers that previously
> used the short form now make it explicit that they are relying on
> global_qtest, and later patches can then clean things up to remove
> the global variable.
> 
> Signed-off-by: Eric Blake 
> ---
>  tests/libqtest.h | 47 ++-
>  tests/libqtest.c |  6 +++---
>  tests/fdc-test.c | 48 
> 
>  tests/ide-test.c | 17 +
>  tests/ipmi-bt-test.c |  6 +++---
>  tests/ipmi-kcs-test.c|  8 
>  tests/libqos/libqos-pc.c |  2 +-
>  tests/rtc-test.c | 10 +-
>  tests/tco-test.c |  2 +-
>  tests/wdt_ib700-test.c   |  8 
>  10 files changed, 60 insertions(+), 94 deletions(-)
> 
> diff --git a/tests/libqtest.h b/tests/libqtest.h
> index 26d5f37bc9..8398c0fd07 100644
> --- a/tests/libqtest.h
> +++ b/tests/libqtest.h
> @@ -176,33 +176,33 @@ char *qtest_hmp(QTestState *s, const char *fmt, ...) 
> GCC_FMT_ATTR(2, 3);
>  char *qtest_hmpv(QTestState *s, const char *fmt, va_list ap);
> 
>  /**
> - * qtest_get_irq:
> + * get_irq:
>   * @s: #QTestState instance to operate on.
>   * @num: Interrupt to observe.
>   *
>   * Returns: The level of the @num interrupt.
>   */
> -bool qtest_get_irq(QTestState *s, int num);
> +bool get_irq(QTestState *s, int num);
> 
>  /**
> - * qtest_irq_intercept_in:
> + * irq_intercept_in:
>   * @s: #QTestState instance to operate on.
>   * @string: QOM path of a device.
>   *
>   * Associate qtest irqs with the GPIO-in pins of the device
>   * whose path is specified by @string.
>   */
> -void qtest_irq_intercept_in(QTestState *s, const char *string);
> +void irq_intercept_in(QTestState *s, const char *string);
> 
>  /**
> - * qtest_irq_intercept_out:
> + * irq_intercept_out:
>   * @s: #QTestState instance to operate on.
>   * @string: QOM path of a device.
>   *
>   * Associate qtest irqs with the GPIO-out pins of the device
>   * whose path is specified by @string.
>   */
> -void qtest_irq_intercept_out(QTestState *s, const char *string);
> +void irq_intercept_out(QTestState *s, const char *string);

Could we please also keep the qtest prefix here?

 Thomas

Re: [Qemu-devel] Suggested Wiki Update

[Cornelia Huck]

On Tue, 12 Sep 2017 10:57:14 +0200
Viktor Mihajlovski  wrote:

> Hi,
> 
> the content of https://wiki.qemu.org/index.php/Features/S390xNetworkBoot
> is slightly outdated since proper DHCP based netboot support for s390x
> has been implemented by the series ending with commit 29d1221.
> 
> As it is still desirable to provide some instructions on building
> network bootable images for the s390x architecture, I'd like to suggest
> that the text is replaced (see proposal below). Conny, could I once more
> request your help in that matter?
> 
> == Building a s390 network bootable binary ==
> 
> Since 2.10 QEMU offers network boot support which allows to load a
> binary from a TFTP server and boot it. As s390 network bootable images
> are not very common, this document gives a brief overview on how to
> build one.
> 
> A s390 network bootable image can be built by bundling some shell
> scripts, busybox and the kexec binary bundled into an initial ramdisk
> and append that to a kernel image. An existing s390 system can be used
> as source.
> 
> One way to do that is to take a kernel and an installer initial ramdisk
> from a distribution's DVD/ISO and concatenate them. Some fixups are
> necessary int the new binary, which can be done by using the script in
> [https://github.com/ibm-s390-tools/s390-tools/blob/master/netboot/mk-s390image].
> Booting this image would then start the installation process as if
> booted from the DVD.
> 
> Another possible way is to build a binary that behaves similar to the
> PXELINUX boot loader. In this case an initial ramdisk with an init
> process triggering the PXELINUX-like processing has to be built as
> described in
> [https://github.com/ibm-s390-tools/s390-tools/tree/master/netboot]. The
> site also contains a script assisting in the creation of such an initial
> ramdisk.
> 

Looks good.

Can you perhaps add a sentence that the base support is available with
2.9 and netboot with 2.10? ('Overview' looks like a good place for
that.)

[Qemu-devel] question： I found a bug which will lead to qemu crash

[WangJie (Captain)]

Hi, Kevin.

I found a bug about qemu-kvm(version 2.7.0-rc0 adn 2.8.1). but qemu 2.6.0 and 
current master is OK.
So I git-bisect the master branch，and I found the patch you commited (block: 
Decouple throttling from BlockDriverState) lead the bug into qemu.

The patch which lead the bug into qemu: 
(https://github.com/qemu/qemu/commit/7ca7f0f6db1fedd28d490795d778cf23979a2aa7#diff-ea36ba0f79150cc299732696a069caba)

Because the current master is OK. So I think you had fixed it , can you tell me 
which patch fixed the bug?Thank you :>


the bug is that: qemu will crash when loop to attach and detach a disk which 
configured qos to a VM for a while.


*Segmentation fault info(qemu 2.7.0-rc0):*
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/bin/qemu-kvm -name 
guest=wangjie-i-clone203_rhel_7.3_64_guestosdev,debug-t'.
Program terminated with signal 11, Segmentation fault.
#0  0x7fe960413e3c in throttle_group_next_blk (blk=0x11) at 
block/throttle-groups.c:160
160ThrottleState *ts = blkp->throttle_state;
Missing separate debuginfos, use: debuginfo-install glib2-2.40.0-4.x86_64 
glibc-2.17-157.h5.x86_64 libaio-0.3.109-13.x86_64 libgcc-4.8.3-10.h1.x86_64 
nettle-2.7.1-4.h1.x86_64 numactl-libs-2.0.9-4.x86_64 pixman-0.32.4-3.x86_64 
zlib-1.2.7-14.x86_64
(gdb) bt
#0  0x7fe960413e3c in throttle_group_next_blk (blk=0x11) at 
block/throttle-groups.c:160
#1  0x7fe960413eff in next_throttle_token (blk=0x7fe963f5c400, 
is_write=false) at block/throttle-groups.c:192
#2  0x7fe9604141a8 in throttle_group_co_io_limits_intercept 
(blk=0x7fe963f5c400, bytes=512, is_write=false)
at block/throttle-groups.c:303
#3  0x7fe960400048 in blk_co_preadv (blk=0x7fe963f5c400, offset=0, 
bytes=512, qiov=0x7ffc37ee8aa0, flags=(unknown: 0))
at block/block-backend.c:728
#4  0x7fe960400159 in blk_read_entry (opaque=0x7ffc37ee8ac0) at 
block/block-backend.c:769
#5  0x7fe96048f4d7 in coroutine_trampoline (i0=1678853408, i1=32745) at 
util/coroutine-ucontext.c:78
#6  0x7fe95dfdacf0 in ?? () from /lib64/libc.so.6
#7  0x7ffc37ee9c00 in ?? ()
#8  0x in ?? ()



*Segmentation fault info(qemu 2.8.1):*
Program received signal SIGSEGV, Segmentation fault.
0x7f5469220607 in blk_has_pending_reqs (blk=0x7f54672a0032, is_write=false) 
at block/throttle-groups.c:184
184return blkp->pending_reqs[is_write];
(gdb) bt
#0  0x7f5469220607 in blk_has_pending_reqs (blk=0x7f54672a0032, 
is_write=false) at block/throttle-groups.c:184
#1  0x7f54692206a8 in next_throttle_token (blk=0x7f546b6cd120, 
is_write=false) at block/throttle-groups.c:207
#2  0x7f5469220984 in throttle_group_co_io_limits_intercept 
(blk=0x7f546b6cd120, bytes=512, is_write=false)
at block/throttle-groups.c:322
#3  0x7f546920bc79 in blk_co_preadv (blk=0x7f546b6cd120, offset=0, 
bytes=512, qiov=0x7ffcc7355060, flags=0)
at block/block-backend.c:815
#4  0x7f546920bddf in blk_read_entry (opaque=0x7ffcc7355080) at 
block/block-backend.c:865
#5  0x7f54692a00f0 in coroutine_trampoline (i0=-588050448, i1=32595) at 
util/coroutine-ucontext.c:79
#6  0x7f5466f34cf0 in ?? () from /lib64/libc.so.6
#7  0x7f53f27fa9e0 in ?? ()
#8  0x in ?? ()


*The way how to find the bug as follows:*
*1、start a VM*


*2、attach and detach a disk for a while，the configure of the disk (add-1.xml) 
as follows*





3000
3000
12000
12000




*3、run below script for a while，the qemu process of  VM will crash*
ret=1
while [ $ret -ne 0 ]; do
virsh attach-device i-clone203_rhel_7.3_64_guestosdev add-1.xml
sleep 2
virsh detach-device i-clone203_rhel_7.3_64_guestosdev add-1.xml
done

[Qemu-devel] [PATCH v3 3/7] block: fix data type casting for crypto payload offset

[Daniel P. Berrange]

The crypto APIs report the offset of the data payload as an uint64_t
type, but the block driver is casting to size_t or ssize_t which will
potentially truncate.

Most of the block APIs use int64_t for offsets meanwhile, so even if
using uint64_t in the crypto block driver we are still at risk of
truncation.

Change the block crypto driver to use uint64_t, but add asserts that
the value is less than INT64_MAX.

Signed-off-by: Daniel P. Berrange 
---
 block/crypto.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/block/crypto.c b/block/crypto.c
index cc8afe0e0d..d68cbac2ac 100644
--- a/block/crypto.c
+++ b/block/crypto.c
@@ -364,8 +364,9 @@ static int block_crypto_truncate(BlockDriverState *bs, 
int64_t offset,
  PreallocMode prealloc, Error **errp)
 {
 BlockCrypto *crypto = bs->opaque;
-size_t payload_offset =
+uint64_t payload_offset =
 qcrypto_block_get_payload_offset(crypto->block);
+assert(payload_offset < (INT64_MAX - offset));
 
 offset += payload_offset;
 
@@ -391,8 +392,9 @@ block_crypto_co_readv(BlockDriverState *bs, int64_t 
sector_num,
 uint8_t *cipher_data = NULL;
 QEMUIOVector hd_qiov;
 int ret = 0;
-size_t payload_offset =
+uint64_t payload_offset =
 qcrypto_block_get_payload_offset(crypto->block) / 512;
+assert(payload_offset < (INT64_MAX / 512));
 
 qemu_iovec_init(_qiov, qiov->niov);
 
@@ -458,8 +460,9 @@ block_crypto_co_writev(BlockDriverState *bs, int64_t 
sector_num,
 uint8_t *cipher_data = NULL;
 QEMUIOVector hd_qiov;
 int ret = 0;
-size_t payload_offset =
+uint64_t payload_offset =
 qcrypto_block_get_payload_offset(crypto->block) / 512;
+assert(payload_offset < (INT64_MAX / 512));
 
 qemu_iovec_init(_qiov, qiov->niov);
 
@@ -520,7 +523,9 @@ static int64_t block_crypto_getlength(BlockDriverState *bs)
 BlockCrypto *crypto = bs->opaque;
 int64_t len = bdrv_getlength(bs->file->bs);
 
-ssize_t offset = qcrypto_block_get_payload_offset(crypto->block);
+uint64_t offset = qcrypto_block_get_payload_offset(crypto->block);
+assert(offset < INT64_MAX);
+assert(offset < len);
 
 len -= offset;
 
-- 
2.13.5

[Qemu-devel] [PATCH v3 2/7] crypto: expose encryption sector size in APIs

[Daniel P. Berrange]

While current encryption schemes all have a fixed sector size of
512 bytes, this is not guaranteed to be the case in future. Expose
the sector size in the APIs so the block layer can remove assumptions
about fixed 512 byte sectors.

Signed-off-by: Daniel P. Berrange 
---
 crypto/block-luks.c|  6 --
 crypto/block-qcow.c|  1 +
 crypto/block.c |  6 ++
 crypto/blockpriv.h |  1 +
 include/crypto/block.h | 15 +++
 5 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/crypto/block-luks.c b/crypto/block-luks.c
index 36bc856084..a9062bb0f2 100644
--- a/crypto/block-luks.c
+++ b/crypto/block-luks.c
@@ -846,8 +846,9 @@ qcrypto_block_luks_open(QCryptoBlock *block,
 }
 }
 
+block->sector_size = QCRYPTO_BLOCK_LUKS_SECTOR_SIZE;
 block->payload_offset = luks->header.payload_offset *
-QCRYPTO_BLOCK_LUKS_SECTOR_SIZE;
+block->sector_size;
 
 luks->cipher_alg = cipheralg;
 luks->cipher_mode = ciphermode;
@@ -1240,8 +1241,9 @@ qcrypto_block_luks_create(QCryptoBlock *block,
QCRYPTO_BLOCK_LUKS_SECTOR_SIZE)) *
  QCRYPTO_BLOCK_LUKS_NUM_KEY_SLOTS);
 
+block->sector_size = QCRYPTO_BLOCK_LUKS_SECTOR_SIZE;
 block->payload_offset = luks->header.payload_offset *
-QCRYPTO_BLOCK_LUKS_SECTOR_SIZE;
+block->sector_size;
 
 /* Reserve header space to match payload offset */
 initfunc(block, block->payload_offset, opaque, _err);
diff --git a/crypto/block-qcow.c b/crypto/block-qcow.c
index a456fe338b..4dd594a9ba 100644
--- a/crypto/block-qcow.c
+++ b/crypto/block-qcow.c
@@ -80,6 +80,7 @@ qcrypto_block_qcow_init(QCryptoBlock *block,
 goto fail;
 }
 
+block->sector_size = QCRYPTO_BLOCK_QCOW_SECTOR_SIZE;
 block->payload_offset = 0;
 
 return 0;
diff --git a/crypto/block.c b/crypto/block.c
index c382393d9a..a7a9ad240e 100644
--- a/crypto/block.c
+++ b/crypto/block.c
@@ -170,6 +170,12 @@ uint64_t qcrypto_block_get_payload_offset(QCryptoBlock 
*block)
 }
 
 
+uint64_t qcrypto_block_get_sector_size(QCryptoBlock *block)
+{
+return block->sector_size;
+}
+
+
 void qcrypto_block_free(QCryptoBlock *block)
 {
 if (!block) {
diff --git a/crypto/blockpriv.h b/crypto/blockpriv.h
index 0edb810e22..d227522d88 100644
--- a/crypto/blockpriv.h
+++ b/crypto/blockpriv.h
@@ -36,6 +36,7 @@ struct QCryptoBlock {
 QCryptoHashAlgorithm kdfhash;
 size_t niv;
 uint64_t payload_offset; /* In bytes */
+uint64_t sector_size; /* In bytes */
 };
 
 struct QCryptoBlockDriver {
diff --git a/include/crypto/block.h b/include/crypto/block.h
index f0e543bee1..13232b2472 100644
--- a/include/crypto/block.h
+++ b/include/crypto/block.h
@@ -241,6 +241,21 @@ QCryptoHashAlgorithm 
qcrypto_block_get_kdf_hash(QCryptoBlock *block);
 uint64_t qcrypto_block_get_payload_offset(QCryptoBlock *block);
 
 /**
+ * qcrypto_block_get_sector_size:
+ * @block: the block encryption object
+ *
+ * Get the size of sectors used for payload encryption. A new
+ * IV is used at the start of each sector. The encryption
+ * sector size is not required to match the sector size of the
+ * underlying storage. For example LUKS will always use a 512
+ * byte sector size, even if the volume is on a disk with 4k
+ * sectors.
+ *
+ * Returns: the sector in bytes
+ */
+uint64_t qcrypto_block_get_sector_size(QCryptoBlock *block);
+
+/**
  * qcrypto_block_free:
  * @block: the block encryption object
  *
-- 
2.13.5

[Qemu-devel] [PATCH v3 0/7] Misc improvements to crypto block driver

[Daniel P. Berrange]

This is a followup to

  v1: https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg00781.html
  v2: https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg06464.html

This collection of patches first improves the performance of the
crypto block driver and then does various cleanups to improve ongoing
maint work.

Changed in v3:

  - Support passthrough of BDRV_REQ_FUA (Eric)
  - Fix potential truncation of payload offset values (Eric)
  - Use encryption scheme sector size instead of BDRV_SECTOR_SIZE (Kevin)
  - Use QEMU_IS_ALIGNED where appropriate (Eric)
  - Remove unused 'sector_num' variable (Eric)
  - Fix whitespace alignment (Eric)
  - Fix math error in qcow conversion (Eric)

Daniel P. Berrange (7):
  block: use 1 MB bounce buffers for crypto instead of 16KB
  crypto: expose encryption sector size in APIs
  block: fix data type casting for crypto payload offset
  block: don't use constant 512 as sector size in crypto driver
  block: convert crypto driver to bdrv_co_preadv|pwritev
  block: convert qcrypto_block_encrypt|decrypt to take bytes offset
  block: support passthrough of BDRV_REQ_FUA in crypto driver

 block/crypto.c | 134 +++--
 block/qcow.c   |   7 ++-
 block/qcow2-cluster.c  |   8 ++-
 block/qcow2.c  |   4 +-
 crypto/block-luks.c|  18 ---
 crypto/block-qcow.c|  13 +++--
 crypto/block.c |  26 +++---
 crypto/blockpriv.h |   5 +-
 include/crypto/block.h |  29 ---
 9 files changed, 150 insertions(+), 94 deletions(-)

-- 
2.13.5

[Qemu-devel] [PATCH v3 6/7] block: convert qcrypto_block_encrypt|decrypt to take bytes offset

[Daniel P. Berrange]

Instead of sector offset, take the bytes offset when encrypting
or decrypting data.

Signed-off-by: Daniel P. Berrange 
---
 block/crypto.c | 12 
 block/qcow.c   |  7 +--
 block/qcow2-cluster.c  |  8 +++-
 block/qcow2.c  |  4 ++--
 crypto/block-luks.c| 12 
 crypto/block-qcow.c| 12 
 crypto/block.c | 20 ++--
 crypto/blockpriv.h |  4 ++--
 include/crypto/block.h | 14 --
 9 files changed, 54 insertions(+), 39 deletions(-)

diff --git a/block/crypto.c b/block/crypto.c
index d004e9cef4..1f77095336 100644
--- a/block/crypto.c
+++ b/block/crypto.c
@@ -394,7 +394,6 @@ block_crypto_co_preadv(BlockDriverState *bs, uint64_t 
offset, uint64_t bytes,
 int ret = 0;
 uint64_t sector_size = qcrypto_block_get_sector_size(crypto->block);
 size_t payload_offset = qcrypto_block_get_payload_offset(crypto->block);
-uint64_t sector_num = offset / sector_size;
 
 assert(!flags);
 assert(payload_offset < INT64_MAX);
@@ -430,15 +429,14 @@ block_crypto_co_preadv(BlockDriverState *bs, uint64_t 
offset, uint64_t bytes,
 goto cleanup;
 }
 
-if (qcrypto_block_decrypt(crypto->block, sector_num, cipher_data,
-  cur_bytes, NULL) < 0) {
+if (qcrypto_block_decrypt(crypto->block, offset + bytes_done,
+  cipher_data, cur_bytes, NULL) < 0) {
 ret = -EIO;
 goto cleanup;
 }
 
 qemu_iovec_from_buf(qiov, bytes_done, cipher_data, cur_bytes);
 
-sector_num += cur_bytes / sector_size;
 bytes -= cur_bytes;
 bytes_done += cur_bytes;
 }
@@ -463,7 +461,6 @@ block_crypto_co_pwritev(BlockDriverState *bs, uint64_t 
offset, uint64_t bytes,
 int ret = 0;
 uint64_t sector_size = qcrypto_block_get_sector_size(crypto->block);
 uint64_t payload_offset = qcrypto_block_get_payload_offset(crypto->block);
-uint64_t sector_num = offset / sector_size;
 
 assert(!flags);
 assert(payload_offset < INT64_MAX);
@@ -492,8 +489,8 @@ block_crypto_co_pwritev(BlockDriverState *bs, uint64_t 
offset, uint64_t bytes,
 
 qemu_iovec_to_buf(qiov, bytes_done, cipher_data, cur_bytes);
 
-if (qcrypto_block_encrypt(crypto->block, sector_num, cipher_data,
-  cur_bytes, NULL) < 0) {
+if (qcrypto_block_encrypt(crypto->block, offset + bytes_done,
+  cipher_data, cur_bytes, NULL) < 0) {
 ret = -EIO;
 goto cleanup;
 }
@@ -507,7 +504,6 @@ block_crypto_co_pwritev(BlockDriverState *bs, uint64_t 
offset, uint64_t bytes,
 goto cleanup;
 }
 
-sector_num += cur_bytes / sector_size;
 bytes -= cur_bytes;
 bytes_done += cur_bytes;
 }
diff --git a/block/qcow.c b/block/qcow.c
index f450b00cfc..d242301ed2 100644
--- a/block/qcow.c
+++ b/block/qcow.c
@@ -478,7 +478,9 @@ static int get_cluster_offset(BlockDriverState *bs,
 for(i = 0; i < s->cluster_sectors; i++) {
 if (i < n_start || i >= n_end) {
 memset(s->cluster_data, 0x00, 512);
-if (qcrypto_block_encrypt(s->crypto, start_sect + 
i,
+if (qcrypto_block_encrypt(s->crypto,
+  (start_sect + i) *
+  BDRV_SECTOR_SIZE,
   s->cluster_data,
   BDRV_SECTOR_SIZE,
   NULL) < 0) {
@@ -668,7 +670,8 @@ static coroutine_fn int qcow_co_readv(BlockDriverState *bs, 
int64_t sector_num,
 }
 if (bs->encrypted) {
 assert(s->crypto);
-if (qcrypto_block_decrypt(s->crypto, sector_num, buf,
+if (qcrypto_block_decrypt(s->crypto,
+  sector_num * BDRV_SECTOR_SIZE, buf,
   n * BDRV_SECTOR_SIZE, NULL) < 0) {
 ret = -EIO;
 break;
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index 0d4824993c..09ae0b6ecc 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -396,15 +396,13 @@ static bool coroutine_fn 
do_perform_cow_encrypt(BlockDriverState *bs,
 {
 if (bytes && bs->encrypted) {
 BDRVQcow2State *s = bs->opaque;
-int64_t sector = (s->crypt_physical_offset ?
+int64_t offset = (s->crypt_physical_offset ?
   (cluster_offset + offset_in_cluster) :
-  (src_cluster_offset + offset_in_cluster))
- >> BDRV_SECTOR_BITS;
+  (src_cluster_offset + offset_in_cluster));
   

Re: [Qemu-devel] [PATCH] s390: set DHCP client architecure id for netboot

[Cornelia Huck]

On Mon, 11 Sep 2017 12:33:47 +0200
Viktor Mihajlovski  wrote:

> Setting the client architecture DHCP option to 0x001f (s390 Basic) [1]
> allows the DHCP server to return a s390-specific bootfile if wanted.
> DHCP servers not configured for the option (or not yet recognizing the
> option value) will continue to work as they have done before.
> 
> [1] https://www.iana.org/assignments/dhcpv6-parameters
> 
> Signed-off-by: Viktor Mihajlovski 
> ---
>  pc-bios/s390-ccw/netboot.mak | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/pc-bios/s390-ccw/netboot.mak b/pc-bios/s390-ccw/netboot.mak
> index a9e1374..a25d238 100644
> --- a/pc-bios/s390-ccw/netboot.mak
> +++ b/pc-bios/s390-ccw/netboot.mak
> @@ -50,7 +50,7 @@ libc.a: $(LIBCOBJS)
>  
>  LIBNETOBJS := args.o dhcp.o dns.o icmpv6.o ipv6.o tcp.o udp.o bootp.o \
> dhcpv6.o ethernet.o ipv4.o ndp.o tftp.o
> -LIBNETCFLAGS := $(QEMU_CFLAGS) $(LIBC_INC) $(LIBNET_INC)
> +LIBNETCFLAGS := $(QEMU_CFLAGS) -DDHCPARCH=0x1F $(LIBC_INC) $(LIBNET_INC)
>  
>  %.o : $(SLOF_DIR)/lib/libnet/%.c
>   $(call quiet-command,$(CC) $(LIBNETCFLAGS) -c -o $@ 
> $<,"CC","$(TARGET_DIR)$@")

Thanks, applied.

Re: [Qemu-devel] [PATCH v2] Replace round_page() with TARGET_PAGE_ALIGN()

[Thomas Huth]

On 11.09.2017 22:16, Kamil Rytarowski wrote:
> This change fixes conflict with the DragonFly BSD headers.
> 
> Signed-off-by: Kamil Rytarowski 
> ---
>  hw/ppc/mac_newworld.c | 11 +++
>  hw/ppc/mac_oldworld.c | 11 +++
>  2 files changed, 6 insertions(+), 16 deletions(-)
> 
> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
> index d466634997..51bf83019b 100644
> --- a/hw/ppc/mac_newworld.c
> +++ b/hw/ppc/mac_newworld.c
> @@ -124,11 +124,6 @@ static uint64_t translate_kernel_address(void *opaque, 
> uint64_t addr)
>  return (addr & 0x0fff) + KERNEL_LOAD_ADDR;
>  }
>  
> -static hwaddr round_page(hwaddr addr)
> -{
> -return (addr + TARGET_PAGE_SIZE - 1) & TARGET_PAGE_MASK;
> -}
> -
>  static void ppc_core99_reset(void *opaque)
>  {
>  PowerPCCPU *cpu = opaque;
> @@ -256,7 +251,7 @@ static void ppc_core99_init(MachineState *machine)
>  }
>  /* load initrd */
>  if (initrd_filename) {
> -initrd_base = round_page(kernel_base + kernel_size + KERNEL_GAP);
> +initrd_base = TARGET_PAGE_ALIGN(kernel_base + kernel_size + 
> KERNEL_GAP);
>  initrd_size = load_image_targphys(initrd_filename, initrd_base,
>ram_size - initrd_base);
>  if (initrd_size < 0) {
> @@ -264,11 +259,11 @@ static void ppc_core99_init(MachineState *machine)
>   initrd_filename);
>  exit(1);
>  }
> -cmdline_base = round_page(initrd_base + initrd_size);
> +cmdline_base = TARGET_PAGE_ALIGN(initrd_base + initrd_size);
>  } else {
>  initrd_base = 0;
>  initrd_size = 0;
> -cmdline_base = round_page(kernel_base + kernel_size + 
> KERNEL_GAP);
> +cmdline_base = TARGET_PAGE_ALIGN(kernel_base + kernel_size + 
> KERNEL_GAP);
>  }
>  ppc_boot_device = 'm';
>  } else {
> diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
> index fcac399562..feb31911ca 100644
> --- a/hw/ppc/mac_oldworld.c
> +++ b/hw/ppc/mac_oldworld.c
> @@ -66,11 +66,6 @@ static uint64_t translate_kernel_address(void *opaque, 
> uint64_t addr)
>  return (addr & 0x0fff) + KERNEL_LOAD_ADDR;
>  }
>  
> -static hwaddr round_page(hwaddr addr)
> -{
> -return (addr + TARGET_PAGE_SIZE - 1) & TARGET_PAGE_MASK;
> -}
> -
>  static void ppc_heathrow_reset(void *opaque)
>  {
>  PowerPCCPU *cpu = opaque;
> @@ -191,7 +186,7 @@ static void ppc_heathrow_init(MachineState *machine)
>  }
>  /* load initrd */
>  if (initrd_filename) {
> -initrd_base = round_page(kernel_base + kernel_size + KERNEL_GAP);
> +initrd_base = TARGET_PAGE_ALIGN(kernel_base + kernel_size + 
> KERNEL_GAP);
>  initrd_size = load_image_targphys(initrd_filename, initrd_base,
>ram_size - initrd_base);
>  if (initrd_size < 0) {
> @@ -199,11 +194,11 @@ static void ppc_heathrow_init(MachineState *machine)
>   initrd_filename);
>  exit(1);
>  }
> -cmdline_base = round_page(initrd_base + initrd_size);
> +cmdline_base = TARGET_PAGE_ALIGN(initrd_base + initrd_size);
>  } else {
>  initrd_base = 0;
>  initrd_size = 0;
> -cmdline_base = round_page(kernel_base + kernel_size + 
> KERNEL_GAP);
> +cmdline_base = TARGET_PAGE_ALIGN(kernel_base + kernel_size + 
> KERNEL_GAP);
>  }
>  ppc_boot_device = 'm';
>  } else {
> 

Reviewed-by: Thomas Huth 

(and please make sure to CC: qemu-...@nongnu.org for ppc related changes)

Re: [Qemu-devel] qdev_get_machine() can return something non-NULL but not TYPE_MACHINE

[Igor Mammedov]

On Tue, 12 Sep 2017 10:11:32 +0100
Peter Maydell  wrote:

> On 12 September 2017 at 08:40, Igor Mammedov  wrote:
> > On Mon, 11 Sep 2017 14:33:03 +0100
> > Peter Maydell  wrote:  
> >> It's not possible in all cases to set a CPU property from the
> >> top level board code. In quite a lot of cases the CPU
> >> object is created by an SoC object which is in turn
> >> created by the board code, and there is no plumbing
> >> there to pass arbitrary properties through to the CPU
> >> object...  
> > there is a cleaner way without cpu accessing machine,
> > make it property of cpu and use compat machinery that
> > was invented for fixing up stuff of this kind.
> >
> > SET_MACHINE_COMPAT(MachineClass,
> >{ .driver = "arm-cpu",
> >  .property = "foo",
> >  .value= "off",
> >}
> >   )  
> 
> It looks like we only use that machine-compat stuff on
> our versioned boards, which is pretty much the only place
> where we don't need to set this particular flag...
typically, yes it's used for versioned boards to, because
it's where we have to fixup/override defaults to keep compatibility.
But it's does not mean that it's limited to it.

in this case it allows to keep clean separation of device model
and not add an extra member to generic MachineClass which is used
by some old boards.


> thanks
> -- PMM
> 

Re: [Qemu-devel] Suggested Wiki Update

[Christian Borntraeger]

Looks good to me. I somehow lost my wiki password, so maybe Conny can do the
update until this is fixed

On 09/12/2017 10:57 AM, Viktor Mihajlovski wrote:
> Hi,
> 
> the content of https://wiki.qemu.org/index.php/Features/S390xNetworkBoot
> is slightly outdated since proper DHCP based netboot support for s390x
> has been implemented by the series ending with commit 29d1221.
> 
> As it is still desirable to provide some instructions on building
> network bootable images for the s390x architecture, I'd like to suggest
> that the text is replaced (see proposal below). Conny, could I once more
> request your help in that matter?
> 
> == Building a s390 network bootable binary ==
> 
> Since 2.10 QEMU offers network boot support which allows to load a
> binary from a TFTP server and boot it. As s390 network bootable images
> are not very common, this document gives a brief overview on how to
> build one.
> 
> A s390 network bootable image can be built by bundling some shell
> scripts, busybox and the kexec binary bundled into an initial ramdisk
> and append that to a kernel image. An existing s390 system can be used
> as source.
> 
> One way to do that is to take a kernel and an installer initial ramdisk
> from a distribution's DVD/ISO and concatenate them. Some fixups are
> necessary int the new binary, which can be done by using the script in
> [https://github.com/ibm-s390-tools/s390-tools/blob/master/netboot/mk-s390image].
> Booting this image would then start the installation process as if
> booted from the DVD.
> 
> Another possible way is to build a binary that behaves similar to the
> PXELINUX boot loader. In this case an initial ramdisk with an init
> process triggering the PXELINUX-like processing has to be built as
> described in
> [https://github.com/ibm-s390-tools/s390-tools/tree/master/netboot]. The
> site also contains a script assisting in the creation of such an initial
> ramdisk.
> 

Re: [Qemu-devel] [PATCH 6/6] arm: drop intermadiate cpu_model -> cpu type parsing and use cpu type directly

[Igor Mammedov]

On Tue, 5 Sep 2017 14:47:52 -0700
Alistair Francis  wrote:

> On Tue, Sep 5, 2017 at 2:31 PM, Eduardo Habkost  wrote:
> > On Mon, Sep 04, 2017 at 04:01:02PM +0200, Igor Mammedov wrote:  
> >> there are 2 use cases to deal with:
> >>   1: fixed CPU models per board/soc
> >>   2: boards with user configurable cpu_model and fallback to
> >>  default cpu_model if user hasn't specified one explicitly
> >>
> >> For the 1st
> >>   drop intermediate cpu_model parsing and use const cpu type
> >>   directly, which replaces:
> >>  typename = object_class_get_name(
> >>cpu_class_by_name(TYPE_ARM_CPU, cpu_model))
> >>  object_new(typename)
> >>   with
> >>  object_new(FOO_CPU_TYPE_NAME)
> >>   or
> >>  cpu_generic_init(BASE_CPU_TYPE, "my cpu model")
> >>   with
> >>  cpu_create(FOO_CPU_TYPE_NAME)
> >>
> >> as result 1st use case doesn't have to invoke not necessary
> >> translation and not needed code is removed.
> >>
> >> For the 2nd
> >>  1: set default cpu type with MachineClass::default_cpu_type and
> >>  2: use generic cpu_model parsing that done before machine_init()
> >> is run and:
> >> 2.1: drop custom cpu_model parsing where pattern is:
> >>typename = object_class_get_name(
> >>cpu_class_by_name(TYPE_ARM_CPU, cpu_model))
> >>[parse_features(typename, cpu_model, ) ]
> >>
> >> 2.2: or replace cpu_generic_init() which does what
> >>  2.1 does + create_cpu(typename) with just
> >>  create_cpu(machine->cpu_type)
> >> as result cpu_name -> cpu_type translation is done using
> >> generic machine code one including parsing optional features
> >> if supported/present (removes a bunch of duplicated cpu_model
> >> parsing code) and default cpu type is defined in an uniform way
> >> within machine_class_init callbacks instead of adhoc places
> >> in boadr's machine_init code.
> >>
> >> Signed-off-by: Igor Mammedov 
> >> ---
> >> CC: Peter Maydell 
> >> CC: Igor Mitsyanko 
> >> CC: Rob Herring 
> >> CC: Andrzej Zaborowski 
> >> CC: Jan Kiszka 
> >> CC: Alistair Francis 
> >> CC: "Edgar E. Iglesias" 
> >> CC: qemu-...@nongnu.org
> >> ---

[...]

> >>
> >>  static const TypeInfo lm3s6965evb_type = {
> >> diff --git a/hw/arm/stm32f205_soc.c b/hw/arm/stm32f205_soc.c
> >> index f61e735..1cd6374 100644
> >> --- a/hw/arm/stm32f205_soc.c
> >> +++ b/hw/arm/stm32f205_soc.c
> >> @@ -112,7 +112,7 @@ static void stm32f205_soc_realize(DeviceState 
> >> *dev_soc, Error **errp)
> >>
> >>  armv7m = DEVICE(>armv7m);
> >>  qdev_prop_set_uint32(armv7m, "num-irq", 96);
> >> -qdev_prop_set_string(armv7m, "cpu-model", s->cpu_model);
> >> +qdev_prop_set_string(armv7m, "cpu-type", s->cpu_type);
> >>  object_property_set_link(OBJECT(>armv7m), 
> >> OBJECT(get_system_memory()),
> >>   "memory", _abort);
> >>  object_property_set_bool(OBJECT(>armv7m), true, "realized", );
> >> @@ -200,7 +200,7 @@ static void stm32f205_soc_realize(DeviceState 
> >> *dev_soc, Error **errp)
> >>  }
> >>
> >>  static Property stm32f205_soc_properties[] = {
> >> -DEFINE_PROP_STRING("cpu-model", STM32F205State, cpu_model),
> >> +DEFINE_PROP_STRING("cpu-type", STM32F205State, cpu_type),  
> >
> > Same as armv7m: are we 100% sure users are not setting this
> > manually?  
> 
> In an embedded board like this it really doesn't make sense to let the
> user overwrite the CPU. The SoC will take it as an option, but the
> board (which creates the SoC) just blindly always uses the same CPU.
> That feature is more for QOMificatoion then any real reason though.
If SoC has fixed cpu type then I'd drop property.
I'd leave it upto board maintainers to cleanup not really needed
properties and make soc with fixed cpu type where it makes sense.

> In saying that I think a warning if the user tries to set the CPU
> would make sense. I know that this issues comes up in other ARM boards
> (Zynq-7000 has the same issue as well) so maybe a machine property
> saying that the board doesn't accept custom CPUs would be a good idea.
> 
> Overall I think this patch is moving in the right direction though and
> this CPU option being ignored existed before this series.
right, this series just removes cpu_generic_init()/cpu_model in boards
everything else should be done as separate series.

> 
> Thanks,
> Alistair
> 
> 
> >
> >  
> 

[Qemu-devel] [PATCH v3 4/7] block: don't use constant 512 as sector size in crypto driver

[Daniel P. Berrange]

Use the qcrypto_block_get_sector_size() value in the block
crypto driver instead of hardcoding 512 as the sector size.

Signed-off-by: Daniel P. Berrange 
---
 block/crypto.c | 34 ++
 1 file changed, 18 insertions(+), 16 deletions(-)

diff --git a/block/crypto.c b/block/crypto.c
index d68cbac2ac..49d6d4c058 100644
--- a/block/crypto.c
+++ b/block/crypto.c
@@ -392,8 +392,9 @@ block_crypto_co_readv(BlockDriverState *bs, int64_t 
sector_num,
 uint8_t *cipher_data = NULL;
 QEMUIOVector hd_qiov;
 int ret = 0;
+uint64_t sector_size = qcrypto_block_get_sector_size(crypto->block);
 uint64_t payload_offset =
-qcrypto_block_get_payload_offset(crypto->block) / 512;
+qcrypto_block_get_payload_offset(crypto->block) / sector_size;
 assert(payload_offset < (INT64_MAX / 512));
 
 qemu_iovec_init(_qiov, qiov->niov);
@@ -401,9 +402,9 @@ block_crypto_co_readv(BlockDriverState *bs, int64_t 
sector_num,
 /* Bounce buffer because we don't wish to expose cipher text
  * in qiov which points to guest memory.
  */
-cipher_data =
-qemu_try_blockalign(bs->file->bs, MIN(BLOCK_CRYPTO_MAX_SECTORS * 512,
-  qiov->size));
+cipher_data = qemu_try_blockalign(
+bs->file->bs, MIN(BLOCK_CRYPTO_MAX_SECTORS * sector_size,
+  qiov->size));
 if (cipher_data == NULL) {
 ret = -ENOMEM;
 goto cleanup;
@@ -417,7 +418,7 @@ block_crypto_co_readv(BlockDriverState *bs, int64_t 
sector_num,
 }
 
 qemu_iovec_reset(_qiov);
-qemu_iovec_add(_qiov, cipher_data, cur_nr_sectors * 512);
+qemu_iovec_add(_qiov, cipher_data, cur_nr_sectors * sector_size);
 
 ret = bdrv_co_readv(bs->file,
 payload_offset + sector_num,
@@ -428,18 +429,18 @@ block_crypto_co_readv(BlockDriverState *bs, int64_t 
sector_num,
 
 if (qcrypto_block_decrypt(crypto->block,
   sector_num,
-  cipher_data, cur_nr_sectors * 512,
+  cipher_data, cur_nr_sectors * sector_size,
   NULL) < 0) {
 ret = -EIO;
 goto cleanup;
 }
 
 qemu_iovec_from_buf(qiov, bytes_done,
-cipher_data, cur_nr_sectors * 512);
+cipher_data, cur_nr_sectors * sector_size);
 
 remaining_sectors -= cur_nr_sectors;
 sector_num += cur_nr_sectors;
-bytes_done += cur_nr_sectors * 512;
+bytes_done += cur_nr_sectors * sector_size;
 }
 
  cleanup:
@@ -460,8 +461,9 @@ block_crypto_co_writev(BlockDriverState *bs, int64_t 
sector_num,
 uint8_t *cipher_data = NULL;
 QEMUIOVector hd_qiov;
 int ret = 0;
+uint64_t sector_size = qcrypto_block_get_sector_size(crypto->block);
 uint64_t payload_offset =
-qcrypto_block_get_payload_offset(crypto->block) / 512;
+qcrypto_block_get_payload_offset(crypto->block) / sector_size;
 assert(payload_offset < (INT64_MAX / 512));
 
 qemu_iovec_init(_qiov, qiov->niov);
@@ -469,9 +471,9 @@ block_crypto_co_writev(BlockDriverState *bs, int64_t 
sector_num,
 /* Bounce buffer because we're not permitted to touch
  * contents of qiov - it points to guest memory.
  */
-cipher_data =
-qemu_try_blockalign(bs->file->bs, MIN(BLOCK_CRYPTO_MAX_SECTORS * 512,
-  qiov->size));
+cipher_data = qemu_try_blockalign(
+bs->file->bs, MIN(BLOCK_CRYPTO_MAX_SECTORS * sector_size,
+  qiov->size));
 if (cipher_data == NULL) {
 ret = -ENOMEM;
 goto cleanup;
@@ -485,18 +487,18 @@ block_crypto_co_writev(BlockDriverState *bs, int64_t 
sector_num,
 }
 
 qemu_iovec_to_buf(qiov, bytes_done,
-  cipher_data, cur_nr_sectors * 512);
+  cipher_data, cur_nr_sectors * sector_size);
 
 if (qcrypto_block_encrypt(crypto->block,
   sector_num,
-  cipher_data, cur_nr_sectors * 512,
+  cipher_data, cur_nr_sectors * sector_size,
   NULL) < 0) {
 ret = -EIO;
 goto cleanup;
 }
 
 qemu_iovec_reset(_qiov);
-qemu_iovec_add(_qiov, cipher_data, cur_nr_sectors * 512);
+qemu_iovec_add(_qiov, cipher_data, cur_nr_sectors * sector_size);
 
 ret = bdrv_co_writev(bs->file,
  payload_offset + sector_num,
@@ -507,7 +509,7 @@ block_crypto_co_writev(BlockDriverState *bs, int64_t 
sector_num,
 
 remaining_sectors -= cur_nr_sectors;
 sector_num += cur_nr_sectors;
-bytes_done += cur_nr_sectors * 512;
+bytes_done += cur_nr_sectors * sector_size;
 }
 

[Qemu-devel] [PATCH v3 7/7] block: support passthrough of BDRV_REQ_FUA in crypto driver

[Daniel P. Berrange]

The BDRV_REQ_FUA flag can trivially be allowed in the crypt driver
as a passthrough to the underlying block driver.

Signed-off-by: Daniel P. Berrange 
---
 block/crypto.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/block/crypto.c b/block/crypto.c
index 1f77095336..d1c28d62c1 100644
--- a/block/crypto.c
+++ b/block/crypto.c
@@ -279,6 +279,9 @@ static int block_crypto_open_generic(QCryptoBlockFormat 
format,
 return -EINVAL;
 }
 
+bs->supported_write_flags = BDRV_REQ_FUA &
+bs->file->bs->supported_write_flags;
+
 opts = qemu_opts_create(opts_spec, NULL, 0, _abort);
 qemu_opts_absorb_qdict(opts, options, _err);
 if (local_err) {
@@ -462,7 +465,7 @@ block_crypto_co_pwritev(BlockDriverState *bs, uint64_t 
offset, uint64_t bytes,
 uint64_t sector_size = qcrypto_block_get_sector_size(crypto->block);
 uint64_t payload_offset = qcrypto_block_get_payload_offset(crypto->block);
 
-assert(!flags);
+assert(!(flags & ~BDRV_REQ_FUA));
 assert(payload_offset < INT64_MAX);
 assert(QEMU_IS_ALIGNED(offset, sector_size));
 assert(QEMU_IS_ALIGNED(bytes, sector_size));
@@ -499,7 +502,7 @@ block_crypto_co_pwritev(BlockDriverState *bs, uint64_t 
offset, uint64_t bytes,
 qemu_iovec_add(_qiov, cipher_data, cur_bytes);
 
 ret = bdrv_co_pwritev(bs->file, payload_offset + offset + bytes_done,
-  cur_bytes, _qiov, 0);
+  cur_bytes, _qiov, flags);
 if (ret < 0) {
 goto cleanup;
 }
-- 
2.13.5

Re: [Qemu-devel] loading bitmaps in invalidate_cache fails

[Kevin Wolf]

Am 11.09.2017 um 18:51 hat Vladimir Sementsov-Ogievskiy geschrieben:
> Hi Kevin!
> 
> I'm confused with relations of permissions and invalidation, can you please
> help?
> 
> Now dirty bitmaps are loaded in invalidate_cache. Here is a problem with
> migration:
> 
> 1. destination starts (inactive)
> 
> 2. load bitmaps readonly
> 
> ...
> 
> 3. invalidate_cache: here we should make our loaded bitmaps RW, ie set
> BdrvDirtyBitmap->readonly
> 
>   to false and set IN_USE bit in the image. But the latter goes into
> "bdrv_aligned_pwritev: Assertion `child->perm & BLK_PERM_WRITE' failed",
> 
>   because in bdrv_invalidate_cache we call bdrv_set_perm after
> drv->bdrv_invalidate_cache.
> 
> 
> What is the true way of fixing this?

It's all still a bit of a mess. :-(

I think it makes a lot of sense that we should activate the lower layers
first, so the order in bdrv_invalidate_cache() looks wrong. It should be
something like this:

1. invalidate_cache() for the children
2. Update permissions for non-BDRV_O_INACTIVE
3. Call drv->bdrv_invalidate_cache()

I'm currently working on some fixes related to bdrv_reopen() where
things become tricky because the updated permissions shouldn't depend on
the current state, but on the state after the operation has finished.

You get something similar here, but I think just making sure that we
clear BDRV_O_INACTIVE before updating the permissions is enough here.
The only thing to be careful is that in error cases, we need to revert
both the flag and the permissions then.

Kevin

Re: [Qemu-devel] [PATCH for-2.10] qemu-options: Document the -drive locking parameter.

[Richard W.M. Jones]

On Wed, Sep 06, 2017 at 01:38:45PM +0200, Kevin Wolf wrote:
> This command line fragment looks correct to me. For me, it seems to
> work. I'm starting a first qemu in the background with default locking
> options:
> 
> $ x86_64-softmmu/qemu-system-x86_64 -hda /tmp/test.qcow2
> 
> And then starting a second one with a command line resembling yours:
> 
> $ x86_64-softmmu/qemu-system-x86_64 -device virtio-scsi \
>   -drive 
> file=/tmp/test.qcow2,cache=unsafe,format=qcow2,file.locking=off,id=hd0,if=none
>  \
>   -device scsi-hd,drive=hd0

The problem is with overlays, where file.locking doesn't propagate to
the backing file.  Thus:

  $ qemu-system-x86_64 -drive file=backing,format=raw

while in another terminal:

  $ qemu-img create -b backing -f qcow2 overlay
  $ qemu-system-x86_64 -drive file=overlay,format=qcow2,file.locking=off
  qemu-system-x86_64: Failed to get shared "write" lock
  Is another process using the image?

After some experimentation, I came up with this command which works:

  $ qemu-system-x86_64 -drive 
file.file.filename=overlay,file.driver=qcow2,file.backing.file.locking=off

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/

Re: [Qemu-devel] [RFC PATCH qemu 3/4] memory: Share flat views and dispatch trees between address spaces

[Alexey Kardashevskiy]

On 12/09/17 17:12, Paolo Bonzini wrote:
> On 12/09/2017 07:55, Alexey Kardashevskiy wrote:
>> On 12/09/17 01:30, Paolo Bonzini wrote:
>>> On 11/09/2017 14:08, Alexey Kardashevskiy wrote:
> Ok, this makes sense.  Maybe it should be a flatview rather than an
> AddressSpaceDispatch (a FlatView is essentially a list of
> MemoryRegionSections; attaching the ASD to the FlatView is more or less
> an implementation detail).
 The helpers I converted from AddressSpace to AddressSpaceDispatch do use
 dispatch structure only and do not use FlatView so it seemed logical.
>>>
>>> Understood, but from a design POV FlatView makes more sense.
>>>
 btw this address_space in MemoryRegionSection - it does not seem to make
 much sense in the PhysPageMap::sections array, it only makes sense when
 MemoryRegionSection uses as a temporary object when calling listeners. Will
 it make sense if we enforce MemoryRegionSection::address_space to be NULL
 in the array and not NULL when used temporary?
>>>
>>> memory_region_section_get_iotlb needs to access the AddressSpaceDispatch
>>> for sections stored in the PhysPageMap array, because
>>> memory_region_section_get_iotlb uses the ASD to compute the section index.
>>
>> Ohhh, not extremely trivial, out of curiosity - is that iotlb encoding
>> described anywhere?
> 
> No, I don't think so.
> 
>> Anyway, this can be simplified (or rather made more straightforward?) -
>> tlb_set_page_with_attrs() can calculate the section index and pass it to
>> memory_region_section_get_iotlb(). Still does not make much sense? It just
>> looks quite useless to keep that address_space pointer alive just for one
>> case which can easily avoid using this pointer.
> 
> Hmm I suppose address_space_translate_for_iotlb knows the ASD and could
> also return the index, basically combining it and
> memory_region_section_get_iotlb() into one function.

Ok, good.

One more question - how do we decide what goes to exec.c and what goes to
memory.c? I have a temptation to simply embed AddressSpaceDispatch into
FlatView instead of allocating it and storing the pointer (I'll probably
avoid doing so for now anyway but still curios).

The header comment for exec.c says it is "Virtual page mapping" but
AddressSpaceDispatch is a physical address space map and it seems to fit
into the memory.c's "Physical memory management" header comment.


-- 
Alexey

Re: [Qemu-devel] [PATCH 01/12] qemu-iotests: remove dead code

[Kevin Wolf]

Am 10.08.2017 um 00:43 hat Paolo Bonzini geschrieben:
> 
> 
> - Original Message -
> > From: "Eric Blake" 
> > To: "Paolo Bonzini" , qemu-devel@nongnu.org
> > Cc: kw...@redhat.com, qemu-bl...@nongnu.org
> > Sent: Thursday, August 10, 2017 12:18:54 AM
> > Subject: Re: [Qemu-devel] [PATCH 01/12] qemu-iotests: remove dead code
> > 
> > On 08/09/2017 04:54 PM, Paolo Bonzini wrote:
> > > This includes shell function, shell variables, command line options
> > > (randomize.awk does not exist) and conditions that can never be true
> > > (./qemu does not exist anymore).
> > 
> > Can we point to a commit id where we stopped making ./qemu?
> 
> commit 9aed1e036dc0de49d08d713f9e5c4655e94acb56
> Author: Anthony Liguori 
> Date:   Mon Aug 29 09:55:36 2011 -0500
> 
> Rename qemu -> qemu-system-i386
> 
> This has been discussed before in the past.  The special casing really 
> makes no
> sense anymore.  This seems like a good change to make for 1.0.
> 
> Signed-off-by: Anthony Liguori 

This is not related to ./qemu in the qemu-iotests directory. It's just
the name of the binary that is created in i386-softmmu/, but that has
never been the working directory for qemu-iotests.

> > Is it still worth supporting a local symlink?
> 
> Not sure who would have one...

I have always been using symlinks in the qemu-iotests directory. And, as
you probably expect now, ./qemu does exist in my setup.

Now, I must admit that I haven't actually made real use of it recently
because the symlinks only point to the binaries that qemu-iotests would
pick up anyway. But when running qemu-iotests against a different qemu
version or installed binaries instead of whatever is in the build tree,
I always found the symlinks more convenient that setting up a bunch of
environment variables.

So maybe supporting them isn't completely useless.

Kevin

Re: [Qemu-devel] [PATCH v2 3/4] block: convert crypto driver to bdrv_co_preadv|pwritev

[Daniel P. Berrange]

On Thu, Aug 31, 2017 at 10:08:00AM -0500, Eric Blake wrote:
> On 08/31/2017 06:05 AM, Daniel P. Berrange wrote:
> > Make the crypto driver implement the bdrv_co_preadv|pwritev
> > callbacks,  and also use bdrv_co_preadv|pwritev for I/O
> > with the protocol driver beneath.
> > 
> > Signed-off-by: Daniel P. Berrange 
> > ---
> >  block/crypto.c | 103 
> > +
> >  1 file changed, 53 insertions(+), 50 deletions(-)
> > 
> 
> >  static coroutine_fn int
> > -block_crypto_co_readv(BlockDriverState *bs, int64_t sector_num,
> > -  int remaining_sectors, QEMUIOVector *qiov)
> > +block_crypto_co_preadv(BlockDriverState *bs, uint64_t offset, uint64_t 
> > bytes,
> > +   QEMUIOVector *qiov, int flags)
> 
> >  {
> >  BlockCrypto *crypto = bs->opaque;
> > -int cur_nr_sectors; /* number of sectors in current iteration */
> > +uint64_t cur_bytes; /* number of bytes in current iteration */
> >  uint64_t bytes_done = 0;
> >  uint8_t *cipher_data = NULL;
> >  QEMUIOVector hd_qiov;
> >  int ret = 0;
> > -size_t payload_offset =
> > -qcrypto_block_get_payload_offset(crypto->block) / BDRV_SECTOR_SIZE;
> > +size_t payload_offset = 
> > qcrypto_block_get_payload_offset(crypto->block);
> 
> Pre-existing: is size_t the right type, or can we overflow a 64-bit
> offset on a 32-bit host?

No, it is bad. I'm fixing that as a separate patch, since it is a good
to cleanup.

> 
> > +uint64_t sector_num = offset / BDRV_SECTOR_SIZE;
> > +
> > +assert((offset % BDRV_SECTOR_SIZE) == 0);
> > +assert((bytes % BDRV_SECTOR_SIZE) == 0);
> 
> The osdep.h macros might be nicer than open-coding; furthermore, if
> desired, you could shorten to:
> 
> assert(QEMU_IS_ALIGNED(offset | bytes, BDRV_SECTOR_SIZE));

Yep, makes sense.

> >  static coroutine_fn int
> > -block_crypto_co_writev(BlockDriverState *bs, int64_t sector_num,
> > -   int remaining_sectors, QEMUIOVector *qiov)
> > +block_crypto_co_pwritev(BlockDriverState *bs, uint64_t offset, uint64_t 
> > bytes,
> > +QEMUIOVector *qiov, int flags)
> >  {
> 
> Hmm - you don't set supported_write_flags.  But presumably, if the
> underlying BDS supports BDRV_REQUEST_FUA, then crypto can likewise
> support that flag by passing it through to the underlying device after
> encryption.

Something to be added as a separate patch

> > @@ -611,8 +613,9 @@ BlockDriver bdrv_crypto_luks = {
> >  .bdrv_truncate  = block_crypto_truncate,
> >  .create_opts= _crypto_create_opts_luks,
> >  
> > -.bdrv_co_readv  = block_crypto_co_readv,
> > -.bdrv_co_writev = block_crypto_co_writev,
> > +.bdrv_refresh_limits = block_crypto_refresh_limits,
> > +.bdrv_co_preadv  = block_crypto_co_preadv,
> > +.bdrv_co_pwritev = block_crypto_co_pwritev,
> >  .bdrv_getlength = block_crypto_getlength,
> >  .bdrv_get_info  = block_crypto_get_info_luks,
> >  .bdrv_get_specific_info = block_crypto_get_specific_info_luks,
> 
> Looks weird when = isn't consistently aligned, but we use more than one
> space.  My preference is to just use one space everywhere, as adding a
> longer name to the list doesn't require a mass re-format of all other
> entries; but I'm not opposed when people like the aligned = for
> legibility.  So up to you if you do anything in response to my nit.

Normally I stick with one space, so don't know what I was thinking
when i wrote this.

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 :|

Re: [Qemu-devel] [PATCH v7 28/38] libqtest: Add qtest_[v]startf()

[Thomas Huth]

On 11.09.2017 19:20, Eric Blake wrote:
> We have several callers that were formatting the argument strings
> themselves; consolidate this effort by adding new convenience
> functions directly in libqtest, and update all call-sites that
> can benefit from it.
[...]
> diff --git a/tests/libqtest.c b/tests/libqtest.c
> index e8c2e11817..b535d7768f 100644
> --- a/tests/libqtest.c
> +++ b/tests/libqtest.c
> @@ -245,6 +245,27 @@ QTestState *qtest_start(const char *extra_args)
>  return global_qtest = s;
>  }
> 
> +QTestState *qtest_vstartf(const char *fmt, va_list ap)
> +{
> +char *args = g_strdup_vprintf(fmt, ap);
> +QTestState *s;
> +
> +s = qtest_start(args);
> +global_qtest = NULL;

Don't you need a g_free(args) here?

> +return s;
> +}
> +
> +QTestState *qtest_startf(const char *fmt, ...)
> +{
> +va_list ap;
> +QTestState *s;
> +
> +va_start(ap, fmt);
> +s = qtest_vstartf(fmt, ap);
> +va_end(ap);
> +return s;
> +}
[...]
> diff --git a/tests/e1000-test.c b/tests/e1000-test.c
> index 0c5fcdcc44..12bc526ad6 100644
> --- a/tests/e1000-test.c
> +++ b/tests/e1000-test.c
> @@ -14,16 +14,8 @@
>  static void test_device(gconstpointer data)
>  {
>  const char *model = data;
> -QTestState *s;
> -char *args;
> 
> -args = g_strdup_printf("-device %s", model);
> -s = qtest_start(args);
> -
> -if (s) {
> -qtest_quit(s);
> -}
> -g_free(args);
> +qtest_quit(qtest_startf("-device %s", model));

Just my personal taste, but I think I'd be nicer to keep this on
separate lines:

QTestState *s;

s = qtest_startf("-device %s", model);
qtest_quit(s);

>  }
[...]
> diff --git a/tests/eepro100-test.c b/tests/eepro100-test.c
> index bdc8a67d57..fc9ea84d66 100644
> --- a/tests/eepro100-test.c
> +++ b/tests/eepro100-test.c
> @@ -13,18 +13,9 @@
>  static void test_device(gconstpointer data)
>  {
>  const char *model = data;
> -QTestState *s;
> -char *args;
> -
> -args = g_strdup_printf("-device %s", model);
> -s = qtest_start(args);
> 
>  /* Tests only initialization so far. TODO: Implement functional tests */
> -
> -if (s) {
> -qtest_quit(s);
> -}
> -g_free(args);
> +qtest_quit(qtest_startf("-device %s", model));
>  }

dito

[...]
> diff --git a/tests/numa-test.c b/tests/numa-test.c
> index fa21d26935..e2f6c68be8 100644
> --- a/tests/numa-test.c
> +++ b/tests/numa-test.c
> @@ -12,20 +12,14 @@
>  #include "qemu/osdep.h"
>  #include "libqtest.h"
> 
> -static char *make_cli(const char *generic_cli, const char *test_cli)
> -{
> -return g_strdup_printf("%s %s", generic_cli ? generic_cli : "", 
> test_cli);
> -}
> -
>  static void test_mon_explicit(const void *data)
>  {
>  char *s;
> -char *cli;
> +const char *args = data;
> 
> -cli = make_cli(data, "-smp 8 "
> -   "-numa node,nodeid=0,cpus=0-3 "
> -   "-numa node,nodeid=1,cpus=4-7 ");
> -qtest_start(cli);
> +global_qtest = qtest_startf("%s -smp 8 "
> +"-numa node,nodeid=0,cpus=0-3 "
> +"-numa node,nodeid=1,cpus=4-7 ", args);
> 
>  s = hmp("info numa");
>  g_assert(strstr(s, "node 0 cpus: 0 1 2 3"));
> @@ -33,16 +27,14 @@ static void test_mon_explicit(const void *data)
>  g_free(s);
> 
>  qtest_quit(global_qtest);
> -g_free(cli);
>  }
> 
>  static void test_mon_default(const void *data)
>  {
>  char *s;
> -char *cli;
> +const char *args = data;
> 
> -cli = make_cli(data, "-smp 8 -numa node -numa node");
> -qtest_start(cli);
> +global_qtest = qtest_startf("%s -smp 8 -numa node -numa node", args);
> 
>  s = hmp("info numa");
>  g_assert(strstr(s, "node 0 cpus: 0 2 4 6"));
> @@ -50,18 +42,16 @@ static void test_mon_default(const void *data)
>  g_free(s);
> 
>  qtest_quit(global_qtest);
> -g_free(cli);
>  }
> 
>  static void test_mon_partial(const void *data)
>  {
>  char *s;
> -char *cli;
> +const char *args = data;
> 
> -cli = make_cli(data, "-smp 8 "
> -   "-numa node,nodeid=0,cpus=0-1 "
> -   "-numa node,nodeid=1,cpus=4-5 ");
> -qtest_start(cli);
> +global_qtest = qtest_startf("%s -smp 8 "
> +"-numa node,nodeid=0,cpus=0-1 "
> +"-numa node,nodeid=1,cpus=4-5 ", args);

Does GCC emit a warning if you'd used data here directly? Otherwise I
think you could simply do this without the local args variable...

 Thomas

Re: [Qemu-devel] question: qemu will crash when attach and detach a disk which configured qos for a while

[Stefan Hajnoczi]

On Mon, Sep 11, 2017 at 09:24:23AM +0800, WangJie (Captain) wrote:
> Hi, I maybe find a bug about qemu-kvm(version:2.8.1.1)

Can you reproduce the segfault with qemu.git/master?

> *Segmentation fault info:*
> Program received signal SIGSEGV, Segmentation fault.
> 0x7f5469220607 in blk_has_pending_reqs (blk=0x7f54672a0032, 
> is_write=false) at block/throttle-groups.c:184
> 184return blkp->pending_reqs[is_write];
> (gdb) bt
> #0  0x7f5469220607 in blk_has_pending_reqs (blk=0x7f54672a0032, 
> is_write=false) at block/throttle-groups.c:184
> #1  0x7f54692206a8 in next_throttle_token (blk=0x7f546b6cd120, 
> is_write=false) at block/throttle-groups.c:207
> #2  0x7f5469220984 in throttle_group_co_io_limits_intercept 
> (blk=0x7f546b6cd120, bytes=512, is_write=false)
> at block/throttle-groups.c:322
> #3  0x7f546920bc79 in blk_co_preadv (blk=0x7f546b6cd120, offset=0, 
> bytes=512, qiov=0x7ffcc7355060, flags=0)
> at block/block-backend.c:815
> #4  0x7f546920bddf in blk_read_entry (opaque=0x7ffcc7355080) at 
> block/block-backend.c:865
> #5  0x7f54692a00f0 in coroutine_trampoline (i0=-588050448, i1=32595) at 
> util/coroutine-ucontext.c:79
> #6  0x7f5466f34cf0 in ?? () from /lib64/libc.so.6
> #7  0x7f53f27fa9e0 in ?? ()
> #8  0x in ?? ()

Is the guest running software that accesses the disk?  Otherwise I guess
this is the guest kernel probing the partition table on the disk
(offset=0, bytes=512).

> the way how to find the bug as follows:
> 
> *1、attach and detach a disk for a while，the configure of the disk as follows*
> 
> 
> 
> 
> 
> 3000
> 3000
> 12000
> 12000
> 
> 
> 
> 
> *2、run below script for a while，the qemu process of  VM will crash*
> ret=1
> while [ $ret -ne 0 ]; do
> virsh attach-device i-clone203_rhel_7.3_64_guestosdev add-1.xml
> sleep 2
> virsh detach-device i-clone203_rhel_7.3_64_guestosdev add-1.xml
> done
> 

Re: [Qemu-devel] [PATCH v4] pci: Set err to errp directly rather than through error_propagate()

[Stefan Hajnoczi]

On Sat, Sep 09, 2017 at 02:22:26PM +0800, Mao Zhongyi wrote:
> ioh3420_interrupts_init() pass error message to local_err, then
> propagate it to errp by error_propagate(), which is not necessary.
> So eliminate it and pass errp directly instead of local_err.
> 
> Cc: "Michael S. Tsirkin" 
> Cc: Marcel Apfelbaum  
> Signed-off-by: Mao Zhongyi 
> Reviewed-by: Eric Blake 
> Reviewed-by: Marcel Apfelbaum 
> Reviewed-by: Philippe Mathieu-Daudé 
> ---
> v4:
> it not apply clearly on HEAD, so rebase it and modify the commit
> message.
> ---
> 
>  hw/pci-bridge/ioh3420.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)

Reviewed-by: Stefan Hajnoczi 

Re: [Qemu-devel] [PATCH 0/2] spapr_pci: some more cleanup

[David Gibson]

On Mon, Sep 11, 2017 at 12:13:56PM +0200, Greg Kurz wrote:
> ---
> 
> Greg Kurz (2):
>   spapr_pci: convert sprintf() to g_strdup_printf()
>   spapr_pci: don't create 64-bit MMIO window if we don't need to

Applied to ppc-for-2.11.

-- 
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: [Qemu-devel] [PATCH 6/6] arm: drop intermadiate cpu_model -> cpu type parsing and use cpu type directly

[Igor Mammedov]

On Sat, 9 Sep 2017 17:30:14 -0300
Eduardo Habkost  wrote:

> On Tue, Sep 05, 2017 at 03:46:07PM -0700, Alistair Francis wrote:
> > On Tue, Sep 5, 2017 at 3:12 PM, Eduardo Habkost  
> > wrote:  
> > > On Tue, Sep 05, 2017 at 02:47:52PM -0700, Alistair Francis wrote:  
> > >> On Tue, Sep 5, 2017 at 2:31 PM, Eduardo Habkost  
> > >> wrote:  
> > > [...]  
> > >> >> diff --git a/hw/arm/stm32f205_soc.c b/hw/arm/stm32f205_soc.c
> > >> >> index f61e735..1cd6374 100644
> > >> >> --- a/hw/arm/stm32f205_soc.c
> > >> >> +++ b/hw/arm/stm32f205_soc.c
> > >> >> @@ -112,7 +112,7 @@ static void stm32f205_soc_realize(DeviceState 
> > >> >> *dev_soc, Error **errp)
> > >> >>
> > >> >>  armv7m = DEVICE(>armv7m);
> > >> >>  qdev_prop_set_uint32(armv7m, "num-irq", 96);
> > >> >> -qdev_prop_set_string(armv7m, "cpu-model", s->cpu_model);
> > >> >> +qdev_prop_set_string(armv7m, "cpu-type", s->cpu_type);
> > >> >>  object_property_set_link(OBJECT(>armv7m), 
> > >> >> OBJECT(get_system_memory()),
> > >> >>   "memory", _abort);
> > >> >>  object_property_set_bool(OBJECT(>armv7m), true, "realized", 
> > >> >> );
> > >> >> @@ -200,7 +200,7 @@ static void stm32f205_soc_realize(DeviceState 
> > >> >> *dev_soc, Error **errp)
> > >> >>  }
> > >> >>
> > >> >>  static Property stm32f205_soc_properties[] = {
> > >> >> -DEFINE_PROP_STRING("cpu-model", STM32F205State, cpu_model),
> > >> >> +DEFINE_PROP_STRING("cpu-type", STM32F205State, cpu_type),  
> > >> >
> > >> > Same as armv7m: are we 100% sure users are not setting this
> > >> > manually?  
> > >>
> > >> In an embedded board like this it really doesn't make sense to let the
> > >> user overwrite the CPU. The SoC will take it as an option, but the
> > >> board (which creates the SoC) just blindly always uses the same CPU.
> > >> That feature is more for QOMificatoion then any real reason though.
> > >>  
> > >
> > > I'm not talking about -cpu (no user-visible change in the
> > > handling of -cpu should result from this patch), but about
> > > possible cases where the user set the "cpu-model" property using
> > > another mechanism, like -global.  Probably it's impossible for an
> > > user to override the property successfully, but I would like to
> > > be sure.  
> > 
> > Ah, that is trickier.
> > 
> > I guess that is possible to do, but the object setting logic should
> > handle the error gracefully and inform the user of the error.  
> 
> After looking at the code more closely, I think we can be 100%
> sure the user doesn't rely on the property, because:
> 
> * TYPE_ARMV7M and TYPE_STM32F205_SOC are both sysbus devices
>   with user_creatable=false, so the user can't instantiate them
>   directly;
> * The only places where those objects are realized inside the
>   code are:
>   * mps2_common_init()
>   * netduino2_init()
>   * stm32f205_soc_realize()
>   * armv7m_init()
>   Those functions always set the "cpu-model" property immediately
>   before realize.
> 
> This means any value set by the user (e.g. using -global) would
> be always overwritten before realize.
> 
> However, I have a suggestion for Igor: making a separate patch
> that renames the existing property to "x-cpu-model", and using
> "x-cpu-type" in this series.  This way we will explicitly
> document the fact that the property is not a stable
> user/management interface.
There is no much point in renaming to "x-cpu-model" as it will be deleted
right afterwards, I'd just delete "cpu-model" and use "x-cpu-type"
in this patch. I'm not a fun of 'x-' prefix and would prefer a flag
in property to mark it as internal. But it's out of scope of this series,
so I don't care much about naming at the moment and will use "x-cpu-type"
as you suggest.

> 
> >   
> > >
> > >  
> > >> In saying that I think a warning if the user tries to set the CPU
> > >> would make sense. I know that this issues comes up in other ARM boards
> > >> (Zynq-7000 has the same issue as well) so maybe a machine property
> > >> saying that the board doesn't accept custom CPUs would be a good idea.  
> > >
> > > Yeah, there are multiple cases in this patch where boards are
> > > validating the CPU model, but not all boards do that.  A generic
> > > MachineClass::valid_cpu_types[] field would be useful.
> > >  
> > >>
> > >> Overall I think this patch is moving in the right direction though and
> > >> this CPU option being ignored existed before this series.  
> > >
> > > I agree this is going on the right direction.  However, I don't
> > > see any board that ignore the CPU option: all of them seem to use
> > > cpu_model when creating the CPUs, already.  
> > 
> > The Netduino2 will ignore any CPU options and always use a Cortex-m3.
> > I was wrong about Zynq-7000 though, it does respect the -cpu option.
> > 
> > Thanks,
> > Alistair
> >   
> > >
> > > --
> > > Eduardo  
> 

Re: [Qemu-devel] [PATCH 04/12] qemu-iotests: limit non-_PROG-suffixed variables to common.rc

[Kevin Wolf]

Am 09.08.2017 um 23:55 hat Paolo Bonzini geschrieben:
> These are never used by "check", with one exception that does not need
> $QEMU_OPTIONS.  Keep them in common.rc, which will be soon included only
> by the tests.
> 
> Signed-off-by: Paolo Bonzini 

> diff --git a/tests/qemu-iotests/common b/tests/qemu-iotests/common
> index 50720f080f..f58e56fc40 100644
> --- a/tests/qemu-iotests/common
> +++ b/tests/qemu-iotests/common
> @@ -454,11 +454,3 @@ fi
>  #
>  list=`sort $tmp.list`
>  rm -f $tmp.list $tmp.tmp $tmp.sed
> -
> -[ "$QEMU" = "" ] && _fatal "qemu not found"
> -[ "$QEMU_IMG" = "" ] && _fatal "qemu-img not found"
> -[ "$QEMU_IO" = "" ] && _fatal "qemu-io not found"
> -
> -if [ "$IMGPROTO" = "nbd" ] ; then
> -[ "$QEMU_NBD" = "" ] && _fatal "qemu-nbd not found"
> -fi

Hm, does this mean that instead of ./check failing when a binary is
missing, we try each test case now and each one fails with the same
error message?

*tries it out*

Okay, it's already broken today because the strings are never empty but
contain the name of the wrapper functions, but it's still bad behaviour.
Instead of just telling me that the binary is missing like it used to
work, I get tons of test case diffs.

Kevin

Re: [Qemu-devel] [PATCH 07/12] qemu-iotests: disintegrate more parts of common.config

[Kevin Wolf]

Am 09.08.2017 um 23:55 hat Paolo Bonzini geschrieben:
> Split "check" parts from tests part.
> 
> For the directory setup, the actual computation of directories goes
> in "check", while the sanity checks go in the tests.
> 
> Signed-off-by: Paolo Bonzini 

Same comment as for patch 1, we may want to keep this working.

Kevin

Re: [Qemu-devel] [PATCH v7 31/38] libqtest: Merge qtest_clock_*() with clock_*()

[Thomas Huth]

On 11.09.2017 19:20, Eric Blake wrote:
> Maintaining two layers of libqtest APIs, one that takes an explicit
> QTestState object, and the other that uses the implicit global_qtest,
> is annoying.  In the interest of getting rid of global implicit
> state and having less code to maintain, merge:
>  qtest_clock_set()
>  qtest_clock_step()
>  qtest_clock_step_next()
> with their short counterparts.  All callers that previously
> used the short form now make it explicit that they are relying on
> global_qtest, and later patches can then clean things up to remove
> the global variable.
> 
> Signed-off-by: Eric Blake 
> ---
>  tests/libqtest.h | 50 
>  tests/libqtest.c |  6 ++--
>  tests/e1000e-test.c  |  2 +-
>  tests/fdc-test.c |  4 +--
>  tests/ide-test.c |  2 +-
>  tests/libqos/virtio.c|  8 +++---
>  tests/rtc-test.c | 74 
> 
>  tests/rtl8139-test.c | 10 +++
>  tests/tco-test.c | 22 +++---
>  tests/test-arm-mptimer.c | 25 +---
>  tests/wdt_ib700-test.c   | 12 
>  11 files changed, 90 insertions(+), 125 deletions(-)
> 
> diff --git a/tests/libqtest.h b/tests/libqtest.h
> index 5651b77d2f..26d5f37bc9 100644
> --- a/tests/libqtest.h
> +++ b/tests/libqtest.h
> @@ -417,17 +417,17 @@ void qtest_bufwrite(QTestState *s, uint64_t addr,
>  void qtest_memset(QTestState *s, uint64_t addr, uint8_t patt, size_t size);
> 
>  /**
> - * qtest_clock_step_next:
> + * clock_step_next:
>   * @s: #QTestState instance to operate on.
>   *
>   * Advance the QEMU_CLOCK_VIRTUAL to the next deadline.
>   *
>   * Returns: The current value of the QEMU_CLOCK_VIRTUAL in nanoseconds.
>   */
> -int64_t qtest_clock_step_next(QTestState *s);
> +int64_t clock_step_next(QTestState *s);
> 
>  /**
> - * qtest_clock_step:
> + * clock_step:
>   * @s: QTestState instance to operate on.
>   * @step: Number of nanoseconds to advance the clock by.
>   *
> @@ -435,10 +435,10 @@ int64_t qtest_clock_step_next(QTestState *s);
>   *
>   * Returns: The current value of the QEMU_CLOCK_VIRTUAL in nanoseconds.
>   */
> -int64_t qtest_clock_step(QTestState *s, int64_t step);
> +int64_t clock_step(QTestState *s, int64_t step);
> 
>  /**
> - * qtest_clock_set:
> + * clock_set:
>   * @s: QTestState instance to operate on.
>   * @val: Nanoseconds value to advance the clock to.
>   *
> @@ -446,7 +446,7 @@ int64_t qtest_clock_step(QTestState *s, int64_t step);
>   *
>   * Returns: The current value of the QEMU_CLOCK_VIRTUAL in nanoseconds.
>   */
> -int64_t qtest_clock_set(QTestState *s, int64_t val);
> +int64_t clock_set(QTestState *s, int64_t val);
 Could we please keep the "qtest" prefix here and rather get rid of the
other ones? Even if it's more to type, I prefer to have a proper prefix
here so that it is clear at the first sight that the functions belong to
the qtest framework.

 Thomas

Re: [Qemu-devel] [PATCH v4 15/21] s390x: print CPU definitions in sorted order

[Christian Borntraeger]

On 09/11/2017 05:21 PM, David Hildenbrand wrote:
> Other architectures provide nicely sorted lists, let's do it similarly on
> s390x.
> 
> While at it, clean up the code we have to touch either way.
> 
> Signed-off-by: David Hildenbrand 

looks much nicer now, with the most important ones (new ones) still on screen. 


Acked-by: Christian Borntraeger 


> ---
>  target/s390x/cpu_models.c | 56 
> ++-
>  1 file changed, 41 insertions(+), 15 deletions(-)
> 
> diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
> index 8e20e7637b..c295e641e6 100644
> --- a/target/s390x/cpu_models.c
> +++ b/target/s390x/cpu_models.c
> @@ -270,16 +270,11 @@ const S390CPUDef *s390_find_cpu_def(uint16_t type, 
> uint8_t gen, uint8_t ec_ga,
>  return last_compatible;
>  }
> 
> -struct S390PrintCpuListInfo {
> -FILE *f;
> -fprintf_function print;
> -};
> -
> -static void print_cpu_model_list(ObjectClass *klass, void *opaque)
> +static void s390_print_cpu_model_list_entry(gpointer data, gpointer 
> user_data)
>  {
> -struct S390PrintCpuListInfo *info = opaque;
> -S390CPUClass *scc = S390_CPU_CLASS(klass);
> -char *name = g_strdup(object_class_get_name(klass));
> +CPUListState *s = user_data;
> +const S390CPUClass *scc = S390_CPU_CLASS((ObjectClass *)data);
> +char *name = g_strdup(object_class_get_name((ObjectClass *)data));
>  const char *details = "";
> 
>  if (scc->is_static) {
> @@ -290,21 +285,52 @@ static void print_cpu_model_list(ObjectClass *klass, 
> void *opaque)
> 
>  /* strip off the -s390-cpu */
>  g_strrstr(name, "-" TYPE_S390_CPU)[0] = 0;
> -(*info->print)(info->f, "s390 %-15s %-35s %s\n", name, scc->desc,
> -   details);
> +(*s->cpu_fprintf)(s->file, "s390 %-15s %-35s %s\n", name, scc->desc,
> +  details);
>  g_free(name);
>  }
> 
> +static gint s390_cpu_list_compare(gconstpointer a, gconstpointer b)
> +{
> +const S390CPUClass *cc_a = S390_CPU_CLASS((ObjectClass *)a);
> +const S390CPUClass *cc_b = S390_CPU_CLASS((ObjectClass *)b);
> +const char *name_a = object_class_get_name((ObjectClass *)a);
> +const char *name_b = object_class_get_name((ObjectClass *)b);
> +
> +/* move qemu and host to the top of the list, qemu first, host second */
> +if (name_a[0] == 'q') {
> +return -1;
> +} else if (name_b[0] == 'q') {
> +return 1;
> +} else if (name_a[0] == 'h') {
> +return -1;
> +} else if (name_b[0] == 'h') {
> +return 1;
> +}
> +
> +/* keep the same order we have in our table (sorted by release date) */
> +if (cc_a->cpu_def != cc_b->cpu_def) {
> +return cc_a->cpu_def - cc_b->cpu_def;
> +}
> +
> +/* exact same definition - list base model first */
> +return cc_a->is_static ? -1 : 1;
> +}
> +
>  void s390_cpu_list(FILE *f, fprintf_function print)
>  {
> -struct S390PrintCpuListInfo info = {
> -.f = f,
> -.print = print,
> +CPUListState s = {
> +.file = f,
> +.cpu_fprintf = print,
>  };
>  S390FeatGroup group;
>  S390Feat feat;
> +GSList *list;
> 
> -object_class_foreach(print_cpu_model_list, TYPE_S390_CPU, false, );
> +list = object_class_get_list(TYPE_S390_CPU, false);
> +list = g_slist_sort(list, s390_cpu_list_compare);
> +g_slist_foreach(list, s390_print_cpu_model_list_entry, );
> +g_slist_free(list);
> 
>  (*print)(f, "\nRecognized feature flags:\n");
>  for (feat = 0; feat < S390_FEAT_MAX; feat++) {
> 

Re: [Qemu-devel] [PATCH for-2.10] qemu-options: Document the -drive locking parameter.

[Richard W.M. Jones]

On Tue, Sep 12, 2017 at 01:32:05PM +0200, Kevin Wolf wrote:
> Am 12.09.2017 um 11:45 hat Richard W.M. Jones geschrieben:
> > On Wed, Sep 06, 2017 at 01:38:45PM +0200, Kevin Wolf wrote:
> > > This command line fragment looks correct to me. For me, it seems to
> > > work. I'm starting a first qemu in the background with default locking
> > > options:
> > > 
> > > $ x86_64-softmmu/qemu-system-x86_64 -hda /tmp/test.qcow2
> > > 
> > > And then starting a second one with a command line resembling yours:
> > > 
> > > $ x86_64-softmmu/qemu-system-x86_64 -device virtio-scsi \
> > >   -drive 
> > > file=/tmp/test.qcow2,cache=unsafe,format=qcow2,file.locking=off,id=hd0,if=none
> > >  \
> > >   -device scsi-hd,drive=hd0
> > 
> > The problem is with overlays, where file.locking doesn't propagate to
> > the backing file.  Thus:
> > 
> >   $ qemu-system-x86_64 -drive file=backing,format=raw
> > 
> > while in another terminal:
> > 
> >   $ qemu-img create -b backing -f qcow2 overlay
> >   $ qemu-system-x86_64 -drive file=overlay,format=qcow2,file.locking=off
> >   qemu-system-x86_64: Failed to get shared "write" lock
> >   Is another process using the image?
> 
> locking=off isn't the right tool for the case. Try this:
> 
> $ qemu-system-x86_64 -drive file=overlay,if=none -device 
> virtio-blk-pci,drive=none0,share-rw=on
> 
> Unless you're doing really evil things, just telling qemu that your
> guest can cope with concurrent writers to the same image is enough. This
> propagates through the whole chain as appropriate.

Our guest certainly *cannot* cope with multiple writers to the backing
disk (file "raw" in my example).  In fact that would be a disaster.

The overlay protects the backing disk from ever seeing any writes.

In our case because the initial qemu instance (which we don't control)
opened the disk ("raw") with an exclusive lock, our only choice for
monitoring that disk is to turn off locking.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/

Re: [Qemu-devel] [Qemu-arm] [PATCH v7 05/20] hw/arm/smmuv3: Skeleton

[Linu Cherian]

On Fri Sep 08, 2017 at 05:18:19PM +0200, Auger Eric wrote:
> Hi Linu,
> 
> On 08/09/2017 12:52, Linu Cherian wrote:
> > Hi Eric,
> > 
> > On Fri Sep 01, 2017 at 07:21:08PM +0200, Eric Auger wrote:
> >> From: Prem Mallappa 
> >>
> >> This patch implements a skeleton for the smmuv3 device.
> >> Datatypes and register definitions are introduced. The MMIO
> >> region, the interrupts and the queue are initialized (PRI is
> >> not supported).
> >>
> >> Only the MMIO read operation is implemented here.
> >>
> >> Signed-off-by: Prem Mallappa 
> >> Signed-off-by: Eric Auger 
> >>
> >> ---
> >> v6 -> v7:
> >> - split into several patches
> >>
> >> v5 -> v6:
> >> - Use IOMMUMemoryregion
> >> - regs become uint32_t and fix 64b MMIO access (.impl)
> >> - trace_smmuv3_write/read_mmio take the size param
> >>
> >> v4 -> v5:
> >> - change smmuv3_translate proto (IOMMUAccessFlags flag)
> >> - has_stagex replaced by is_ste_stagex
> >> - smmu_cfg_populate removed
> >> - added smmuv3_decode_config and reworked error management
> >> - remwork the naming of IOMMU mrs
> >> - fix SMMU_CMDQ_CONS offset
> >>
> >> v3 -> v4
> >> - smmu_irq_update
> >> - fix hash key allocation
> >> - set smmu_iommu_ops
> >> - set SMMU_REG_CR0,
> >> - smmuv3_translate: ret.perm not set in bypass mode
> >> - use trace events
> >> - renamed STM2U64 into L1STD_L2PTR and STMSPAN into L1STD_SPAN
> >> - rework smmu_find_ste
> >> - fix tg2granule in TT0/0b10 corresponds to 16kB
> >>
> >> v2 -> v3:
> >> - move creation of include/hw/arm/smmuv3.h to this patch to fix compil 
> >> issue
> >> - compilation allowed
> >> - fix sbus allocation in smmu_init_pci_iommu
> >> - restructure code into headers
> >> - misc cleanups
> >> ---
> >>  hw/arm/Makefile.objs |   2 +-
> >>  hw/arm/smmuv3-internal.h | 201 +++
> >>  hw/arm/smmuv3.c  | 239 
> >> +++
> >>  hw/arm/trace-events  |   3 +
> >>  include/hw/arm/smmuv3.h  |  79 
> >>  5 files changed, 523 insertions(+), 1 deletion(-)
> >>  create mode 100644 hw/arm/smmuv3-internal.h
> >>  create mode 100644 hw/arm/smmuv3.c
> >>  create mode 100644 include/hw/arm/smmuv3.h
> >>
> >> diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
> >> index 5b2d38d..a7c808b 100644
> >> --- a/hw/arm/Makefile.objs
> >> +++ b/hw/arm/Makefile.objs
> >> @@ -19,4 +19,4 @@ obj-$(CONFIG_FSL_IMX31) += fsl-imx31.o kzm.o
> >>  obj-$(CONFIG_FSL_IMX6) += fsl-imx6.o sabrelite.o
> >>  obj-$(CONFIG_ASPEED_SOC) += aspeed_soc.o aspeed.o
> >>  obj-$(CONFIG_MPS2) += mps2.o
> >> -obj-$(CONFIG_ARM_SMMUV3) += smmu-common.o
> >> +obj-$(CONFIG_ARM_SMMUV3) += smmu-common.o smmuv3.o
> >> diff --git a/hw/arm/smmuv3-internal.h b/hw/arm/smmuv3-internal.h
> >> new file mode 100644
> >> index 000..488acc8
> >> --- /dev/null
> >> +++ b/hw/arm/smmuv3-internal.h
> >> @@ -0,0 +1,201 @@
> >> +/*
> >> + * ARM SMMUv3 support - Internal API
> >> + *
> >> + * Copyright (C) 2014-2016 Broadcom Corporation
> >> + * Copyright (c) 2017 Red Hat, Inc.
> >> + * Written by Prem Mallappa, Eric Auger
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License as published by
> >> + * the Free Software Foundation, either version 2 of the License, or
> >> + * (at your option) any later version.
> >> + *
> >> + * This program is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >> + * GNU General Public License for more details.
> >> + *
> >> + * You should have received a copy of the GNU General Public License along
> >> + * with this program; if not, see .
> >> + */
> >> +
> >> +#ifndef HW_ARM_SMMU_V3_INTERNAL_H
> >> +#define HW_ARM_SMMU_V3_INTERNAL_H
> >> +
> >> +#include "trace.h"
> >> +#include "qemu/error-report.h"
> >> +#include "hw/arm/smmu-common.h"
> >> +
> >> +/*
> >> + * MMIO Register
> >> + */
> >> +enum {
> >> +SMMU_REG_IDR0= 0x0,
> >> +
> >> +/* IDR0 Field Values and supported features */
> >> +
> >> +#define SMMU_IDR0_S2P  1  /* stage 2 */
> >> +#define SMMU_IDR0_S1P  1  /* stage 1 */
> >> +#define SMMU_IDR0_TTF  2  /* Aarch64 only - not Aarch32 (LPAE) */
> >> +#define SMMU_IDR0_COHACC   1  /* IO coherent access */
> >> +#define SMMU_IDR0_HTTU 2  /* Access and Dirty flag update */
> >> +#define SMMU_IDR0_HYP  0  /* Hypervisor Stage 1 contexts */
> >> +#define SMMU_IDR0_ATS  0  /* PCIe RC ATS */
> >> +#define SMMU_IDR0_ASID16   1  /* 16-bit ASID */
> >> +#define SMMU_IDR0_PRI  0  /* Page Request Interface */
> >> +#define SMMU_IDR0_VMID16   0  /* 16-bit VMID */
> >> +#define SMMU_IDR0_CD2L 0  /* 2-level Context Descriptor 

Re: [Qemu-devel] [PATCH v7 10/38] libqos: Move/rename qpci_unplug_acpi_device_test() to pci.c

[Thomas Huth]

On 11.09.2017 19:19, Eric Blake wrote:
> Commit 2f8b2767 originally added qpci_plug_device_test() and
> qpci_unplug_acpi_device_test() as a pair, both in pci-pc.c.
> Later, commit cf716b31 moved one half of the pair to pci.c
> when adding PPC64 support.  Keep the implementations of the
> two functions together, and shorten the name to
> qpci_unplug_device_test(), since all callers use the two
> functions in tandem.
> 
> Signed-off-by: Eric Blake 
> ---
>  tests/libqos/pci.h  |  2 +-
>  tests/e1000e-test.c |  2 +-
>  tests/ivshmem-test.c|  2 +-
>  tests/libqos/pci-pc.c   | 23 ---
>  tests/libqos/pci.c  | 23 +++
>  tests/virtio-blk-test.c |  2 +-
>  tests/virtio-net-test.c |  2 +-
>  tests/virtio-rng-test.c |  2 +-
>  8 files changed, 29 insertions(+), 29 deletions(-)
> 
> diff --git a/tests/libqos/pci.h b/tests/libqos/pci.h
> index 429c382282..fdda7eca6e 100644
> --- a/tests/libqos/pci.h
> +++ b/tests/libqos/pci.h
> @@ -111,5 +111,5 @@ QPCIBar qpci_legacy_iomap(QPCIDevice *dev, uint16_t addr);
> 
>  void qpci_plug_device_test(const char *driver, const char *id,
> uint8_t slot, const char *opts);
> -void qpci_unplug_acpi_device_test(const char *id, uint8_t slot);
> +void qpci_unplug_device_test(const char *id, uint8_t slot);
>  #endif
> diff --git a/tests/e1000e-test.c b/tests/e1000e-test.c
> index d8085d944e..4c663a3019 100644
> --- a/tests/e1000e-test.c
> +++ b/tests/e1000e-test.c
> @@ -461,7 +461,7 @@ static void test_e1000e_hotplug(gconstpointer data)
>  qtest_start("-device e1000e");
> 
>  qpci_plug_device_test("e1000e", "e1000e_net", slot, NULL);
> -qpci_unplug_acpi_device_test("e1000e_net", slot);
> +qpci_unplug_device_test("e1000e_net", slot);
> 
>  qtest_end();
>  }
> diff --git a/tests/ivshmem-test.c b/tests/ivshmem-test.c
> index 37763425ee..8c9ed6a568 100644
> --- a/tests/ivshmem-test.c
> +++ b/tests/ivshmem-test.c
> @@ -427,7 +427,7 @@ static void test_ivshmem_hotplug(void)
> 
>  qpci_plug_device_test("ivshmem", "iv1", PCI_SLOT_HP, opts);
>  if (strcmp(arch, "ppc64") != 0) {
> -qpci_unplug_acpi_device_test("iv1", PCI_SLOT_HP);
> +qpci_unplug_device_test("iv1", PCI_SLOT_HP);
>  }
> 
>  qtest_end();
> diff --git a/tests/libqos/pci-pc.c b/tests/libqos/pci-pc.c
> index e267fd1a44..6305d142a5 100644
> --- a/tests/libqos/pci-pc.c
> +++ b/tests/libqos/pci-pc.c
> @@ -19,9 +19,6 @@
>  #include "qemu-common.h"
> 
> 
> -#define ACPI_PCIHP_ADDR 0xae00
> -#define PCI_EJ_BASE 0x0008
> -
>  typedef struct QPCIBusPC
>  {
>  QPCIBus bus;
> @@ -156,23 +153,3 @@ void qpci_free_pc(QPCIBus *bus)
> 
>  g_free(s);
>  }
> -
> -void qpci_unplug_acpi_device_test(const char *id, uint8_t slot)
> -{
> -QDict *response;
> -char *cmd;
> -
> -cmd = g_strdup_printf("{'execute': 'device_del',"
> -  " 'arguments': {"
> -  "   'id': '%s'"
> -  "}}", id);
> -response = qmp(cmd);
> -g_free(cmd);
> -g_assert(response);
> -g_assert(!qdict_haskey(response, "error"));
> -QDECREF(response);
> -
> -outb(ACPI_PCIHP_ADDR + PCI_EJ_BASE, 1 << slot);
> -
> -qmp_eventwait("DEVICE_DELETED");
> -}
> diff --git a/tests/libqos/pci.c b/tests/libqos/pci.c
> index 2dcdeade2a..9f36ec73ef 100644
> --- a/tests/libqos/pci.c
> +++ b/tests/libqos/pci.c
> @@ -16,6 +16,9 @@
>  #include "hw/pci/pci_regs.h"
>  #include "qemu/host-utils.h"
> 
> +#define ACPI_PCIHP_ADDR 0xae00
> +#define PCI_EJ_BASE 0x0008
> +
>  void qpci_device_foreach(QPCIBus *bus, int vendor_id, int device_id,
>   void (*func)(QPCIDevice *dev, int devfn, void 
> *data),
>   void *data)
> @@ -412,3 +415,23 @@ void qpci_plug_device_test(const char *driver, const 
> char *id,
>  g_assert(!qdict_haskey(response, "error"));
>  QDECREF(response);
>  }
> +
> +void qpci_unplug_device_test(const char *id, uint8_t slot)
> +{
> +QDict *response;
> +char *cmd;
> +
> +cmd = g_strdup_printf("{'execute': 'device_del',"
> +  " 'arguments': {"
> +  "   'id': '%s'"
> +  "}}", id);
> +response = qmp(cmd);
> +g_free(cmd);
> +g_assert(response);
> +g_assert(!qdict_haskey(response, "error"));
> +QDECREF(response);
> +
> +outb(ACPI_PCIHP_ADDR + PCI_EJ_BASE, 1 << slot);
> +
> +qmp_eventwait("DEVICE_DELETED");
> +}

No, that's a bad idea. ACPI and that outb() is clearly something
specific to x86, so this should not reside in pci.c but in pci-pc.c

We might be able to unify this - I've had a similar patch here:

 https://patchwork.kernel.org/patch/9905031/

... but I think this needs some more careful thinking and discussion, so
I'd suggest that you remove this from your already huge patch series for
now and we fix it later instead.

 Thomas

Re: [Qemu-devel] [PATCH] test-qga: add missing qemu-ga tool dependency

[Paolo Bonzini]

On 11/09/2017 23:01, Philippe Mathieu-Daudé wrote:
> this fixes running 'make check-unit' without running 'make all' beforehand:
> 
> $ make check-unit
>   ...
>   GTESTER tests/test-qga
> **
> ERROR:tests/test-qga.c:73:fixture_setup: assertion failed (error == NULL): 
> Failed to execute child process "/build/qemu/qemu-ga" (No such file or 
> directory) (g-exec-error-quark, 8)

Queued, thanks.

Paolo

> make: *** [check-tests/test-qga] Error 1
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> occured trying to split Travis jobs to run more/faster
> 
>  tests/Makefile.include | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/Makefile.include b/tests/Makefile.include
> index fae5715e9c..59e027f6ea 100644
> --- a/tests/Makefile.include
> +++ b/tests/Makefile.include
> @@ -832,7 +832,8 @@ endif
>  qtest-obj-y = tests/libqtest.o $(test-util-obj-y)
>  $(check-qtest-y): $(qtest-obj-y)
>  
> -tests/test-qga: tests/test-qga.o $(qtest-obj-y)
> +tests/test-qga$(EXESUF): qemu-ga$(EXESUF)
> +tests/test-qga$(EXESUF): tests/test-qga.o $(qtest-obj-y)
>  
>  SPEED = quick
>  GTESTER_OPTIONS = -k $(if $(V),--verbose,-q)
> 

Re: [Qemu-devel] [PATCH] tcg/tci: do not use ldst label (never implemented)

[Stefan Weil]

Am 11.09.2017 um 20:24 schrieb Peter Maydell:
> I've also turned on a tci compile check on my pre-merge tests.
> (It doesn't pass "make check" for me, though...) thanks -- PMM

"make check-qtest-ppc64" fails for me, too.

Thomas, this seems to be again the well known timing problem
in tests/prom-env-test.c. The time for the test had been
changedfrom 30 s to 10 s to 120 s in the past.

For TCI, even that latest value isnot sufficient when
testing with pseries. Of course that also depends on other
parameters (speed of test machine, compilerflags).

In my test pseries took nearly 5 minutes, so the test passes
when the loop upper limit is increased to 3.

Is there a better way to handle this test? Why does pseries
still need much more time than the other machines
(not only with TCI)?

Regards,
Stefan

Re: [Qemu-devel] [PATCH v7 14/38] libqos: Use explicit QTestState for rtas operations

[Thomas Huth]

On 11.09.2017 19:19, Eric Blake wrote:
> Drop one more client of global_qtest by teaching all rtas test
> functionality to pass in an explicit QTestState, adjusting all
> callers.
> 
> Signed-off-by: Eric Blake 
> 
> ---
> v7: catch a couple more operations, drop R-b
> ---
>  tests/libqos/rtas.h  |  9 ++---
>  tests/libqos/pci-spapr.c | 18 --
>  tests/libqos/rtas.c  | 36 
>  tests/rtas-test.c|  2 +-
>  4 files changed, 39 insertions(+), 26 deletions(-)
> 
> diff --git a/tests/libqos/rtas.h b/tests/libqos/rtas.h
> index 498eb19230..e3d0f850a7 100644
> --- a/tests/libqos/rtas.h
> +++ b/tests/libqos/rtas.h
> @@ -7,9 +7,12 @@
>  #define LIBQOS_RTAS_H
>  #include "libqos/malloc.h"
> 
> -int qrtas_get_time_of_day(QGuestAllocator *alloc, struct tm *tm, uint32_t 
> *ns);
> -uint32_t qrtas_ibm_read_pci_config(QGuestAllocator *alloc, uint64_t buid,
> +int qrtas_get_time_of_day(QTestState *qts, QGuestAllocator *alloc,
> +  struct tm *tm, uint32_t *ns);
> +uint32_t qrtas_ibm_read_pci_config(QTestState *qts, QGuestAllocator *alloc,
> +   uint64_t buid,
> uint32_t addr, uint32_t size);
> -int qrtas_ibm_write_pci_config(QGuestAllocator *alloc, uint64_t buid,
> +int qrtas_ibm_write_pci_config(QTestState *qts, QGuestAllocator *alloc,
> +   uint64_t buid,
> uint32_t addr, uint32_t size, uint32_t val);

Nit: I'd prefer if you rather put hte "uint32_t val" on a separate line
instead of the "buid".

[...]
> @@ -92,7 +95,8 @@ uint32_t qrtas_ibm_read_pci_config(QGuestAllocator *alloc, 
> uint64_t buid,
>  return ret[1];
>  }
> 
> -int qrtas_ibm_write_pci_config(QGuestAllocator *alloc, uint64_t buid,
> +int qrtas_ibm_write_pci_config(QTestState *qts, QGuestAllocator *alloc,
> +   uint64_t buid,
> uint32_t addr, uint32_t size, uint32_t val)

dito

>  {
>  int res;
> @@ -103,7 +107,7 @@ int qrtas_ibm_write_pci_config(QGuestAllocator *alloc, 
> uint64_t buid,
>  args[2] = buid & 0x;
>  args[3] = size;
>  args[4] = val;
> -res = qrtas_call(alloc, "ibm,write-pci-config", 5, args, 1, ret);
> +res = qrtas_call(qts, alloc, "ibm,write-pci-config", 5, args, 1, ret);
>  if (res != 0) {
>  return -1;
>  }
> diff --git a/tests/rtas-test.c b/tests/rtas-test.c
> index 276c87ef84..34a692163f 100644
> --- a/tests/rtas-test.c
> +++ b/tests/rtas-test.c
> @@ -16,7 +16,7 @@ static void test_rtas_get_time_of_day(void)
>  qs = qtest_spapr_boot("-machine pseries");
> 
>  t1 = time(NULL);
> -ret = qrtas_get_time_of_day(qs->alloc, , );
> +ret = qrtas_get_time_of_day(qs->qts, qs->alloc, , );
>  g_assert_cmpint(ret, ==, 0);
>  t2 = mktimegm();
>  g_assert(t2 - t1 < 5); /* 5 sec max to run the test */
> 

Reviewed-by: Thomas Huth 

Re: [Qemu-devel] [PATCH 02/27] libvhost-user: drop dependency on glib

[Philippe Mathieu-Daudé]

Hi Marc-André,

On 08/23/2017 01:19 PM, Marc-André Lureau wrote:

libvhost-user is meant to be free of glib dependency. Make sure it is
by droping qemu/osdep.h (which included glib.h)

This fixes a bad malloc()/g_free() pair.

Signed-off-by: Marc-André Lureau 
---
  contrib/libvhost-user/libvhost-user.c | 25 ++---
  1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/contrib/libvhost-user/libvhost-user.c 
b/contrib/libvhost-user/libvhost-user.c
index 35fa0c5e56..bb294c6ef7 100644
--- a/contrib/libvhost-user/libvhost-user.c
+++ b/contrib/libvhost-user/libvhost-user.c
@@ -13,11 +13,22 @@
   * later.  See the COPYING file in the top-level directory.
   */
  
-#include 

+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
  #include 
+#include 
  #include 
  
  #include "qemu/atomic.h"

+#include "qemu/compiler.h"
  
  #include "libvhost-user.h"
  
@@ -34,6 +45,14 @@

  }   \
  } while (0)
  
+#ifndef MIN

+#define MIN(x, y) ({\
+typeof(x) _min1 = (x);  \
+typeof(y) _min2 = (y);  \
+(void) (&_min1 == &_min2);  \
+_min1 < _min2 ? _min1 : _min2; })


why not add this in qemu/compiler.h instead?


+#endif
+
  static const char *
  vu_request_to_string(int req)
  {
@@ -81,7 +100,7 @@ vu_panic(VuDev *dev, const char *msg, ...)
  va_list ap;
  
  va_start(ap, msg);

-buf = g_strdup_vprintf(msg, ap);
+vasprintf(, msg, ap);
  va_end(ap);
  
  dev->broken = true;

@@ -840,7 +859,7 @@ vu_dispatch(VuDev *dev)
  success = true;
  
  end:

-g_free(vmsg.data);
+free(vmsg.data);
  return success;
  }
  

Re: [Qemu-devel] [PATCH 07/12] qemu-iotests: disintegrate more parts of common.config

[Paolo Bonzini]

On 12/09/2017 12:40, Kevin Wolf wrote:
> Am 09.08.2017 um 23:55 hat Paolo Bonzini geschrieben:
>> Split "check" parts from tests part.
>>
>> For the directory setup, the actual computation of directories goes
>> in "check", while the sanity checks go in the tests.
>>
>> Signed-off-by: Paolo Bonzini 
> 
> Same comment as for patch 1, we may want to keep this working.

Can you explain what is the use case?  For local symlinks I (sort of)
understand it, but not here.  This as far as I understand is code that
never runs.

My preferred alternatives would be one of these:

- add a patch 13 that restores the local symlink feature on top of the
cleaned up code.

- later, rewrite "check" in Python now that it is clear what code is
part of it and what code is part of the tests.

or:

- leave local symlinks broken

- when "check" is rewritten in Python, add a configuration mechanism
based on .ini file syntax that replaces the local symlinks.

What do you think?

Paolo

[Qemu-devel] [PATCH v5 00/12] Convert over to use keycodemapdb

[Daniel P. Berrange]

An update of:

  v1: https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg02047.html
  v2: https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg02471.html
  v3: https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg02517.html
  v4: https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg02708.html

The keycodemap project[1] provides a database mapping between many different
keysym/keycode/scancode sets, along with a tool to generate mapping/lookup
tables in various programming languages. It is already used by GTK-VNC,
SPICE-GTK and libvirt.

This series enables its use in QEMU, thus fixing a great many bugs/ommissions
in the 15+ key mapping tables people have manually written for QEMU.

The keycodemapdb code is designed to be used as a git sub-module, it is
not an external dependancy you need installed before use. In this version,
however, the sub-module is not directly use. Instead all the generated
files are checked into GIT. The downside to this is that we get an
enourmous pile of errors from checkpatch.pl. The tool that generates the
mapping files doesn't care about QEMU's coding style rules, because it is
a general purpose tool intended for use by many different projects.

As such I'm not very happy about the idea of checking the generated files into
GIT, and would prefer to go back to generating the files from the submodule
on every build, as was done in v4. I did this this in v5 way to illustrate the
approach, but on balance I think v4 approach was better. Using the v4 approach
would also means when updating the submodule later on, we don't have to post
largely meaningless patches of diffs to all the generated files.

This series converts all the front ends and all the input devices which are
using the new InputEvent framework. A handful of devices still use the
legacy kbd handler

  $ git grep -l add_kbd_event_handler hw
  hw/arm/musicpal.c
  hw/arm/nseries.c
  hw/arm/palm.c
  hw/arm/spitz.c
  hw/input/pxa2xx_keypad.c
  hw/input/stellaris_input.c

and could be usefully converted too.

I've not done much realworld testing of this yet. I did however write code
that compared the mapping tables before and after conversion to identify what
mapping changes have resulted in each frontend/backend.  What I still need to
go back and validate is the Print/Sysrq handling, because that is special
everywhere and I'm not entirely sure I've done that correctly yet. The GTK
frontend should now work correctly when run on X11 servers on Win32 and OS-X,
as well as when run on native Win32/OS-X display backends.

[1] https://gitlab.com/keycodemap/keycodemapdb/

Changed in v5:

 - Don't try to initialize git submodule at all
 - Store generate keymap files in GIT

Changed in v4:

 - Run submodule update in source_dir for vpath builds (patchew)
 - Force submodule update in docker rules in case they
   are run without configure (patchew)

Changed in v3:

 - Ensure docker builds pull in keycodemapdb submodule (patchew)
 - Add compat with py26 for RHEL-6 in keycodemapdb tools (patchew)
 - Initialize submodule in configure script (patchew)

Changed in v2:

 - Change filename pattern to 'ui/input-keymap-$SRC-to-$DST.c'
   and map names 'qemu_input_map_$SRC_to_$DST'  (Eric)
 - Fix typos (Eric)
 - Drop changes to InputKeyEvent struct (Eric)
 - Fix VPATH build (patchew)
 - Fix code style errors (patchew)


Daniel P. Berrange (12):
  ui: add keycodemapdb repository as a GIT submodule
  ui: convert common input code to keycodemapdb
  ui: convert key events to QKeyCodes immediately
  ui: don't export qemu_input_event_new_key
  input: convert virtio-input-hid device to keycodemapdb
  input: convert ps2 device to keycodemapdb
  input: convert the adb device to keycodemapdb
  char: convert the escc device to keycodemapdb
  ui: convert cocoa frontend to keycodemapdb
  ui: convert the SDL2 frontend to keycodemapdb
  ui: convert GTK and SDL1 frontends to keycodemapdb
  display: convert XenInput keyboard to keycodemapdb

 .gitmodules|   3 +
 hw/char/escc.c | 126 +
 hw/display/xenfb.c | 133 +++---
 hw/input/adb.c | 124 +
 hw/input/ps2.c | 406 +
 hw/input/virtio-input-hid.c| 136 +-
 include/hw/input/adb-keys.h| 141 --
 include/ui/input.h |  57 +++-
 ui/Makefile.objs   |  43 ++-
 ui/cocoa.m | 129 +
 ui/gtk.c   | 205 +--
 ui/input-keymap-atset1-to-qcode.c  | 245 +
 ui/input-keymap-linux-to-qcode.c   | 463 +
 ui/input-keymap-osx-to-qcode.c | 128 +
 ui/input-keymap-qcode-to-adb.c | 156 +++
 ui/input-keymap-qcode-to-atset1.c  | 154 +++
 ui/input-keymap-qcode-to-atset2.c  | 142 ++
 

[Qemu-devel] [PATCH v5 03/12] ui: convert key events to QKeyCodes immediately

[Daniel P. Berrange]

Always use QKeyCode in the InputKeyEvent struct, by converting key
numbers to QKeyCode at the time the event is created.

Signed-off-by: Daniel P. Berrange 
---
 ui/input.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/ui/input.c b/ui/input.c
index 3422d4a8ef..9914daf0b4 100644
--- a/ui/input.c
+++ b/ui/input.c
@@ -400,10 +400,8 @@ void qemu_input_event_send_key(QemuConsole *src, KeyValue 
*key, bool down)
 
 void qemu_input_event_send_key_number(QemuConsole *src, int num, bool down)
 {
-KeyValue *key = g_new0(KeyValue, 1);
-key->type = KEY_VALUE_KIND_NUMBER;
-key->u.number.data = num;
-qemu_input_event_send_key(src, key, down);
+QKeyCode code = qemu_input_key_number_to_qcode(num);
+qemu_input_event_send_key_qcode(src, code, down);
 }
 
 void qemu_input_event_send_key_qcode(QemuConsole *src, QKeyCode q, bool down)
-- 
2.13.5

[Qemu-devel] [PATCH v5 01/12] ui: add keycodemapdb repository as a GIT submodule

[Daniel P. Berrange]

The https://gitlab.com/keycodemap/keycodemapdb/ repo contains a
data file mapping between all the different scancode/keycode/keysym
sets that are known, and a tool to auto-generate lookup tables for
different combinations.

It is used by GTK-VNC, SPICE-GTK and libvirt for mapping keys.
Using it in QEMU will let us replace many hand written lookup
tables with auto-generated tables from a master data source,
reducing bugs. Adding new QKeyCodes will now only require the
master table to be updated, all ~20 other tables will be
automatically updated to follow.

Signed-off-by: Daniel P. Berrange 
---
 .gitmodules  |  3 +++
 ui/Makefile.objs | 20 
 ui/keycodemapdb  |  1 +
 3 files changed, 24 insertions(+)
 create mode 16 ui/keycodemapdb

diff --git a/.gitmodules b/.gitmodules
index 5b0c212622..369989f19e 100644
--- a/.gitmodules
+++ b/.gitmodules
@@ -37,3 +37,6 @@
 [submodule "roms/QemuMacDrivers"]
path = roms/QemuMacDrivers
url = git://git.qemu.org/QemuMacDrivers.git
+[submodule "ui/keycodemapdb"]
+   path = ui/keycodemapdb
+   url = https://gitlab.com/keycodemap/keycodemapdb.git
diff --git a/ui/Makefile.objs b/ui/Makefile.objs
index 3369451285..5fcb3010b3 100644
--- a/ui/Makefile.objs
+++ b/ui/Makefile.objs
@@ -49,3 +49,23 @@ gtk-egl.o-libs += $(OPENGL_LIBS)
 shader.o-libs += $(OPENGL_LIBS)
 console-gl.o-libs += $(OPENGL_LIBS)
 egl-helpers.o-libs += $(OPENGL_LIBS)
+
+KEYCODEMAP_GEN = $(SRC_PATH)/ui/keycodemapdb/tools/keymap-gen
+KEYCODEMAP_CSV = $(SRC_PATH)/ui/keycodemapdb/data/keymaps.csv
+
+KEYCODEMAP_FILES = \
+$(NULL)
+
+# Generated input-keymap-XXX.c files are kept in GIT, so
+# the rule below is not normally run. It is only used when
+# the submodule is explicitly updated.
+
+ui/input-keymap-%.c: $(KEYCODEMAP_GEN) $(KEYCODEMAP_CSV) 
$(SRC_PATH)/ui/Makefile.objs
+   $(call quiet-command,\
+   src=$$(echo $@ | sed -E -e 
"s,^ui/input-keymap-(.+)-to-(.+)\.c$$,\1,") && \
+   dst=$$(echo $@ | sed -E -e 
"s,^ui/input-keymap-(.+)-to-(.+)\.c$$,\2,") && \
+   $(PYTHON) $(KEYCODEMAP_GEN) \
+ --lang glib2 \
+ --varname qemu_input_map_$${src}_to_$${dst} \
+ code-map $(KEYCODEMAP_CSV) $${src} $${dst} \
+   > $@ || rm $@, "GEN", "$@")
diff --git a/ui/keycodemapdb b/ui/keycodemapdb
new file mode 16
index 00..56ce5650d2
--- /dev/null
+++ b/ui/keycodemapdb
@@ -0,0 +1 @@
+Subproject commit 56ce5650d2c6ea216b4580df44b9a6dd3bc92c3b
-- 
2.13.5

[Qemu-devel] [PATCH v5 10/12] ui: convert the SDL2 frontend to keycodemapdb

[Daniel P. Berrange]

The SDL2 scancodes are conveniently identical to the USB
scancodes. Replace the sdl2_scancode_to_qcode table with
an automatically generated table.

Missing entries in sdl2_scancode_to_qcode now fixed:

  - 0x32 -> Q_KEY_CODE_BACKSLASH
  - 0x66 -> Q_KEY_CODE_POWER
  - 0x67 -> Q_KEY_CODE_KP_EQUALS
  - 0x74 -> Q_KEY_CODE_OPEN
  - 0x77 -> Q_KEY_CODE_FRONT
  - 0x7f -> Q_KEY_CODE_AUDIOMUTE
  - 0x80 -> Q_KEY_CODE_VOLUMEUP
  - 0x81 -> Q_KEY_CODE_VOLUMEDOWN
  - 0x85 -> Q_KEY_CODE_KP_COMMA
  - 0x87 -> Q_KEY_CODE_RO
  - 0x89 -> Q_KEY_CODE_YEN
  - 0x8a -> Q_KEY_CODE_HENKAN
  - 0x93 -> Q_KEY_CODE_HIRAGANA
  - 0xe8 -> Q_KEY_CODE_AUDIOPLAY
  - 0xe9 -> Q_KEY_CODE_AUDIOSTOP
  - 0xea -> Q_KEY_CODE_AUDIOPREV
  - 0xeb -> Q_KEY_CODE_AUDIONEXT
  - 0xed -> Q_KEY_CODE_VOLUMEUP
  - 0xee -> Q_KEY_CODE_VOLUMEDOWN
  - 0xef -> Q_KEY_CODE_AUDIOMUTE
  - 0xf1 -> Q_KEY_CODE_AC_BACK
  - 0xf2 -> Q_KEY_CODE_AC_FORWARD
  - 0xf3 -> Q_KEY_CODE_STOP
  - 0xf4 -> Q_KEY_CODE_FIND
  - 0xf8 -> Q_KEY_CODE_SLEEP
  - 0xfa -> Q_KEY_CODE_AC_REFRESH
  - 0xfb -> Q_KEY_CODE_CALCULATOR

And some mistakes corrected:

  - 0x65 -> Q_KEY_CODE_COMPOSE, not duplicating Q_KEY_CODE_MENU

Signed-off-by: Daniel P. Berrange 
---
 include/ui/input.h |   3 +
 ui/Makefile.objs   |   1 +
 ui/input-keymap-usb-to-qcode.c | 177 +++
 ui/input-keymap.c  |   1 +
 ui/sdl2-input.c|  16 ++-
 ui/sdl2-keymap.h   | 267 -
 6 files changed, 193 insertions(+), 272 deletions(-)
 create mode 100644 ui/input-keymap-usb-to-qcode.c
 delete mode 100644 ui/sdl2-keymap.h

diff --git a/include/ui/input.h b/include/ui/input.h
index df3eb439bf..dcf7e0e731 100644
--- a/include/ui/input.h
+++ b/include/ui/input.h
@@ -98,4 +98,7 @@ extern const guint16 qemu_input_map_qcode_to_sun[];
 extern const guint qemu_input_map_qnum_to_qcode_len;
 extern const guint16 qemu_input_map_qnum_to_qcode[];
 
+extern const guint qemu_input_map_usb_to_qcode_len;
+extern const guint16 qemu_input_map_usb_to_qcode[];
+
 #endif /* INPUT_H */
diff --git a/ui/Makefile.objs b/ui/Makefile.objs
index 9cf398e5c6..7823e85d7c 100644
--- a/ui/Makefile.objs
+++ b/ui/Makefile.objs
@@ -64,6 +64,7 @@ KEYCODEMAP_FILES = \
 ui/input-keymap-qcode-to-qnum.c \
 ui/input-keymap-qcode-to-sun.c \
 ui/input-keymap-qnum-to-qcode.c \
+ui/input-keymap-usb-to-qcode.c \
 $(NULL)
 
 # Generated input-keymap-XXX.c files are kept in GIT, so
diff --git a/ui/input-keymap-usb-to-qcode.c b/ui/input-keymap-usb-to-qcode.c
new file mode 100644
index 00..b63c351ec7
--- /dev/null
+++ b/ui/input-keymap-usb-to-qcode.c
@@ -0,0 +1,177 @@
+/*
+ * This file is auto-generated from keymaps.csv on 2017-08-31 11:08
+ * Database checksum 
sha256(f8aeff0c3430077a350e3d7ba2b335b381bd929ac4b193413730a402ff3f0097)
+ * To re-generate, run:
+ *   keymap-gen --lang=glib2 --varname=qemu_input_map_usb_to_qcode code-map 
keymaps.csv usb qcode
+*/
+const guint16 qemu_input_map_usb_to_qcode[252] = {
+  [0x4] = Q_KEY_CODE_A, /* usb:4 -> linux:30 (KEY_A) -> qcode:Q_KEY_CODE_A (a) 
*/
+  [0x5] = Q_KEY_CODE_B, /* usb:5 -> linux:48 (KEY_B) -> qcode:Q_KEY_CODE_B (b) 
*/
+  [0x6] = Q_KEY_CODE_C, /* usb:6 -> linux:46 (KEY_C) -> qcode:Q_KEY_CODE_C (c) 
*/
+  [0x7] = Q_KEY_CODE_D, /* usb:7 -> linux:32 (KEY_D) -> qcode:Q_KEY_CODE_D (d) 
*/
+  [0x8] = Q_KEY_CODE_E, /* usb:8 -> linux:18 (KEY_E) -> qcode:Q_KEY_CODE_E (e) 
*/
+  [0x9] = Q_KEY_CODE_F, /* usb:9 -> linux:33 (KEY_F) -> qcode:Q_KEY_CODE_F (f) 
*/
+  [0xa] = Q_KEY_CODE_G, /* usb:10 -> linux:34 (KEY_G) -> qcode:Q_KEY_CODE_G 
(g) */
+  [0xb] = Q_KEY_CODE_H, /* usb:11 -> linux:35 (KEY_H) -> qcode:Q_KEY_CODE_H 
(h) */
+  [0xc] = Q_KEY_CODE_I, /* usb:12 -> linux:23 (KEY_I) -> qcode:Q_KEY_CODE_I 
(i) */
+  [0xd] = Q_KEY_CODE_J, /* usb:13 -> linux:36 (KEY_J) -> qcode:Q_KEY_CODE_J 
(j) */
+  [0xe] = Q_KEY_CODE_K, /* usb:14 -> linux:37 (KEY_K) -> qcode:Q_KEY_CODE_K 
(k) */
+  [0xf] = Q_KEY_CODE_L, /* usb:15 -> linux:38 (KEY_L) -> qcode:Q_KEY_CODE_L 
(l) */
+  [0x10] = Q_KEY_CODE_M, /* usb:16 -> linux:50 (KEY_M) -> qcode:Q_KEY_CODE_M 
(m) */
+  [0x11] = Q_KEY_CODE_N, /* usb:17 -> linux:49 (KEY_N) -> qcode:Q_KEY_CODE_N 
(n) */
+  [0x12] = Q_KEY_CODE_O, /* usb:18 -> linux:24 (KEY_O) -> qcode:Q_KEY_CODE_O 
(o) */
+  [0x13] = Q_KEY_CODE_P, /* usb:19 -> linux:25 (KEY_P) -> qcode:Q_KEY_CODE_P 
(p) */
+  [0x14] = Q_KEY_CODE_Q, /* usb:20 -> linux:16 (KEY_Q) -> qcode:Q_KEY_CODE_Q 
(q) */
+  [0x15] = Q_KEY_CODE_R, /* usb:21 -> linux:19 (KEY_R) -> qcode:Q_KEY_CODE_R 
(r) */
+  [0x16] = Q_KEY_CODE_S, /* usb:22 -> linux:31 (KEY_S) -> qcode:Q_KEY_CODE_S 
(s) */
+  [0x17] = Q_KEY_CODE_T, /* usb:23 -> linux:20 (KEY_T) -> qcode:Q_KEY_CODE_T 
(t) */
+  [0x18] = Q_KEY_CODE_U, /* usb:24 -> linux:22 (KEY_U) -> qcode:Q_KEY_CODE_U 
(u) */
+  [0x19] = Q_KEY_CODE_V, /* usb:25 -> linux:47 (KEY_V) -> qcode:Q_KEY_CODE_V 
(v) */
+  [0x1a] = 

[Qemu-devel] [PATCH v5 04/12] ui: don't export qemu_input_event_new_key

[Daniel P. Berrange]

All public code should use qemu_input_event_send_key* functions
instead of creating an event directly.

Signed-off-by: Daniel P. Berrange 
---
 include/ui/input.h | 1 -
 ui/input.c | 2 +-
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/include/ui/input.h b/include/ui/input.h
index 479cc46cfc..f8cee43f65 100644
--- a/include/ui/input.h
+++ b/include/ui/input.h
@@ -38,7 +38,6 @@ void qemu_input_event_send_impl(QemuConsole *src, InputEvent 
*evt);
 void qemu_input_event_sync(void);
 void qemu_input_event_sync_impl(void);
 
-InputEvent *qemu_input_event_new_key(KeyValue *key, bool down);
 void qemu_input_event_send_key(QemuConsole *src, KeyValue *key, bool down);
 void qemu_input_event_send_key_number(QemuConsole *src, int num, bool down);
 void qemu_input_event_send_key_qcode(QemuConsole *src, QKeyCode q, bool down);
diff --git a/ui/input.c b/ui/input.c
index 9914daf0b4..23f9f2c5e0 100644
--- a/ui/input.c
+++ b/ui/input.c
@@ -374,7 +374,7 @@ void qemu_input_event_sync(void)
 replay_input_sync_event();
 }
 
-InputEvent *qemu_input_event_new_key(KeyValue *key, bool down)
+static InputEvent *qemu_input_event_new_key(KeyValue *key, bool down)
 {
 InputEvent *evt = g_new0(InputEvent, 1);
 evt->u.key.data = g_new0(InputKeyEvent, 1);
-- 
2.13.5

[Qemu-devel] [PATCH v5 09/12] ui: convert cocoa frontend to keycodemapdb

[Daniel P. Berrange]

Replace the mac_to_qkeycode_map table with automatically
generated table.

Signed-off-by: Daniel P. Berrange 
---
 include/ui/input.h |   3 +
 ui/Makefile.objs   |   1 +
 ui/cocoa.m | 129 +
 ui/input-keymap-osx-to-qcode.c | 128 
 ui/input-keymap.c  |   1 +
 5 files changed, 135 insertions(+), 127 deletions(-)
 create mode 100644 ui/input-keymap-osx-to-qcode.c

diff --git a/include/ui/input.h b/include/ui/input.h
index 4ba7340b7b..df3eb439bf 100644
--- a/include/ui/input.h
+++ b/include/ui/input.h
@@ -71,6 +71,9 @@ void qemu_remove_mouse_mode_change_notifier(Notifier *notify);
 extern const guint qemu_input_map_linux_to_qcode_len;
 extern const guint16 qemu_input_map_linux_to_qcode[];
 
+extern const guint qemu_input_map_osx_to_qcode_len;
+extern const guint16 qemu_input_map_osx_to_qcode[];
+
 extern const guint qemu_input_map_qcode_to_adb_len;
 extern const guint16 qemu_input_map_qcode_to_adb[];
 
diff --git a/ui/Makefile.objs b/ui/Makefile.objs
index 3cd1122ea9..9cf398e5c6 100644
--- a/ui/Makefile.objs
+++ b/ui/Makefile.objs
@@ -55,6 +55,7 @@ KEYCODEMAP_CSV = $(SRC_PATH)/ui/keycodemapdb/data/keymaps.csv
 
 KEYCODEMAP_FILES = \
 ui/input-keymap-linux-to-qcode.c \
+ui/input-keymap-osx-to-qcode.c \
 ui/input-keymap-qcode-to-adb.c \
 ui/input-keymap-qcode-to-atset1.c \
 ui/input-keymap-qcode-to-atset2.c \
diff --git a/ui/cocoa.m b/ui/cocoa.m
index 93e56d0518..e966605914 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -106,139 +106,14 @@ bool stretch_video;
 NSTextField *pauseLabel;
 NSArray * supportedImageFileTypes;
 
-// Mac to QKeyCode conversion
-const int mac_to_qkeycode_map[] = {
-[kVK_ANSI_A] = Q_KEY_CODE_A,
-[kVK_ANSI_B] = Q_KEY_CODE_B,
-[kVK_ANSI_C] = Q_KEY_CODE_C,
-[kVK_ANSI_D] = Q_KEY_CODE_D,
-[kVK_ANSI_E] = Q_KEY_CODE_E,
-[kVK_ANSI_F] = Q_KEY_CODE_F,
-[kVK_ANSI_G] = Q_KEY_CODE_G,
-[kVK_ANSI_H] = Q_KEY_CODE_H,
-[kVK_ANSI_I] = Q_KEY_CODE_I,
-[kVK_ANSI_J] = Q_KEY_CODE_J,
-[kVK_ANSI_K] = Q_KEY_CODE_K,
-[kVK_ANSI_L] = Q_KEY_CODE_L,
-[kVK_ANSI_M] = Q_KEY_CODE_M,
-[kVK_ANSI_N] = Q_KEY_CODE_N,
-[kVK_ANSI_O] = Q_KEY_CODE_O,
-[kVK_ANSI_P] = Q_KEY_CODE_P,
-[kVK_ANSI_Q] = Q_KEY_CODE_Q,
-[kVK_ANSI_R] = Q_KEY_CODE_R,
-[kVK_ANSI_S] = Q_KEY_CODE_S,
-[kVK_ANSI_T] = Q_KEY_CODE_T,
-[kVK_ANSI_U] = Q_KEY_CODE_U,
-[kVK_ANSI_V] = Q_KEY_CODE_V,
-[kVK_ANSI_W] = Q_KEY_CODE_W,
-[kVK_ANSI_X] = Q_KEY_CODE_X,
-[kVK_ANSI_Y] = Q_KEY_CODE_Y,
-[kVK_ANSI_Z] = Q_KEY_CODE_Z,
-
-[kVK_ANSI_0] = Q_KEY_CODE_0,
-[kVK_ANSI_1] = Q_KEY_CODE_1,
-[kVK_ANSI_2] = Q_KEY_CODE_2,
-[kVK_ANSI_3] = Q_KEY_CODE_3,
-[kVK_ANSI_4] = Q_KEY_CODE_4,
-[kVK_ANSI_5] = Q_KEY_CODE_5,
-[kVK_ANSI_6] = Q_KEY_CODE_6,
-[kVK_ANSI_7] = Q_KEY_CODE_7,
-[kVK_ANSI_8] = Q_KEY_CODE_8,
-[kVK_ANSI_9] = Q_KEY_CODE_9,
-
-[kVK_ANSI_Grave] = Q_KEY_CODE_GRAVE_ACCENT,
-[kVK_ANSI_Minus] = Q_KEY_CODE_MINUS,
-[kVK_ANSI_Equal] = Q_KEY_CODE_EQUAL,
-[kVK_Delete] = Q_KEY_CODE_BACKSPACE,
-[kVK_CapsLock] = Q_KEY_CODE_CAPS_LOCK,
-[kVK_Tab] = Q_KEY_CODE_TAB,
-[kVK_Return] = Q_KEY_CODE_RET,
-[kVK_ANSI_LeftBracket] = Q_KEY_CODE_BRACKET_LEFT,
-[kVK_ANSI_RightBracket] = Q_KEY_CODE_BRACKET_RIGHT,
-[kVK_ANSI_Backslash] = Q_KEY_CODE_BACKSLASH,
-[kVK_ANSI_Semicolon] = Q_KEY_CODE_SEMICOLON,
-[kVK_ANSI_Quote] = Q_KEY_CODE_APOSTROPHE,
-[kVK_ANSI_Comma] = Q_KEY_CODE_COMMA,
-[kVK_ANSI_Period] = Q_KEY_CODE_DOT,
-[kVK_ANSI_Slash] = Q_KEY_CODE_SLASH,
-[kVK_Shift] = Q_KEY_CODE_SHIFT,
-[kVK_RightShift] = Q_KEY_CODE_SHIFT_R,
-[kVK_Control] = Q_KEY_CODE_CTRL,
-[kVK_RightControl] = Q_KEY_CODE_CTRL_R,
-[kVK_Option] = Q_KEY_CODE_ALT,
-[kVK_RightOption] = Q_KEY_CODE_ALT_R,
-[kVK_Command] = Q_KEY_CODE_META_L,
-[0x36] = Q_KEY_CODE_META_R, /* There is no kVK_RightCommand */
-[kVK_Space] = Q_KEY_CODE_SPC,
-
-[kVK_ANSI_Keypad0] = Q_KEY_CODE_KP_0,
-[kVK_ANSI_Keypad1] = Q_KEY_CODE_KP_1,
-[kVK_ANSI_Keypad2] = Q_KEY_CODE_KP_2,
-[kVK_ANSI_Keypad3] = Q_KEY_CODE_KP_3,
-[kVK_ANSI_Keypad4] = Q_KEY_CODE_KP_4,
-[kVK_ANSI_Keypad5] = Q_KEY_CODE_KP_5,
-[kVK_ANSI_Keypad6] = Q_KEY_CODE_KP_6,
-[kVK_ANSI_Keypad7] = Q_KEY_CODE_KP_7,
-[kVK_ANSI_Keypad8] = Q_KEY_CODE_KP_8,
-[kVK_ANSI_Keypad9] = Q_KEY_CODE_KP_9,
-[kVK_ANSI_KeypadDecimal] = Q_KEY_CODE_KP_DECIMAL,
-[kVK_ANSI_KeypadEnter] = Q_KEY_CODE_KP_ENTER,
-[kVK_ANSI_KeypadPlus] = Q_KEY_CODE_KP_ADD,
-[kVK_ANSI_KeypadMinus] = Q_KEY_CODE_KP_SUBTRACT,
-[kVK_ANSI_KeypadMultiply] = Q_KEY_CODE_KP_MULTIPLY,
-[kVK_ANSI_KeypadDivide] = Q_KEY_CODE_KP_DIVIDE,
-[kVK_ANSI_KeypadEquals] = Q_KEY_CODE_KP_EQUALS,
-[kVK_ANSI_KeypadClear] = Q_KEY_CODE_NUM_LOCK,
-
-

Re: [Qemu-devel] [PATCH] i386/cpu/hyperv: support over 64 vcpus for windows guests

[Gonglei (Arei)]

> 
> On 12/09/2017 03:41, Gonglei (Arei) wrote:
> >
> >> -Original Message-
> >> From: Eduardo Habkost [mailto:ehabk...@redhat.com]
> >> Sent: Tuesday, September 12, 2017 2:38 AM
> >> To: Gonglei (Arei)
> >> Cc: qemu-devel@nongnu.org; m...@redhat.com; pbonz...@redhat.com;
> >> r...@twiddle.net; mtosa...@redhat.com; vroze...@redhat.com;
> >> Huangweidong (C)
> >> Subject: Re: [PATCH] i386/cpu/hyperv: support over 64 vcpus for windows
> >> guests
> >>
> >> On Mon, Sep 11, 2017 at 11:20:27PM +0800, Gonglei wrote:
> >>> Starting with Windows Server 2012 and Windows 8, if
> >>> CPUID.4005.EAX contains a value of -1, Windows assumes specific
> >>> limit to the number of VPs. In this case, Windows Server 2012
> >>> guest VMs may use more than 64 VPs, up to the maximum supported
> >>> number of processors applicable to the specific Windows
> >>> version being used.
> >>>
> >>>
> >>
> https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/referenc
> >> e/tlfs
> >>>
> >>> For compatibility, Let's introduce a new property for X86CPU,
> >>> named "x-hv-max-vps" as Eduardo's suggestion, and set it
> >>> to 0x40 before machine 2.10.
> >>>
> >>> (The "x-" prefix indicates that the property is not supposed to
> >>> be a stable user interface.)
> >>>
> >>> Signed-off-by: Gonglei 
> >>> ---
> >>>  include/hw/i386/pc.h |  5 +
> >>>  target/i386/cpu.c|  1 +
> >>>  target/i386/cpu.h|  2 ++
> >>>  target/i386/kvm.c| 15 ++-
> >>>  4 files changed, 22 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> >>> index 8226904..087d184 100644
> >>> --- a/include/hw/i386/pc.h
> >>> +++ b/include/hw/i386/pc.h
> >>> @@ -371,6 +371,11 @@ bool e820_get_entry(int, uint32_t, uint64_t *,
> >> uint64_t *);
> >>>
> >>>  #define PC_COMPAT_2_10 \
> >>>  HW_COMPAT_2_10 \
> >>> +{\
> >>> +.driver   = TYPE_X86_CPU,\
> >>> +.property = "x-hv-max-vps",\
> >>> +.value= "0x40",\
> >>> +},
> >>>
> >>>  #define PC_COMPAT_2_9 \
> >>>  HW_COMPAT_2_9 \
> >>> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> >>> index 69676e1..2702485 100644
> >>> --- a/target/i386/cpu.c
> >>> +++ b/target/i386/cpu.c
> >>> @@ -4145,6 +4145,7 @@ static Property x86_cpu_properties[] = {
> >>>   false),
> >>>  DEFINE_PROP_BOOL("vmware-cpuid-freq", X86CPU,
> >> vmware_cpuid_freq, true),
> >>>  DEFINE_PROP_BOOL("tcg-cpuid", X86CPU, expose_tcg, true),
> >>> +DEFINE_PROP_INT32("x-hv-max-vps", X86CPU, hv_max_vps, -1),
> >>>  DEFINE_PROP_END_OF_LIST()
> >>>  };
> >>>
> >>> diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> >>> index 525d35d..5c726f3 100644
> >>> --- a/target/i386/cpu.h
> >>> +++ b/target/i386/cpu.h
> >>> @@ -1282,6 +1282,8 @@ struct X86CPU {
> >>>  int32_t socket_id;
> >>>  int32_t core_id;
> >>>  int32_t thread_id;
> >>> +
> >>> +int32_t hv_max_vps;
> >>>  };
> >>>
> >>>  static inline X86CPU *x86_env_get_cpu(CPUX86State *env)
> >>> diff --git a/target/i386/kvm.c b/target/i386/kvm.c
> >>> index 6db7783..a898bef 100644
> >>> --- a/target/i386/kvm.c
> >>> +++ b/target/i386/kvm.c
> >>> @@ -751,7 +751,20 @@ int kvm_arch_init_vcpu(CPUState *cs)
> >>>
> >>>  c = _data.entries[cpuid_i++];
> >>>  c->function = HYPERV_CPUID_IMPLEMENT_LIMITS;
> >>> -c->eax = 0x40;
> >>> +
> >>> +/*
> >>> + * From "Requirements for Implementing the Microsoft
> >>> + * Hypervisor Interface":
> >>> + *
> >>
> https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/referenc
> >> e/tlfs
> >>> + *
> >>> + * "Starting with Windows Server 2012 and Windows 8, if
> >>> + * CPUID.4005.EAX contains a value of -1, Windows
> assumes
> >>> + * specific limit to the number of VPs. In this case, Windows
> >>> + * Server 2012 guest VMs may use more than 64 VPs, up to the
> >>> + * maximum supported number of processors applicable to the
> >>> + * specific Windows version being used."
> >>> + */
> >>
> >> I would place this comment above the DEFINE_PROP_INT32
> >> declaration, as its purpose is to explain the -1 default.
> >>
> > Fine, do I need to send v2? Or you adjust it directly?
> 
> Done, also changing the sentence to "Windows assumes that the hypervisor
> imposes no specific limit to the number of VPs" as in the Microsoft
> document.
> 
> Paolo
> 
Nice, thanks!

Regards,
-Gonglei

Re: [Qemu-devel] [PATCH v5 00/12] Convert over to use keycodemapdb

[no-reply]

Hi,

This series failed build test on s390x host. Please find the details below.

Subject: [Qemu-devel] [PATCH v5 00/12] Convert over to use keycodemapdb
Type: series
Message-id: 20170912123744.14730-1-berra...@redhat.com

=== TEST SCRIPT BEGIN ===
#!/bin/bash
# Testing script will be invoked under the git checkout with
# HEAD pointing to a commit that has the patches applied on top of "base"
# branch
set -e
echo "=== ENV ==="
env
echo "=== PACKAGES ==="
rpm -qa
echo "=== TEST BEGIN ==="
CC=$HOME/bin/cc
INSTALL=$PWD/install
BUILD=$PWD/build
echo -n "Using CC: "
realpath $CC
mkdir -p $BUILD $INSTALL
SRC=$PWD
cd $BUILD
$SRC/configure --cc=$CC --prefix=$INSTALL
make -j4
# XXX: we need reliable clean up
# make check -j4 V=1
make install
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 - [tag update]  patchew/20170823162004.27337-1-marcandre.lur...@redhat.com 
-> patchew/20170823162004.27337-1-marcandre.lur...@redhat.com
 - [tag update]  patchew/20170911201610.15204-1-...@gmx.com -> 
patchew/20170911201610.15204-1-...@gmx.com
 * [new tag] patchew/20170912123744.14730-1-berra...@redhat.com -> 
patchew/20170912123744.14730-1-berra...@redhat.com
Switched to a new branch 'test'
fae652e display: convert XenInput keyboard to keycodemapdb
c8d9524 ui: convert GTK and SDL1 frontends to keycodemapdb
4175200 ui: convert the SDL2 frontend to keycodemapdb
d54c4f7 ui: convert cocoa frontend to keycodemapdb
60a4cdb char: convert the escc device to keycodemapdb
df24350 input: convert the adb device to keycodemapdb
85343f3 input: convert ps2 device to keycodemapdb
00dbdc1 input: convert virtio-input-hid device to keycodemapdb
475272e ui: don't export qemu_input_event_new_key
0d88a11 ui: convert key events to QKeyCodes immediately
33c690e ui: convert common input code to keycodemapdb
1a87122 ui: add keycodemapdb repository as a GIT submodule

=== OUTPUT BEGIN ===
=== ENV ===
XDG_SESSION_ID=5
SHELL=/bin/sh
USER=fam
PATCHEW=/home/fam/patchew/patchew-cli -s http://patchew.org --nodebug
PATH=/usr/bin:/bin
PWD=/var/tmp/patchew-tester-tmp-4iydjbd7/src
LANG=en_US.UTF-8
HOME=/home/fam
SHLVL=2
LOGNAME=fam
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1012/bus
XDG_RUNTIME_DIR=/run/user/1012
_=/usr/bin/env
=== PACKAGES ===
gpg-pubkey-873529b8-54e386ff
xz-libs-5.2.2-2.fc24.s390x
libxshmfence-1.2-3.fc24.s390x
giflib-4.1.6-15.fc24.s390x
trousers-lib-0.3.13-6.fc24.s390x
ncurses-base-6.0-6.20160709.fc25.noarch
gmp-6.1.1-1.fc25.s390x
libidn-1.33-1.fc25.s390x
slang-2.3.0-7.fc25.s390x
pkgconfig-0.29.1-1.fc25.s390x
alsa-lib-1.1.1-2.fc25.s390x
yum-metadata-parser-1.1.4-17.fc25.s390x
python3-slip-dbus-0.6.4-4.fc25.noarch
python2-cssselect-0.9.2-1.fc25.noarch
createrepo_c-libs-0.10.0-6.fc25.s390x
initscripts-9.69-1.fc25.s390x
parted-3.2-21.fc25.s390x
flex-2.6.0-3.fc25.s390x
colord-libs-1.3.4-1.fc25.s390x
python-osbs-client-0.33-3.fc25.noarch
perl-Pod-Simple-3.35-1.fc25.noarch
python2-simplejson-3.10.0-1.fc25.s390x
brltty-5.4-2.fc25.s390x
librados2-10.2.4-2.fc25.s390x
tcp_wrappers-7.6-83.fc25.s390x
libcephfs_jni1-10.2.4-2.fc25.s390x
nettle-devel-3.3-1.fc25.s390x
bzip2-devel-1.0.6-21.fc25.s390x
libuuid-2.28.2-2.fc25.s390x
python3-dnf-1.1.10-6.fc25.noarch
texlive-kpathsea-doc-svn41139-33.fc25.1.noarch
openssh-7.4p1-4.fc25.s390x
texlive-kpathsea-bin-svn40473-33.20160520.fc25.1.s390x
texlive-graphics-svn41015-33.fc25.1.noarch
texlive-dvipdfmx-def-svn40328-33.fc25.1.noarch
texlive-mfware-svn40768-33.fc25.1.noarch
texlive-texlive-scripts-svn41433-33.fc25.1.noarch
texlive-euro-svn22191.1.1-33.fc25.1.noarch
texlive-etex-svn37057.0-33.fc25.1.noarch
texlive-iftex-svn29654.0.2-33.fc25.1.noarch
texlive-palatino-svn31835.0-33.fc25.1.noarch
texlive-texlive-docindex-svn41430-33.fc25.1.noarch
texlive-xunicode-svn30466.0.981-33.fc25.1.noarch
texlive-koma-script-svn41508-33.fc25.1.noarch
texlive-pst-grad-svn15878.1.06-33.fc25.1.noarch
texlive-pst-blur-svn15878.2.0-33.fc25.1.noarch
texlive-jknapltx-svn19440.0-33.fc25.1.noarch
texinfo-6.1-4.fc25.s390x
openssl-devel-1.0.2k-1.fc25.s390x
jansson-2.10-2.fc25.s390x
fedora-repos-25-4.noarch
python3-libs-3.5.3-6.fc25.s390x
perl-Errno-1.25-387.fc25.s390x
acl-2.2.52-13.fc25.s390x
systemd-pam-231-17.fc25.s390x
NetworkManager-libnm-1.4.4-5.fc25.s390x
poppler-0.45.0-5.fc25.s390x
ccache-3.3.4-1.fc25.s390x
valgrind-3.12.0-9.fc25.s390x
perl-open-1.10-387.fc25.noarch
libgcc-6.4.1-1.fc25.s390x
libsoup-2.56.1-1.fc25.s390x
libstdc++-devel-6.4.1-1.fc25.s390x
nss-softokn-devel-3.31.0-1.0.fc25.s390x
libobjc-6.4.1-1.fc25.s390x
python2-rpm-4.13.0.1-2.fc25.s390x
python2-gluster-3.10.5-1.fc25.s390x
rpm-build-4.13.0.1-2.fc25.s390x
glibc-static-2.24-10.fc25.s390x
lz4-1.8.0-1.fc25.s390x
xapian-core-libs-1.2.24-1.fc25.s390x
elfutils-libelf-devel-0.169-1.fc25.s390x
libaio-0.3.110-6.fc24.s390x
libfontenc-1.1.3-3.fc24.s390x
lzo-2.08-8.fc24.s390x
isl-0.14-5.fc24.s390x
libXau-1.0.8-6.fc24.s390x
linux-atm-libs-2.5.1-14.fc24.s390x
libXext-1.3.3-4.fc24.s390x

Re: [Qemu-devel] [PATCH v5 00/12] Convert over to use keycodemapdb

[no-reply]

Hi,

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

Subject: [Qemu-devel] [PATCH v5 00/12] Convert over to use keycodemapdb
Message-id: 20170912123744.14730-1-berra...@redhat.com
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
# Let docker tests dump environment info
export SHOW_ENV=1
export J=8
time make docker-test-quick@centos6
time make docker-test-build@min-glib
time make docker-test-mingw@fedora
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
fae652ea62 display: convert XenInput keyboard to keycodemapdb
c8d95241f3 ui: convert GTK and SDL1 frontends to keycodemapdb
4175200b40 ui: convert the SDL2 frontend to keycodemapdb
d54c4f7d1b ui: convert cocoa frontend to keycodemapdb
60a4cdb7cc char: convert the escc device to keycodemapdb
df243503e5 input: convert the adb device to keycodemapdb
85343f342f input: convert ps2 device to keycodemapdb
00dbdc189b input: convert virtio-input-hid device to keycodemapdb
475272eb06 ui: don't export qemu_input_event_new_key
0d88a11efd ui: convert key events to QKeyCodes immediately
33c690e7a1 ui: convert common input code to keycodemapdb
1a87122cbb ui: add keycodemapdb repository as a GIT submodule

=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into '/var/tmp/patchew-tester-tmp-86s7dwy8/src/dtc'...
Submodule path 'dtc': checked out '558cd81bdd432769b59bff01240c44f82cfb1a9d'
  BUILD   centos6
make[1]: Entering directory '/var/tmp/patchew-tester-tmp-86s7dwy8/src'
  ARCHIVE qemu.tgz
  ARCHIVE dtc.tgz
  COPYRUNNER
RUN test-quick in qemu:centos6 
Packages installed:
SDL-devel-1.2.14-7.el6_7.1.x86_64
bison-2.4.1-5.el6.x86_64
bzip2-devel-1.0.5-7.el6_0.x86_64
ccache-3.1.6-2.el6.x86_64
csnappy-devel-0-6.20150729gitd7bc683.el6.x86_64
flex-2.5.35-9.el6.x86_64
gcc-4.4.7-18.el6.x86_64
git-1.7.1-8.el6.x86_64
glib2-devel-2.28.8-9.el6.x86_64
libepoxy-devel-1.2-3.el6.x86_64
libfdt-devel-1.4.0-1.el6.x86_64
librdmacm-devel-1.0.21-0.el6.x86_64
lzo-devel-2.03-3.1.el6_5.1.x86_64
make-3.81-23.el6.x86_64
mesa-libEGL-devel-11.0.7-4.el6.x86_64
mesa-libgbm-devel-11.0.7-4.el6.x86_64
package g++ is not installed
pixman-devel-0.32.8-1.el6.x86_64
spice-glib-devel-0.26-8.el6.x86_64
spice-server-devel-0.12.4-16.el6.x86_64
tar-1.23-15.el6_8.x86_64
vte-devel-0.25.1-9.el6.x86_64
xen-devel-4.6.3-15.el6.x86_64
zlib-devel-1.2.3-29.el6.x86_64

Environment variables:
PACKAGES=bison bzip2-devel ccache csnappy-devel flex g++
 gcc git glib2-devel libepoxy-devel libfdt-devel 
librdmacm-devel lzo-devel make mesa-libEGL-devel 
mesa-libgbm-devel pixman-devel SDL-devel spice-glib-devel 
spice-server-devel tar vte-devel xen-devel zlib-devel
HOSTNAME=73f5b8f10f48
TERM=xterm
MAKEFLAGS= -j8
HISTSIZE=1000
J=8
USER=root
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.tbz=01;31:*.tbz2=01;31:*.bz=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=01;36:*.au=01;36:*.flac=01;36:*.mid=01;36:*.midi=01;36:*.mka=01;36:*.mp3=01;36:*.mpc=01;36:*.ogg=01;36:*.ra=01;36:*.wav=01;36:*.axa=01;36:*.oga=01;36:*.spx=01;36:*.xspf=01;36:
CCACHE_DIR=/var/tmp/ccache
EXTRA_CONFIGURE_OPTS=
V=
SHOW_ENV=1
MAIL=/var/spool/mail/root
PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
LANG=en_US.UTF-8
TARGET_LIST=
HISTCONTROL=ignoredups
SHLVL=1
HOME=/root
TEST_DIR=/tmp/qemu-test
LOGNAME=root
LESSOPEN=||/usr/bin/lesspipe.sh %s
FEATURES= dtc
DEBUG=
G_BROKEN_FILENAMES=1
CCACHE_HASHDIR=
_=/usr/bin/env

Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu 
--prefix=/var/tmp/qemu-build/install
No C++ compiler available; disabling C++ specific optional code
Install prefix/var/tmp/qemu-build/install
BIOS directory

Re: [Qemu-devel] [PATCH 04/12] qemu-iotests: limit non-_PROG-suffixed variables to common.rc

[Paolo Bonzini]

On 12/09/2017 14:51, Kevin Wolf wrote:
> Am 12.09.2017 um 14:28 hat Paolo Bonzini geschrieben:
>> On 12/09/2017 12:31, Kevin Wolf wrote:
>>> Hm, does this mean that instead of ./check failing when a binary is
>>> missing, we try each test case now and each one fails with the same
>>> error message?
>>>
>>> *tries it out*
>>>
>>> Okay, it's already broken today because the strings are never empty but
>>> contain the name of the wrapper functions, but it's still bad behaviour.
>>> Instead of just telling me that the binary is missing like it used to
>>> work, I get tons of test case diffs.
>>
>> So the patch is still dead code, isn't it?
> 
> Yes. But instead of moving it to a place where this ugly failure mode
> becomes intentional, we should just fix the check and keep doing it once
> at the start of ./check.

Ok, that is better indeed.

Paolo

Re: [Qemu-devel] [PATCH v4 13/21] target/s390x: use "core-id" for cpu number/address/id handling

[Igor Mammedov]

On Mon, 11 Sep 2017 17:21:42 +0200
David Hildenbrand  wrote:

> Some time ago we discussed that using "id" as property name is not the
> right thing to do, as it is a reserved property for other devices and
> will not work with device_add.
> 
> Switch to the term "core-id" instead, and use it as an equivalent to
> "CPU address" mentioned in the PoP. There is no such thing as cpu number,
> so rename env.cpu_num to env.core_id. We use "core-id" as this is the
> common term to use for device_add later on (x86 and ppc).
is there possibility that later The core (something that contains threads)
would appear/exist in real hw?
(my concern here is that we would have to use some other name for it as
renaming of already shipped public property name would be not an option)


> We can get rid of cpu->id now. Keep cpu_index and env->core_id in sync.
> cpu_index was already implicitly used by e.g. cpu_exists(), so keeping
> both in sync seems to be the right thing to do.
> 
> cpu_index will now no longer automatically get set via
> cpu_exec_realizefn(). For now, we were lucky that both implicitly stayed
> in sync.
> 
> Our new cpu property "core-id" can be a static property. Range checks can
> be avoided by using the correct type and the "setting after realized"
> check is done implicitly.
> 
> device_add will later need the reserved "id" property. Hotplugging a CPU
> on s390x will then be: "device_add host-s390-cpu,id=cpu2,core-id=2".
> 
> Reviewed-by: Matthew Rosato 
> Signed-off-by: David Hildenbrand 
> ---
[...]

> diff --git a/target/s390x/misc_helper.c b/target/s390x/misc_helper.c
> index f3624d75eb..293fc8428a 100644
> --- a/target/s390x/misc_helper.c
> +++ b/target/s390x/misc_helper.c
> @@ -232,7 +232,7 @@ uint32_t HELPER(stsi)(CPUS390XState *env, uint64_t a0,
>  /* XXX make different for different CPUs? */
>  ebcdic_put(sysib.sequence, "QEMUQEMUQEMUQEMU", 16);
>  ebcdic_put(sysib.plant, "QEMU", 4);
> -stw_p(_addr, env->cpu_num);
> +stw_p(_addr, env->core_id);
>  cpu_physical_memory_write(a0, , sizeof(sysib));
>  } else if ((sel1 == 2) && (sel2 == 2)) {
>  /* Basic Machine CPUs */
> @@ -260,7 +260,7 @@ uint32_t HELPER(stsi)(CPUS390XState *env, uint64_t a0,
>  /* XXX make different for different CPUs? */
>  ebcdic_put(sysib.sequence, "QEMUQEMUQEMUQEMU", 16);
>  ebcdic_put(sysib.plant, "QEMU", 4);
> -stw_p(_addr, env->cpu_num);
> +stw_p(_addr, env->core_id);
>  stw_p(_id, 0);
>  cpu_physical_memory_write(a0, , sizeof(sysib));
>  } else if ((sel1 == 2) && (sel2 == 2)) {
> diff --git a/target/s390x/translate.c b/target/s390x/translate.c
> index 909b12818d..5abd34fb34 100644
> --- a/target/s390x/translate.c
> +++ b/target/s390x/translate.c
> @@ -3823,10 +3823,7 @@ static ExitStatus op_ssm(DisasContext *s, DisasOps *o)
>  static ExitStatus op_stap(DisasContext *s, DisasOps *o)
>  {
>  check_privileged(s);
> -/* ??? Surely cpu address != cpu number.  In any case the previous
> -   version of this stored more than the required half-word, so it
> -   is unlikely this has ever been tested.  */
> -tcg_gen_ld32u_i64(o->out, cpu_env, offsetof(CPUS390XState, cpu_num));
> +tcg_gen_ld32u_i64(o->out, cpu_env, offsetof(CPUS390XState, core_id));
>  return NO_EXIT;
>  }
I see core_id is used in several instructions,
does it really have any influence on code executed by *-user target?

[Qemu-devel] [PATCH v4 0/3] Improve websock response / error handling

[Daniel P. Berrange]

A followup of:

 v1: https://lists.gnu.org/archive/html/qemu-devel/2017-09/msg01176.html
 v2: https://lists.gnu.org/archive/html/qemu-devel/2017-09/msg01974.html
 v3: https://lists.gnu.org/archive/html/qemu-devel/2017-09/msg02108.html

Changed in v4:

  - Use time() instead of gettimeofday() to avoid data type
cast problems on mingw

Changed in v3:

  - Use strftime instead of g_date_time_format

Changed in v2:

  - Drop redundant return statement
  - Drop redundant variable initialization
  - Assert that g_date_time_format is non-NULL

Daniel P. Berrange (3):
  io: send proper HTTP response for websocket errors
  io: include full error message in websocket handshake trace
  io: use case insensitive check for Connection & Upgrade websock
headers

 io/channel-websock.c | 194 ++-
 io/trace-events  |   2 +-
 2 files changed, 145 insertions(+), 51 deletions(-)

-- 
2.13.5

[Qemu-devel] [PATCH v4 3/3] io: use case insensitive check for Connection & Upgrade websock headers

[Daniel P. Berrange]

When checking the value of the Connection and Upgrade HTTP headers
the websock RFC (6455) requires the comparison to be case insensitive.
The Connection value should be an exact match not a substring.

Reviewed-by: Eric Blake 
Signed-off-by: Daniel P. Berrange 
---
 io/channel-websock.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/io/channel-websock.c b/io/channel-websock.c
index 6ddcec1549..2258557a21 100644
--- a/io/channel-websock.c
+++ b/io/channel-websock.c
@@ -431,12 +431,12 @@ static void 
qio_channel_websock_handshake_process(QIOChannelWebsock *ioc,
 goto bad_request;
 }
 
-if (!g_strrstr(connection, QIO_CHANNEL_WEBSOCK_CONNECTION_UPGRADE)) {
+if (strcasecmp(connection, QIO_CHANNEL_WEBSOCK_CONNECTION_UPGRADE) != 0) {
 error_setg(errp, "No connection upgrade requested '%s'", connection);
 goto bad_request;
 }
 
-if (!g_str_equal(upgrade, QIO_CHANNEL_WEBSOCK_UPGRADE_WEBSOCKET)) {
+if (strcasecmp(upgrade, QIO_CHANNEL_WEBSOCK_UPGRADE_WEBSOCKET) != 0) {
 error_setg(errp, "Incorrect upgrade method '%s'", upgrade);
 goto bad_request;
 }
-- 
2.13.5

Re: [Qemu-devel] question： I found a bug which will lead to qemu crash

[Alberto Garcia]

On Tue 12 Sep 2017 01:17:38 PM CEST, WangJie (Captain) wrote:
> Hi, Kevin.
>
> I found a bug about qemu-kvm(version 2.7.0-rc0 adn 2.8.1). but qemu 2.6.0 and 
> current master is OK.
> So I git-bisect the master branch，and I found the patch you commited (block: 
> Decouple throttling from BlockDriverState) lead the bug into qemu.
>
> The patch which lead the bug into qemu: 
> (https://github.com/qemu/qemu/commit/7ca7f0f6db1fedd28d490795d778cf23979a2aa7#diff-ea36ba0f79150cc299732696a069caba)
>
> Because the current master is OK. So I think you had fixed it , can you tell 
> me which patch fixed the bug?Thank you :>
>
>
> the bug is that: qemu will crash when loop to attach and detach a disk which 
> configured qos to a VM for a while.
>
>
> *Segmentation fault info(qemu 2.7.0-rc0):*
> Using host libthread_db library "/lib64/libthread_db.so.1".
> Core was generated by `/usr/bin/qemu-kvm -name 
> guest=wangjie-i-clone203_rhel_7.3_64_guestosdev,debug-t'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x7fe960413e3c in throttle_group_next_blk (blk=0x11) at 
> block/throttle-groups.c:160

That's clearly an invalid pointer, so the code is iterating over a
BlockBackend that has either been freed or is not on the throttle_groups
list anymore.

Commit 6bf77e1c2dc24da1bade16e8a9a637f3b127314d fixed a problem in which
the code was not iterating the list correctly, although I don't think
that would have caused any crash.

Did you try using git-bisect to find the commit that fixed the bug?

Berto

Re: [Qemu-devel] [Qemu-arm] [PATCH v2 3/3] tests/hmp: test "none" machine with memory

[Philippe Mathieu-Daudé]

On 09/11/2017 11:20 AM, Laurent Vivier wrote:

and add a test case of dump-guest-memory without
"[begin length]" parameters.

Signed-off-by: Laurent Vivier 
---
  tests/test-hmp.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/tests/test-hmp.c b/tests/test-hmp.c
index 729c0339f7..90693c0ce2 100644
--- a/tests/test-hmp.c
+++ b/tests/test-hmp.c
@@ -35,6 +35,7 @@ static const char *hmp_cmds[] = {
  "mouse_button 0",
  "device_del mouse1",
  "dump-guest-memory /dev/null 0 4096",
+"dump-guest-memory /dev/null",
  "gdbserver",
  "host_net_add user id=net0",
  "hostfwd_add tcp::43210-:43210",
@@ -159,5 +160,9 @@ int main(int argc, char **argv)
  
  qtest_cb_for_every_machine(add_machine_test_case);
  
+/* as none machine has no memory, add a test case with memory */

+
+qtest_add_data_func("hmp/none+2MB", g_strdup("none -m 2"), test_machine);


TIL:

"-m 0",
"none" machine is implemented in "null-machine.c",
"none" machine default maps memory at 0x0.


+
  return g_test_run();
  }

Re: [Qemu-devel] [PATCH v5 05/12] input: convert virtio-input-hid device to keycodemapdb

[Daniel P. Berrange]

On Tue, Sep 12, 2017 at 01:37:37PM +0100, Daniel P. Berrange wrote:
> Replace the keymap_qcode table with automatically generated
> tables.
> 
> Missing entries in keymap_qcode now fixed:
> 
>   Q_KEY_CODE_ASTERISK -> KEY_KPASTERISK
>   Q_KEY_CODE_KP_MULTIPLY -> KEY_KPASTERISK
>   Q_KEY_CODE_STOP -> KEY_STOP
>   Q_KEY_CODE_AGAIN -> KEY_AGAIN
>   Q_KEY_CODE_PROPS -> KEY_PROPS
>   Q_KEY_CODE_UNDO -> KEY_UNDO
>   Q_KEY_CODE_FRONT -> KEY_FRONT
>   Q_KEY_CODE_COPY -> KEY_COPY
>   Q_KEY_CODE_OPEN -> KEY_OPEN
>   Q_KEY_CODE_PASTE -> KEY_PASTE
>   Q_KEY_CODE_FIND -> KEY_FIND
>   Q_KEY_CODE_CUT -> KEY_CUT
>   Q_KEY_CODE_LF -> KEY_LINEFEED
>   Q_KEY_CODE_HELP -> KEY_HELP
>   Q_KEY_CODE_COMPOSE -> KEY_COMPOSE
>   Q_KEY_CODE_RO -> KEY_RO
>   Q_KEY_CODE_HIRAGANA -> KEY_HIRAGANA
>   Q_KEY_CODE_HENKAN -> KEY_HENKAN
>   Q_KEY_CODE_YEN -> KEY_YEN
>   Q_KEY_CODE_KP_COMMA -> KEY_KPCOMMA
>   Q_KEY_CODE_KP_EQUALS -> KEY_KPEQUAL
>   Q_KEY_CODE_POWER -> KEY_POWER
>   Q_KEY_CODE_SLEEP -> KEY_SLEEP
>   Q_KEY_CODE_WAKE -> KEY_WAKEUP
>   Q_KEY_CODE_AUDIONEXT -> KEY_NEXTSONG
>   Q_KEY_CODE_AUDIOPREV -> KEY_PREVIOUSSONG
>   Q_KEY_CODE_AUDIOSTOP -> KEY_STOPCD
>   Q_KEY_CODE_AUDIOPLAY -> KEY_PLAYPAUSE
>   Q_KEY_CODE_AUDIOMUTE -> KEY_MUTE
>   Q_KEY_CODE_VOLUMEUP -> KEY_VOLUMEUP
>   Q_KEY_CODE_VOLUMEDOWN -> KEY_VOLUMEDOWN
>   Q_KEY_CODE_MEDIASELECT -> KEY_MEDIA
>   Q_KEY_CODE_MAIL -> KEY_MAIL
>   Q_KEY_CODE_CALCULATOR -> KEY_CALC
>   Q_KEY_CODE_COMPUTER -> KEY_COMPUTER
>   Q_KEY_CODE_AC_HOME -> KEY_HOMEPAGE
>   Q_KEY_CODE_AC_BACK -> KEY_BACK
>   Q_KEY_CODE_AC_FORWARD -> KEY_FORWARD
>   Q_KEY_CODE_AC_REFRESH -> KEY_REFRESH
>   Q_KEY_CODE_AC_BOOKMARKS -> KEY_BOOKMARKS
> 
> Signed-off-by: Daniel P. Berrange 
> ---
>  hw/input/virtio-input-hid.c  | 136 +++---
>  include/ui/input.h   |   3 +
>  ui/Makefile.objs |   1 +
>  ui/input-keymap-qcode-to-linux.c | 156 
> +++
>  ui/input-keymap.c|   1 +
>  5 files changed, 170 insertions(+), 127 deletions(-)
>  create mode 100644 ui/input-keymap-qcode-to-linux.c
> 

> @@ -162,7 +43,7 @@ static const unsigned int axismap_abs[INPUT_AXIS__MAX] = {
>  /* - */
>  
>  static void virtio_input_key_config(VirtIOInput *vinput,
> -const unsigned int *keymap,
> +const unsigned short *keymap,
>  size_t mapsize)
>  {
>  virtio_input_config keys;

[snip]

> @@ -387,8 +269,8 @@ static void virtio_keyboard_init(Object *obj)
>  
>  vhid->handler = _keyboard_handler;
>  virtio_input_init_config(vinput, virtio_keyboard_config);
> -virtio_input_key_config(vinput, keymap_qcode,
> -ARRAY_SIZE(keymap_qcode));
> +virtio_input_key_config(vinput, qemu_input_map_qcode_to_linux,
> +qemu_input_map_qcode_to_linux_len);
>  }

Revisiting Gerd's comment on an earlier posting of this patch. Gerd
mentioned that this change affects guest ABI, but I'm wondering
whether we actually need to care about that or not.

IIUC, the array we pass in here is used to populate a bitmap that is
passed to the guest OS. The bitmap has one bit set for each Linux
keycode that the input driver is capable of sending.

>From what I can see the guest OS will read this bitmap when it first
probes the virtio device, and never updates it.  If so, then is it
actually a problem if we don't preserve the same map across save/
restore/migrate ?

If we removed a key from the bitmap in newer QEMU, that does not
appear a problem as we'd never send an event to the guest with
that key code.

If we added a key to the bitmap, we would potentially be sending
a key to the guest that we hadn't previously declared support for.
Either the guest OS will handle this normally, despite it not
being in the declared bitmap, or it will silently drop the event.
Neither behaviour seems problematic.

If we did need to preserve ABI for this bitmap, then it seems we're
going to create alot of work for ourselves, having to maintain
many historical copies of the keycode maps tables, adding a new
copy every time support for a new key is added in QEMU. I'd
rather we avoided that complexity & burden unless there's clear
bad behaviour by not maintaining stable keycode bitmap data across
QEMU releases.

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 :|

[Qemu-devel] [Bug 1716028] Re: qemu 2.10 locks images with no feature flag

[Kevin Wolf]

The share-rw=on option belongs to -device, not to -drive/-blockdev.

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

Title:
  qemu 2.10 locks images with no feature flag

Status in QEMU:
  New
Status in qemu package in Ubuntu:
  New

Bug description:
  1) % lsb_release -rd
  Description:  Ubuntu Artful Aardvark (development branch)
  Release:  17.10

  2) % apt-cache policy qemu-system-x86
  qemu-system-x86:
Installed: 1:2.10~rc3+dfsg-0ubuntu1
Candidate: 1:2.10+dfsg-0ubuntu1
Version table:
   1:2.10+dfsg-0ubuntu1 500
  500 http://archive.ubuntu.com//ubuntu devel/main amd64 Packages
   *** 1:2.10~rc3+dfsg-0ubuntu1 100
  100 /var/lib/dpkg/status

  3) qemu locks image files with no way to discover this feature nor how
  to disable it

  4) qemu provides a way to query if it supports image locking, and what
  the default value is, and how to disable the locking via cli

  qemu 2.10 now will lock image files and warn if an image is currently
  locked.  This prevent qemu from running (and possibly corrupting said
  image).

  However, qemu does not provide any way to determine if a qemu binary
  actually has this capability.  Normally behavior changing features are
  exposed via some change to the qemu help menu or QMP/QAPI output of
  capabilities.

  I believe this slipped through since libvirt already does image
  locking, but direct cli users will be caught by this change.

  In particular, we have a use-case where we simulate multipath disks by
  creating to disks which point to the same file which now breaks
  without adding the 'file.locking=off' to the -drive parameters;  which
  is also completely undocumented and unexposed.

  Some parts of the cli like -device allow querying of settable options
  (qemu-system-x86 -device scsi_hd,?)  but nothing equivalent exists for
  -drive parameters.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: qemu-system-x86 1:2.10~rc3+dfsg-0ubuntu1
  ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5
  Uname: Linux 4.12.0-11-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.6-0ubuntu7
  Architecture: amd64
  Date: Fri Sep  8 12:56:53 2017
  JournalErrors:
   Hint: You are currently not seeing messages from other users and the system.
 Users in groups 'adm', 'systemd-journal' can see all messages.
 Pass -q to turn off this notice.
   -- Logs begin at Mon 2017-01-30 11:56:02 CST, end at Fri 2017-09-08 12:56:46 
CDT. --
   -- No entries --
  KvmCmdLine: COMMAND STAT  EUID  RUID   PID  PPID %CPU COMMAND
  MachineType: HP ProLiant DL360 Gen9
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.12.0-11-generic 
root=UUID=45354276-e0c0-4bf6-9083-f130b89411cc ro --- console=ttyS1,115200
  SourcePackage: qemu
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 03/05/2015
  dmi.bios.vendor: HP
  dmi.bios.version: P89
  dmi.chassis.type: 23
  dmi.chassis.vendor: HP
  dmi.modalias: 
dmi:bvnHP:bvrP89:bd03/05/2015:svnHP:pnProLiantDL360Gen9:pvr:cvnHP:ct23:cvr:
  dmi.product.family: ProLiant
  dmi.product.name: ProLiant DL360 Gen9
  dmi.sys.vendor: HP

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

Re: [Qemu-devel] [PATCH v4 11/21] s390x: allow only 1 CPU with TCG

[Igor Mammedov]

On Mon, 11 Sep 2017 17:21:40 +0200
David Hildenbrand  wrote:

> Specifying more than 1 CPU (e.g. -smp 5) leads to SIGP errors (the
> guest tries to bring these CPUs up but fails), because we don't support
> multiple CPUs on s390x under TCG.
> 
> Let's bail out if more than 1 is specified, so we don't raise people's
> hope. Make it a define, so we can easily bump it up later.
> 
> Tested-by: Matthew Rosato 
> Signed-off-by: David Hildenbrand 
> ---
>  hw/s390x/s390-virtio-ccw.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> index f67b4b5d58..f1198b2745 100644
> --- a/hw/s390x/s390-virtio-ccw.c
> +++ b/hw/s390x/s390-virtio-ccw.c
> @@ -23,6 +23,7 @@
>  #include "hw/s390x/css.h"
>  #include "virtio-ccw.h"
>  #include "qemu/config-file.h"
> +#include "qemu/error-report.h"
>  #include "s390-pci-bus.h"
>  #include "hw/s390x/storage-keys.h"
>  #include "hw/s390x/storage-attributes.h"
> @@ -47,6 +48,8 @@ S390CPU *s390_cpu_addr2state(uint16_t cpu_addr)
>  return cpu_states[cpu_addr];
>  }
>  
> +/* #define S390_TCG_SMP_SUPPORT */
I'd drop define and ifdef for something that doesn't exists

>  static void s390_init_cpus(MachineState *machine)
>  {
>  int i;
> @@ -55,6 +58,13 @@ static void s390_init_cpus(MachineState *machine)
>  if (machine->cpu_model == NULL) {
>  machine->cpu_model = s390_default_cpu_model_name();
>  }
> +#ifndef S390_TCG_SMP_SUPPORT
> +if (tcg_enabled() && max_cpus > 1) {
> +error_report("Number of SMP CPUs requested (%d) exceeds max CPUs "
> + "supported by TCG (1) on s390x", max_cpus);
> +exit(1);
> +}
> +#endif
>  
>  cpu_states = g_new0(S390CPU *, max_cpus);
>  

Re: [Qemu-devel] [PATCH 07/12] qemu-iotests: disintegrate more parts of common.config

[Paolo Bonzini]

On 12/09/2017 14:57, Kevin Wolf wrote:
> Am 12.09.2017 um 14:31 hat Paolo Bonzini geschrieben:
>> On 12/09/2017 12:40, Kevin Wolf wrote:
>>> Am 09.08.2017 um 23:55 hat Paolo Bonzini geschrieben:
 Split "check" parts from tests part.

 For the directory setup, the actual computation of directories goes
 in "check", while the sanity checks go in the tests.

 Signed-off-by: Paolo Bonzini 
>>>
>>> Same comment as for patch 1, we may want to keep this working.
>>
>> Can you explain what is the use case?  For local symlinks I (sort of)
>> understand it, but not here.  This as far as I understand is code that
>> never runs.
> 
> Sorry, somehow I replied to the wrong patch...
> 
> This was meant as a comment for patch 9 ('do not search for binaries in
> the current directory').
> 
>> My preferred alternatives would be one of these:
>>
>> - add a patch 13 that restores the local symlink feature on top of the
>> cleaned up code.
>>
>> - later, rewrite "check" in Python now that it is clear what code is
>> part of it and what code is part of the tests.
> 
> Do you really think that removing and the reintroducing the feature is
> easier than just keeping it in the first place?

Nah, sorry, I was confused -- I thought the feature was in some common.*
file, but it's straight in "check".  I'll get rid of patch 9 and the
'./qemu' hunk of patch 1.

Paolo

Re: [Qemu-devel] [PATCH v4 14/21] target/s390x: rename next_cpu_id to next_core_id

[David Hildenbrand]

On 12.09.2017 15:09, Igor Mammedov wrote:
> On Mon, 11 Sep 2017 17:21:43 +0200
> David Hildenbrand  wrote:
> 
>> Adapt to the new term "core_id". While at it, fix the type and drop the
>> initialization to 0 (which is superfluous).
>>
>> Reviewed-by: Matthew Rosato 
>> Signed-off-by: David Hildenbrand 
>> ---
>>  target/s390x/cpu-qom.h |  2 +-
>>  target/s390x/cpu.c | 11 +--
>>  2 files changed, 6 insertions(+), 7 deletions(-)
>>
>> diff --git a/target/s390x/cpu-qom.h b/target/s390x/cpu-qom.h
>> index 2435cd8390..2e446fab51 100644
>> --- a/target/s390x/cpu-qom.h
>> +++ b/target/s390x/cpu-qom.h
>> @@ -54,7 +54,7 @@ typedef struct S390CPUClass {
>>  bool is_migration_safe;
>>  const char *desc;
>>  
>> -int64_t next_cpu_id;
>> +uint32_t next_core_id;
> is it possible to hotplug cpus in out of order in real hw?

Yes, at least under z/VM. See last two patches in this series.


-- 

Thanks,

David

[Qemu-devel] [PATCH v4 2/3] io: include full error message in websocket handshake trace

[Daniel P. Berrange]

When the websocket handshake fails it is useful to log the real
error message via the trace points for debugging purposes.

Fixes bug: #1715186

Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Daniel P. Berrange 
---
 io/channel-websock.c | 7 ---
 io/trace-events  | 2 +-
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/io/channel-websock.c b/io/channel-websock.c
index f5fac5b422..6ddcec1549 100644
--- a/io/channel-websock.c
+++ b/io/channel-websock.c
@@ -507,7 +507,7 @@ static gboolean 
qio_channel_websock_handshake_send(QIOChannel *ioc,
 );
 
 if (ret < 0) {
-trace_qio_channel_websock_handshake_fail(ioc);
+trace_qio_channel_websock_handshake_fail(ioc, error_get_pretty(err));
 qio_task_set_error(task, err);
 qio_task_complete(task);
 return FALSE;
@@ -516,7 +516,8 @@ static gboolean 
qio_channel_websock_handshake_send(QIOChannel *ioc,
 buffer_advance(>encoutput, ret);
 if (wioc->encoutput.offset == 0) {
 if (wioc->io_err) {
-trace_qio_channel_websock_handshake_fail(ioc);
+trace_qio_channel_websock_handshake_fail(
+ioc, error_get_pretty(wioc->io_err));
 qio_task_set_error(task, wioc->io_err);
 wioc->io_err = NULL;
 qio_task_complete(task);
@@ -547,7 +548,7 @@ static gboolean qio_channel_websock_handshake_io(QIOChannel 
*ioc,
  * client connection, as most of the time we have an
  * HTTP 4xx err response to send instead
  */
-trace_qio_channel_websock_handshake_fail(ioc);
+trace_qio_channel_websock_handshake_fail(ioc, error_get_pretty(err));
 qio_task_set_error(task, err);
 qio_task_complete(task);
 return FALSE;
diff --git a/io/trace-events b/io/trace-events
index 3d233698d0..6459f71f5b 100644
--- a/io/trace-events
+++ b/io/trace-events
@@ -46,7 +46,7 @@ qio_channel_websock_new_server(void *ioc, void *master) 
"Websock new client ioc=
 qio_channel_websock_handshake_start(void *ioc) "Websock handshake start ioc=%p"
 qio_channel_websock_handshake_pending(void *ioc, int status) "Websock 
handshake pending ioc=%p status=%d"
 qio_channel_websock_handshake_reply(void *ioc) "Websock handshake reply ioc=%p"
-qio_channel_websock_handshake_fail(void *ioc) "Websock handshake fail ioc=%p"
+qio_channel_websock_handshake_fail(void *ioc, const char *msg) "Websock 
handshake fail ioc=%p err=%s"
 qio_channel_websock_handshake_complete(void *ioc) "Websock handshake complete 
ioc=%p"
 
 # io/channel-command.c
-- 
2.13.5

Re: [Qemu-devel] [PATCH v15 1/5] lib/xbitmap: Introduce xbitmap

[Wei Wang]

On 09/11/2017 08:54 PM, Matthew Wilcox wrote:

On Mon, Aug 28, 2017 at 06:08:29PM +0800, Wei Wang wrote:

From: Matthew Wilcox 

The eXtensible Bitmap is a sparse bitmap representation which is
efficient for set bits which tend to cluster.  It supports up to
'unsigned long' worth of bits, and this commit adds the bare bones --
xb_set_bit(), xb_clear_bit() and xb_test_bit().

Signed-off-by: Matthew Wilcox 
Signed-off-by: Wei Wang 
Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: Michael S. Tsirkin 

This is quite naughty of you.  You've modified the xbitmap implementation
without any indication in the changelog that you did so.


This was changed in the previous version and included in that
v13->v14 ChangeLog: https://lkml.org/lkml/2017/8/16/923



I don't
think the modifications you made are an improvement, but without any
argumentation from you I don't know why you think they're an improvement.


Probably it shouldn't be modified when the discussion is incomplete:
https://lkml.org/lkml/2017/8/10/36
Sorry about that. Hope we could get more feedback from you on the
changes later.

If you want, we can continue this part from the the v13 patch, which might
be closer to the implementation that you like: 
https://lkml.org/lkml/2017/8/3/60



diff --git a/lib/xbitmap.c b/lib/xbitmap.c
new file mode 100644
index 000..8c55296
--- /dev/null
+++ b/lib/xbitmap.c
@@ -0,0 +1,176 @@
+#include 
+#include 
+
+/*
+ * The xbitmap implementation supports up to ULONG_MAX bits, and it is
+ * implemented based on ida bitmaps. So, given an unsigned long index,
+ * the high order XB_INDEX_BITS bits of the index is used to find the
+ * corresponding item (i.e. ida bitmap) from the radix tree, and the low
+ * order (i.e. ilog2(IDA_BITMAP_BITS)) bits of the index are indexed into
+ * the ida bitmap to find the bit.
+ */
+#define XB_INDEX_BITS  (BITS_PER_LONG - ilog2(IDA_BITMAP_BITS))
+#define XB_MAX_PATH(DIV_ROUND_UP(XB_INDEX_BITS, \
+ RADIX_TREE_MAP_SHIFT))
+#define XB_PRELOAD_SIZE(XB_MAX_PATH * 2 - 1)

I don't understand why you moved the xb_preload code here from the
radix tree.  I want all the code which touches the preload implementation
together in one place, which is the radix tree.


Based on the previous comments (put all the code to lib/xbitmap.c) and your
comment here, I will move xb_preload() and the above Macro to radix-tree.c,
while leaving the rest in xbitmap.c.

Would this be something you expected? Or would you like to move all back
to radix-tree.c like that in v13?


Best,
Wei

Re: [Qemu-devel] [PATCH v7 28/38] libqtest: Add qtest_[v]startf()

[Eric Blake]

On 09/12/2017 05:14 AM, Thomas Huth wrote:
> On 11.09.2017 19:20, Eric Blake wrote:
>> We have several callers that were formatting the argument strings
>> themselves; consolidate this effort by adding new convenience
>> functions directly in libqtest, and update all call-sites that
>> can benefit from it.
> [...]
>> diff --git a/tests/libqtest.c b/tests/libqtest.c
>> index e8c2e11817..b535d7768f 100644
>> --- a/tests/libqtest.c
>> +++ b/tests/libqtest.c
>> @@ -245,6 +245,27 @@ QTestState *qtest_start(const char *extra_args)
>>  return global_qtest = s;
>>  }
>>
>> +QTestState *qtest_vstartf(const char *fmt, va_list ap)
>> +{
>> +char *args = g_strdup_vprintf(fmt, ap);
>> +QTestState *s;
>> +
>> +s = qtest_start(args);
>> +global_qtest = NULL;
> 
> Don't you need a g_free(args) here?

D'oh.  Yes, I do.

>> +qtest_quit(qtest_startf("-device %s", model));
> 
> Just my personal taste, but I think I'd be nicer to keep this on
> separate lines:
> 
> QTestState *s;
> 
> s = qtest_startf("-device %s", model);
> qtest_quit(s);

Sure.  I debated about it.  If we ever do more than just create/destroy,
then having the separate lines makes it easier to stick the actual test
in between the two lines, so I'll avoid my abbreviation and go with the
longer form on respin.

>>  static void test_mon_partial(const void *data)
>>  {
>>  char *s;
>> -char *cli;
>> +const char *args = data;
>>
>> -cli = make_cli(data, "-smp 8 "
>> -   "-numa node,nodeid=0,cpus=0-1 "
>> -   "-numa node,nodeid=1,cpus=4-5 ");
>> -qtest_start(cli);
>> +global_qtest = qtest_startf("%s -smp 8 "
>> +"-numa node,nodeid=0,cpus=0-1 "
>> +"-numa node,nodeid=1,cpus=4-5 ", args);
> 
> Does GCC emit a warning if you'd used data here directly? Otherwise I
> think you could simply do this without the local args variable...

Passing void* through varargs, with the intent of the receiver parsing
it as char*, is technically undefined in C.  I don't know if gcc warns,
but I'm also worried that clang might warn.  I prefer to err on the side
of defined behavior in this case, even though it annoyingly requires a
temporary variable.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v4 18/21] s390x: implement query-hotpluggable-cpus

[Igor Mammedov]

On Mon, 11 Sep 2017 17:21:47 +0200
David Hildenbrand  wrote:

> CPU hotplug is only possible on a per core basis on s390x.
> 
> As we now have ms->possible_cpus, we can get rid of the global variable
> cpu_states.
> 
> While rewriting s390_cpu_addr2state() completely to be based on
> possible_cpus, move it to cpu.c, as it is independent of the virtio-ccw
> machine.
I'd split patch on
 1) introduce possible cpus 
 2) rewrite s390_cpu_addr2state() using #2

> Signed-off-by: David Hildenbrand 
> ---
>  hw/s390x/s390-virtio-ccw.c | 87 
> +-
>  qapi-schema.json   | 16 +
>  target/s390x/cpu.c | 17 +
>  target/s390x/cpu.h |  5 +--
>  4 files changed, 89 insertions(+), 36 deletions(-)
> 
> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> index 120f82e339..0e10a4c73a 100644
> --- a/hw/s390x/s390-virtio-ccw.c
> +++ b/hw/s390x/s390-virtio-ccw.c
> @@ -36,24 +36,12 @@
>  #include "qapi/qmp/qerror.h"
>  #include "hw/nmi.h"
>  
> -static S390CPU **cpu_states;
> -
> -S390CPU *s390_cpu_addr2state(uint16_t cpu_addr)
> -{
> -if (cpu_addr >= max_cpus) {
> -return NULL;
> -}
> -
> -/* Fast lookup via CPU ID */
> -return cpu_states[cpu_addr];
> -}
> -
>  /* #define S390_TCG_SMP_SUPPORT */
>  
>  static void s390_init_cpus(MachineState *machine)
>  {
> +MachineClass *mc = MACHINE_GET_CLASS(machine);
>  int i;
> -gchar *name;
>  
>  if (machine->cpu_model == NULL) {
>  machine->cpu_model = s390_default_cpu_model_name();
> @@ -66,17 +54,8 @@ static void s390_init_cpus(MachineState *machine)
>  }
>  #endif
>  
> -cpu_states = g_new0(S390CPU *, max_cpus);
> -
> -for (i = 0; i < max_cpus; i++) {
> -name = g_strdup_printf("cpu[%i]", i);
> -object_property_add_link(OBJECT(machine), name, TYPE_S390_CPU,
> - (Object **) _states[i],
> - object_property_allow_set_link,
> - OBJ_PROP_LINK_UNREF_ON_RELEASE,
> - _abort);
> -g_free(name);
> -}
> +/* initialize possible_cpus */
> +mc->possible_cpu_arch_ids(machine);
>  
>  for (i = 0; i < smp_cpus; i++) {
>  s390x_new_cpu(machine->cpu_model, i, _fatal);
> @@ -307,17 +286,14 @@ static void ccw_init(MachineState *machine)
>  register_savevm_live(NULL, "todclock", 0, 1, _gtod, NULL);
>  }
>  
> -static void s390_cpu_plug(HotplugHandler *hotplug_dev,
> -DeviceState *dev, Error **errp)
> +static void s390_cpu_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
> +  Error **errp)
>  {
> -gchar *name;
> +MachineState *ms = MACHINE(hotplug_dev);
>  S390CPU *cpu = S390_CPU(dev);
> -CPUState *cs = CPU(dev);
>  
> -name = g_strdup_printf("cpu[%i]", cpu->env.core_id);
> -object_property_set_link(OBJECT(hotplug_dev), OBJECT(cs), name,
> - errp);
> -g_free(name);
> +g_assert(!ms->possible_cpus->cpus[cpu->env.core_id].cpu);
> +ms->possible_cpus->cpus[cpu->env.core_id].cpu = OBJECT(dev);
>  }
>  
>  static void s390_machine_reset(void)
> @@ -350,6 +326,50 @@ static void 
> s390_machine_device_unplug_request(HotplugHandler *hotplug_dev,
>  }
>  }
>  
> +static CPUArchId *s390_find_cpu_slot(MachineState *ms, uint32_t core_id,
> + int *idx)
> +{
> +if (core_id >= ms->possible_cpus->len) {
> +return NULL;
> +}
> +/* core_id corresponds to the index */
> +if (idx) {
> +*idx = core_id;
> +}
> +return >possible_cpus->cpus[core_id];
> +}
it looks like cpu_index == core_id == idx in possible_cpus,
is this helper really necessary?
(we have it in x86 because of possible not 1:1 mapping)

I'd drop it and just access array directly

> +
> +static CpuInstanceProperties s390_cpu_index_to_props(MachineState *machine,
> + unsigned cpu_index)
> +{
> +CPUArchId *slot = s390_find_cpu_slot(machine, cpu_index, NULL);
> +
> +assert(slot);
> +return slot->props;
> +}
> +
> +static const CPUArchIdList *s390_possible_cpu_arch_ids(MachineState *ms)
> +{
> +int i;
> +
> +if (ms->possible_cpus) {
> +g_assert(ms->possible_cpus && ms->possible_cpus->len == max_cpus);
> +return ms->possible_cpus;
> +}
> +
> +ms->possible_cpus = g_malloc0(sizeof(CPUArchIdList) +
> +  sizeof(CPUArchId) * max_cpus);
> +ms->possible_cpus->len = max_cpus;
> +for (i = 0; i < ms->possible_cpus->len; i++) {
> +ms->possible_cpus->cpus[i].vcpus_count = 1;
> +ms->possible_cpus->cpus[i].arch_id = i;
> +ms->possible_cpus->cpus[i].props.has_core_id = true;
> +ms->possible_cpus->cpus[i].props.core_id = i;
> +}
> +
> +return 

Re: [Qemu-devel] Suggested Wiki Update

[Viktor Mihajlovski]

On 12.09.2017 13:25, Thomas Huth wrote:
> On 12.09.2017 13:18, Cornelia Huck wrote:
[...]
>>
>> Looks good.
>>
>> Can you perhaps add a sentence that the base support is available with
>> 2.9 and netboot with 2.10? ('Overview' looks like a good place for
>> that.)
> 
> FWIW, I think it would also be good to add a sentence about the need to
> specify "bootindex" somewhere (I remember trying to use "-boot n" the
> first time I wanted to use it) ...
> 
Good points, I'll add more context ... thanks for the review.

-- 

Mit freundlichen Grüßen/Kind Regards
   Viktor Mihajlovski

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

Re: [Qemu-devel] [PATCH 6/6] arm: drop intermadiate cpu_model -> cpu type parsing and use cpu type directly

[Eduardo Habkost]

On Tue, Sep 12, 2017 at 12:22:14PM +0200, Igor Mammedov wrote:
> On Sat, 9 Sep 2017 17:30:14 -0300
> Eduardo Habkost  wrote:
> 
> > On Tue, Sep 05, 2017 at 03:46:07PM -0700, Alistair Francis wrote:
> > > On Tue, Sep 5, 2017 at 3:12 PM, Eduardo Habkost  
> > > wrote:  
> > > > On Tue, Sep 05, 2017 at 02:47:52PM -0700, Alistair Francis wrote:  
> > > >> On Tue, Sep 5, 2017 at 2:31 PM, Eduardo Habkost  
> > > >> wrote:  
> > > > [...]  
> > > >> >> diff --git a/hw/arm/stm32f205_soc.c b/hw/arm/stm32f205_soc.c
> > > >> >> index f61e735..1cd6374 100644
> > > >> >> --- a/hw/arm/stm32f205_soc.c
> > > >> >> +++ b/hw/arm/stm32f205_soc.c
> > > >> >> @@ -112,7 +112,7 @@ static void stm32f205_soc_realize(DeviceState 
> > > >> >> *dev_soc, Error **errp)
> > > >> >>
> > > >> >>  armv7m = DEVICE(>armv7m);
> > > >> >>  qdev_prop_set_uint32(armv7m, "num-irq", 96);
> > > >> >> -qdev_prop_set_string(armv7m, "cpu-model", s->cpu_model);
> > > >> >> +qdev_prop_set_string(armv7m, "cpu-type", s->cpu_type);
> > > >> >>  object_property_set_link(OBJECT(>armv7m), 
> > > >> >> OBJECT(get_system_memory()),
> > > >> >>   "memory", _abort);
> > > >> >>  object_property_set_bool(OBJECT(>armv7m), true, "realized", 
> > > >> >> );
> > > >> >> @@ -200,7 +200,7 @@ static void stm32f205_soc_realize(DeviceState 
> > > >> >> *dev_soc, Error **errp)
> > > >> >>  }
> > > >> >>
> > > >> >>  static Property stm32f205_soc_properties[] = {
> > > >> >> -DEFINE_PROP_STRING("cpu-model", STM32F205State, cpu_model),
> > > >> >> +DEFINE_PROP_STRING("cpu-type", STM32F205State, cpu_type),  
> > > >> >
> > > >> > Same as armv7m: are we 100% sure users are not setting this
> > > >> > manually?  
> > > >>
> > > >> In an embedded board like this it really doesn't make sense to let the
> > > >> user overwrite the CPU. The SoC will take it as an option, but the
> > > >> board (which creates the SoC) just blindly always uses the same CPU.
> > > >> That feature is more for QOMificatoion then any real reason though.
> > > >>  
> > > >
> > > > I'm not talking about -cpu (no user-visible change in the
> > > > handling of -cpu should result from this patch), but about
> > > > possible cases where the user set the "cpu-model" property using
> > > > another mechanism, like -global.  Probably it's impossible for an
> > > > user to override the property successfully, but I would like to
> > > > be sure.  
> > > 
> > > Ah, that is trickier.
> > > 
> > > I guess that is possible to do, but the object setting logic should
> > > handle the error gracefully and inform the user of the error.  
> > 
> > After looking at the code more closely, I think we can be 100%
> > sure the user doesn't rely on the property, because:
> > 
> > * TYPE_ARMV7M and TYPE_STM32F205_SOC are both sysbus devices
> >   with user_creatable=false, so the user can't instantiate them
> >   directly;
> > * The only places where those objects are realized inside the
> >   code are:
> >   * mps2_common_init()
> >   * netduino2_init()
> >   * stm32f205_soc_realize()
> >   * armv7m_init()
> >   Those functions always set the "cpu-model" property immediately
> >   before realize.
> > 
> > This means any value set by the user (e.g. using -global) would
> > be always overwritten before realize.
> > 
> > However, I have a suggestion for Igor: making a separate patch
> > that renames the existing property to "x-cpu-model", and using
> > "x-cpu-type" in this series.  This way we will explicitly
> > document the fact that the property is not a stable
> > user/management interface.
> There is no much point in renaming to "x-cpu-model" as it will be deleted
> right afterwards, I'd just delete "cpu-model" and use "x-cpu-type"
> in this patch. I'm not a fun of 'x-' prefix and would prefer a flag
> in property to mark it as internal. But it's out of scope of this series,
> so I don't care much about naming at the moment and will use "x-cpu-type"
> as you suggest.

Peter pointed out that this is the case with lots of properties
on non-user-creatable devices.  So we can keep "cpu-type" for
consistency by now.

-- 
Eduardo

Re: [Qemu-devel] [PATCH 6/6] arm: drop intermadiate cpu_model -> cpu type parsing and use cpu type directly

[Igor Mammedov]

On Tue, 5 Sep 2017 18:31:52 -0300
Eduardo Habkost  wrote:

> On Mon, Sep 04, 2017 at 04:01:02PM +0200, Igor Mammedov wrote:
> > there are 2 use cases to deal with:
> >   1: fixed CPU models per board/soc
> >   2: boards with user configurable cpu_model and fallback to
> >  default cpu_model if user hasn't specified one explicitly
> > 
> > For the 1st
> >   drop intermediate cpu_model parsing and use const cpu type
> >   directly, which replaces:
> >  typename = object_class_get_name(
> >cpu_class_by_name(TYPE_ARM_CPU, cpu_model))
> >  object_new(typename)
> >   with
> >  object_new(FOO_CPU_TYPE_NAME)
> >   or
> >  cpu_generic_init(BASE_CPU_TYPE, "my cpu model")
> >   with
> >  cpu_create(FOO_CPU_TYPE_NAME)
> > 
> > as result 1st use case doesn't have to invoke not necessary
> > translation and not needed code is removed.
> > 
> > For the 2nd
> >  1: set default cpu type with MachineClass::default_cpu_type and
> >  2: use generic cpu_model parsing that done before machine_init()
> > is run and:
> > 2.1: drop custom cpu_model parsing where pattern is:
> >typename = object_class_get_name(
> >cpu_class_by_name(TYPE_ARM_CPU, cpu_model))
> >[parse_features(typename, cpu_model, ) ]
> > 
> > 2.2: or replace cpu_generic_init() which does what
> >  2.1 does + create_cpu(typename) with just
> >  create_cpu(machine->cpu_type)
> > as result cpu_name -> cpu_type translation is done using
> > generic machine code one including parsing optional features
> > if supported/present (removes a bunch of duplicated cpu_model
> > parsing code) and default cpu type is defined in an uniform way
> > within machine_class_init callbacks instead of adhoc places
> > in boadr's machine_init code.
> > 
> > Signed-off-by: Igor Mammedov 
> > ---
[...]

> > @@ -285,20 +259,16 @@ static void armv7m_reset(void *opaque)
> > Returns the ARMv7M device.  */
> >  
> >  DeviceState *armv7m_init(MemoryRegion *system_memory, int mem_size, int 
> > num_irq,
> > -  const char *kernel_filename, const char *cpu_model)
> > +  const char *kernel_filename, const char *cpu_type)
> >  {
> >  DeviceState *armv7m;
> >  
> > -if (cpu_model == NULL) {
> > -cpu_model = "cortex-m3";
> > -}
> > -  
> 
> I was going to suggest doing the default_cpu_type stuff in a
> separate patch, but it might require touching those lines twice.
> So I guess this is OK.
I've have tried it, but yes it's more changes and there is also
chicken/egg problem, cleanest way I've stopped at is to get rid of
cpu_model fallback + cpu_generic_init() in one go.

 
> >  armv7m = qdev_create(NULL, "armv7m");
> >  qdev_prop_set_uint32(armv7m, "num-irq", num_irq);
> > -qdev_prop_set_string(armv7m, "cpu-model", cpu_model);
> > +qdev_prop_set_string(armv7m, "cpu-type", cpu_type);
> >  object_property_set_link(OBJECT(armv7m), OBJECT(get_system_memory()),
> >   "memory", _abort);
> > -/* This will exit with an error if the user passed us a bad cpu_model 
> > */
> > +/* This will exit with an error if the user passed us a bad cpu_type */
> >  qdev_init_nofail(armv7m);
> >  
> >  armv7m_load_kernel(ARM_CPU(first_cpu), kernel_filename, mem_size);
[...]

> > diff --git a/hw/arm/highbank.c b/hw/arm/highbank.c
> > index 20e60f1..0d7190a 100644
> > --- a/hw/arm/highbank.c
> > +++ b/hw/arm/highbank.c
> > @@ -219,7 +219,6 @@ enum cxmachines {
> >  static void calxeda_init(MachineState *machine, enum cxmachines machine_id)
> >  {
> >  ram_addr_t ram_size = machine->ram_size;
> > -const char *cpu_model = machine->cpu_model;
> >  const char *kernel_filename = machine->kernel_filename;
> >  const char *kernel_cmdline = machine->kernel_cmdline;
> >  const char *initrd_filename = machine->initrd_filename;
> > @@ -236,19 +235,20 @@ static void calxeda_init(MachineState *machine, enum 
> > cxmachines machine_id)
> >  
> >  switch (machine_id) {
> >  case CALXEDA_HIGHBANK:
> > -cpu_model = "cortex-a9";
> > +machine->cpu_type = ARM_CPU_TYPE_NAME("cortex-a9");
> >  break;
> >  case CALXEDA_MIDWAY:
> > -cpu_model = "cortex-a15";
> > +machine->cpu_type = ARM_CPU_TYPE_NAME("cortex-a15");
> >  break;
> > +default:
> > +assert(0);
> >  }  
> 
> Why not delete this switch statement completely and set
> default_cpu_type at midway_class_init() and
> highbank_class_init()?
it would allow '-cpu foo' to take effect which isn't what current code does,
as series doesn't add valid_cpus[] check at the same time.

So here we do pretty much strait-forward conversion from cpu_model
to cpu_type and nothing else.

> 
> 
> >  
> >  for (n = 0; n < smp_cpus; n++) {
> > -ObjectClass *oc = cpu_class_by_name(TYPE_ARM_CPU, cpu_model);
> >  Object *cpuobj;
> >  

Re: [Qemu-devel] [PATCH 01/27] glib-compat: move G_SOURCE_CONTINUE/REMOVE there

[Philippe Mathieu-Daudé]

On 08/23/2017 01:19 PM, Marc-André Lureau wrote:

Signed-off-by: Marc-André Lureau 


Acked-by: Philippe Mathieu-Daudé 


---
  include/glib-compat.h | 7 +++
  contrib/vhost-user-scsi/vhost-user-scsi.c | 8 
  2 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/include/glib-compat.h b/include/glib-compat.h
index fcffcd3f07..d35d641b7f 100644
--- a/include/glib-compat.h
+++ b/include/glib-compat.h
@@ -354,5 +354,12 @@ g_test_add_data_func_full(const char *path,
  }
  #endif
  
+/* Small compat shim from glib 2.32 */

+#ifndef G_SOURCE_CONTINUE
+#define G_SOURCE_CONTINUE TRUE
+#endif
+#ifndef G_SOURCE_REMOVE
+#define G_SOURCE_REMOVE FALSE
+#endif
  
  #endif

diff --git a/contrib/vhost-user-scsi/vhost-user-scsi.c 
b/contrib/vhost-user-scsi/vhost-user-scsi.c
index b5ae02c96f..78bcc65f5a 100644
--- a/contrib/vhost-user-scsi/vhost-user-scsi.c
+++ b/contrib/vhost-user-scsi/vhost-user-scsi.c
@@ -17,14 +17,6 @@
  
  #include 
  
-/* Small compat shim from glib 2.32 */

-#ifndef G_SOURCE_CONTINUE
-#define G_SOURCE_CONTINUE TRUE
-#endif
-#ifndef G_SOURCE_REMOVE
-#define G_SOURCE_REMOVE FALSE
-#endif
-
  /* #define VUS_DEBUG 1 */
  
  /** Log helpers **/

[Qemu-devel] [PATCH v5 12/12] display: convert XenInput keyboard to keycodemapdb

[Daniel P. Berrange]

Replace the scancode2linux table with an automatically
generated table. In doing so, the XenFB keyboard
handler is also converted to the modern InputEvent
framework.

Signed-off-by: Daniel P. Berrange 
---
 hw/display/xenfb.c | 133 -
 1 file changed, 30 insertions(+), 103 deletions(-)

diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index df8b78f6f4..b4668dfce4 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -28,6 +28,7 @@
 
 #include "hw/hw.h"
 #include "ui/console.h"
+#include "ui/input.h"
 #include "hw/xen/xen_backend.h"
 
 #include 
@@ -52,7 +53,7 @@ struct XenInput {
 struct common c;
 int abs_pointer_wanted; /* Whether guest supports absolute pointer */
 int button_state;   /* Last seen pointer button state */
-int extended;
+QemuInputHandlerState *qkbd;
 QEMUPutMouseEntry *qmouse;
 };
 
@@ -120,78 +121,6 @@ static void common_unbind(struct common *c)
 
 /*  */
 
-#if 0
-/*
- * These two tables are not needed any more, but left in here
- * intentionally as documentation, to show how scancode2linux[]
- * was generated.
- *
- * Tables to map from scancode to Linux input layer keycode.
- * Scancodes are hardware-specific.  These maps assumes a
- * standard AT or PS/2 keyboard which is what QEMU feeds us.
- */
-const unsigned char atkbd_set2_keycode[512] = {
-
- 0, 67, 65, 63, 61, 59, 60, 88,  0, 68, 66, 64, 62, 15, 41,117,
- 0, 56, 42, 93, 29, 16,  2,  0,  0,  0, 44, 31, 30, 17,  3,  0,
- 0, 46, 45, 32, 18,  5,  4, 95,  0, 57, 47, 33, 20, 19,  6,183,
- 0, 49, 48, 35, 34, 21,  7,184,  0,  0, 50, 36, 22,  8,  9,185,
- 0, 51, 37, 23, 24, 11, 10,  0,  0, 52, 53, 38, 39, 25, 12,  0,
- 0, 89, 40,  0, 26, 13,  0,  0, 58, 54, 28, 27,  0, 43,  0, 85,
- 0, 86, 91, 90, 92,  0, 14, 94,  0, 79,124, 75, 71,121,  0,  0,
-82, 83, 80, 76, 77, 72,  1, 69, 87, 78, 81, 74, 55, 73, 70, 99,
-
-  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
-217,100,255,  0, 97,165,  0,  0,156,  0,  0,  0,  0,  0,  0,125,
-173,114,  0,113,  0,  0,  0,126,128,  0,  0,140,  0,  0,  0,127,
-159,  0,115,  0,164,  0,  0,116,158,  0,150,166,  0,  0,  0,142,
-157,  0,  0,  0,  0,  0,  0,  0,155,  0, 98,  0,  0,163,  0,  0,
-226,  0,  0,  0,  0,  0,  0,  0,  0,255, 96,  0,  0,  0,143,  0,
-  0,  0,  0,  0,  0,  0,  0,  0,  0,107,  0,105,102,  0,  0,112,
-110,111,108,112,106,103,  0,119,  0,118,109,  0, 99,104,119,  0,
-
-};
-
-const unsigned char atkbd_unxlate_table[128] = {
-
-  0,118, 22, 30, 38, 37, 46, 54, 61, 62, 70, 69, 78, 85,102, 13,
- 21, 29, 36, 45, 44, 53, 60, 67, 68, 77, 84, 91, 90, 20, 28, 27,
- 35, 43, 52, 51, 59, 66, 75, 76, 82, 14, 18, 93, 26, 34, 33, 42,
- 50, 49, 58, 65, 73, 74, 89,124, 17, 41, 88,  5,  6,  4, 12,  3,
- 11,  2, 10,  1,  9,119,126,108,117,125,123,107,115,116,121,105,
-114,122,112,113,127, 96, 97,120,  7, 15, 23, 31, 39, 47, 55, 63,
- 71, 79, 86, 94,  8, 16, 24, 32, 40, 48, 56, 64, 72, 80, 87,111,
- 19, 25, 57, 81, 83, 92, 95, 98, 99,100,101,103,104,106,109,110
-
-};
-#endif
-
-/*
- * for (i = 0; i < 128; i++) {
- * scancode2linux[i] = atkbd_set2_keycode[atkbd_unxlate_table[i]];
- * scancode2linux[i | 0x80] = atkbd_set2_keycode[atkbd_unxlate_table[i] | 
0x80];
- * }
- */
-static const unsigned char scancode2linux[512] = {
-  0,  1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, 13, 14, 15,
- 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31,
- 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47,
- 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63,
- 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79,
- 80, 81, 82, 83, 99,  0, 86, 87, 88,117,  0,  0, 95,183,184,185,
-  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
- 93,  0,  0, 89,  0,  0, 85, 91, 90, 92,  0, 94,  0,124,121,  0,
-
-  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
-165,  0,  0,  0,  0,  0,  0,  0,  0,163,  0,  0, 96, 97,  0,  0,
-113,140,164,  0,166,  0,  0,  0,  0,  0,255,  0,  0,  0,114,  0,
-115,  0,150,  0,  0, 98,255, 99,100,  0,  0,  0,  0,  0,  0,  0,
-  0,  0,  0,  0,  0,119,119,102,103,104,  0,105,112,106,118,107,
-108,109,110,111,  0,  0,  0,  0,  0,  0,  0,125,126,127,116,142,
-  0,  0,  0,143,  0,217,156,173,128,159,158,157,155,226,  0,112,
-  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
-};
-
 /* Send an event to the keyboard frontend driver */
 static int xenfb_kbd_event(struct XenInput *xenfb,
   union xenkbd_in_event *event)
@@ -260,37 +189,21 @@ static int xenfb_send_position(struct XenInput *xenfb,
 return xenfb_kbd_event(xenfb, );
 }
 
-/*
- * Send a key event from the client to the guest OS
- * QEMU gives us a raw scancode from an AT / PS/2 

[Qemu-devel] [PATCH v5 02/12] ui: convert common input code to keycodemapdb

[Daniel P. Berrange]

Replace the number_to_qcode, qcode_to_number and linux_to_qcode
tables with automatically generated tables.

Missing entries in linux_to_qcode now fixed:

  KEY_LINEFEED -> Q_KEY_CODE_LF
  KEY_KPEQUAL -> Q_KEY_CODE_KP_EQUALS
  KEY_COMPOSE -> Q_KEY_CODE_COMPOSE
  KEY_AGAIN -> Q_KEY_CODE_AGAIN
  KEY_PROPS -> Q_KEY_CODE_PROPS
  KEY_UNDO -> Q_KEY_CODE_UNDO
  KEY_FRONT -> Q_KEY_CODE_FRONT
  KEY_COPY -> Q_KEY_CODE_COPY
  KEY_OPEN -> Q_KEY_CODE_OPEN
  KEY_PASTE -> Q_KEY_CODE_PASTE
  KEY_CUT -> Q_KEY_CODE_CUT
  KEY_HELP -> Q_KEY_CODE_HELP
  KEY_MEDIA -> Q_KEY_CODE_MEDIASELECT

In additionsome fixes:

 - KEY_PLAYPAUSE now maps to Q_KEY_CODE_AUDIOPLAY, instead of
   KEY_PLAYCD. KEY_PLAYPAUSE is defined across almost all scancodes
   sets, while KEY_PLAYCD only appears in AT set1, so the former is
   a more useful mapping.

Missing entries in qcode_to_number now fixed:

  Q_KEY_CODE_AGAIN -> 0x85
  Q_KEY_CODE_PROPS -> 0x86
  Q_KEY_CODE_UNDO -> 0x87
  Q_KEY_CODE_FRONT -> 0x8c
  Q_KEY_CODE_COPY -> 0xf8
  Q_KEY_CODE_OPEN -> 0x64
  Q_KEY_CODE_PASTE -> 0x65
  Q_KEY_CODE_CUT -> 0xbc
  Q_KEY_CODE_LF -> 0x5b
  Q_KEY_CODE_HELP -> 0xf5
  Q_KEY_CODE_COMPOSE -> 0xdd
  Q_KEY_CODE_KP_EQUALS -> 0x59
  Q_KEY_CODE_MEDIASELECT -> 0xed

In addition some fixes:

 - Q_KEY_CODE_MENU was incorrectly mapped to the compose
   scancode (0xdd) and is now mapped to 0x9e
 - Q_KEY_CODE_FIND was mapped to 0xe065 (Search) instead
   of to 0xe041 (Find)
 - Q_KEY_CODE_HIRAGANA was mapped to 0x70 (Katakanahiragana)
   instead of of 0x77 (Hirigana)
 - Q_KEY_CODE_PRINT was mapped to 0xb7 which is not a defined
   scan code in AT set 1, it is now mapped to 0x54 (sysrq)

Signed-off-by: Daniel P. Berrange 
---
 include/ui/input.h   |  11 +-
 ui/Makefile.objs |   3 +
 ui/input-keymap-linux-to-qcode.c | 463 +++
 ui/input-keymap-qcode-to-qnum.c  | 154 +
 ui/input-keymap-qnum-to-qcode.c  | 245 +
 ui/input-keymap.c| 326 ++-
 6 files changed, 890 insertions(+), 312 deletions(-)
 create mode 100644 ui/input-keymap-linux-to-qcode.c
 create mode 100644 ui/input-keymap-qcode-to-qnum.c
 create mode 100644 ui/input-keymap-qnum-to-qcode.c

diff --git a/include/ui/input.h b/include/ui/input.h
index c488585def..479cc46cfc 100644
--- a/include/ui/input.h
+++ b/include/ui/input.h
@@ -43,7 +43,7 @@ void qemu_input_event_send_key(QemuConsole *src, KeyValue 
*key, bool down);
 void qemu_input_event_send_key_number(QemuConsole *src, int num, bool down);
 void qemu_input_event_send_key_qcode(QemuConsole *src, QKeyCode q, bool down);
 void qemu_input_event_send_key_delay(uint32_t delay_ms);
-int qemu_input_key_number_to_qcode(uint8_t nr);
+int qemu_input_key_number_to_qcode(unsigned int nr);
 int qemu_input_key_value_to_number(const KeyValue *value);
 int qemu_input_key_value_to_qcode(const KeyValue *value);
 int qemu_input_key_value_to_scancode(const KeyValue *value, bool down,
@@ -69,4 +69,13 @@ void qemu_input_check_mode_change(void);
 void qemu_add_mouse_mode_change_notifier(Notifier *notify);
 void qemu_remove_mouse_mode_change_notifier(Notifier *notify);
 
+extern const guint qemu_input_map_linux_to_qcode_len;
+extern const guint16 qemu_input_map_linux_to_qcode[];
+
+extern const guint qemu_input_map_qcode_to_qnum_len;
+extern const guint16 qemu_input_map_qcode_to_qnum[];
+
+extern const guint qemu_input_map_qnum_to_qcode_len;
+extern const guint16 qemu_input_map_qnum_to_qcode[];
+
 #endif /* INPUT_H */
diff --git a/ui/Makefile.objs b/ui/Makefile.objs
index 5fcb3010b3..29e44c1baf 100644
--- a/ui/Makefile.objs
+++ b/ui/Makefile.objs
@@ -54,6 +54,9 @@ KEYCODEMAP_GEN = $(SRC_PATH)/ui/keycodemapdb/tools/keymap-gen
 KEYCODEMAP_CSV = $(SRC_PATH)/ui/keycodemapdb/data/keymaps.csv
 
 KEYCODEMAP_FILES = \
+ui/input-keymap-linux-to-qcode.c \
+ui/input-keymap-qcode-to-qnum.c \
+ui/input-keymap-qnum-to-qcode.c \
 $(NULL)
 
 # Generated input-keymap-XXX.c files are kept in GIT, so
diff --git a/ui/input-keymap-linux-to-qcode.c b/ui/input-keymap-linux-to-qcode.c
new file mode 100644
index 00..c026ed106f
--- /dev/null
+++ b/ui/input-keymap-linux-to-qcode.c
@@ -0,0 +1,463 @@
+/*
+ * This file is auto-generated from keymaps.csv on 2017-08-31 11:01
+ * Database checksum 
sha256(f8aeff0c3430077a350e3d7ba2b335b381bd929ac4b193413730a402ff3f0097)
+ * To re-generate, run:
+ *   keymap-gen --lang=glib2 --varname=qemu_input_map_linux_to_qcode code-map 
keymaps.csv linux qcode
+*/
+const guint16 qemu_input_map_linux_to_qcode[525] = {
+  [0x0] = Q_KEY_CODE_UNMAPPED, /* linux:0 (KEY_RESERVED) -> linux:0 
(KEY_RESERVED) -> qcode:Q_KEY_CODE_UNMAPPED (unmapped) */
+  [0x1] = Q_KEY_CODE_ESC, /* linux:1 (KEY_ESC) -> linux:1 (KEY_ESC) -> 
qcode:Q_KEY_CODE_ESC (esc) */
+  [0x2] = Q_KEY_CODE_1, /* linux:2 (KEY_1) -> linux:2 (KEY_1) -> 
qcode:Q_KEY_CODE_1 (1) */
+  [0x3] = 

Re: [Qemu-devel] [PATCH 04/12] qemu-iotests: limit non-_PROG-suffixed variables to common.rc

[Kevin Wolf]

Am 12.09.2017 um 14:28 hat Paolo Bonzini geschrieben:
> On 12/09/2017 12:31, Kevin Wolf wrote:
> > Hm, does this mean that instead of ./check failing when a binary is
> > missing, we try each test case now and each one fails with the same
> > error message?
> > 
> > *tries it out*
> > 
> > Okay, it's already broken today because the strings are never empty but
> > contain the name of the wrapper functions, but it's still bad behaviour.
> > Instead of just telling me that the binary is missing like it used to
> > work, I get tons of test case diffs.
> 
> So the patch is still dead code, isn't it?

Yes. But instead of moving it to a place where this ugly failure mode
becomes intentional, we should just fix the check and keep doing it once
at the start of ./check.

Kevin

Re: [Qemu-devel] [PATCH 6/6] arm: drop intermadiate cpu_model -> cpu type parsing and use cpu type directly

[Eduardo Habkost]

On Tue, Sep 12, 2017 at 02:11:59PM +0200, Igor Mammedov wrote:
> On Tue, 5 Sep 2017 18:31:52 -0300
> Eduardo Habkost  wrote:
> 
> > On Mon, Sep 04, 2017 at 04:01:02PM +0200, Igor Mammedov wrote:
> > > there are 2 use cases to deal with:
> > >   1: fixed CPU models per board/soc
> > >   2: boards with user configurable cpu_model and fallback to
> > >  default cpu_model if user hasn't specified one explicitly
> > > 
> > > For the 1st
> > >   drop intermediate cpu_model parsing and use const cpu type
> > >   directly, which replaces:
> > >  typename = object_class_get_name(
> > >cpu_class_by_name(TYPE_ARM_CPU, cpu_model))
> > >  object_new(typename)
> > >   with
> > >  object_new(FOO_CPU_TYPE_NAME)
> > >   or
> > >  cpu_generic_init(BASE_CPU_TYPE, "my cpu model")
> > >   with
> > >  cpu_create(FOO_CPU_TYPE_NAME)
> > > 
> > > as result 1st use case doesn't have to invoke not necessary
> > > translation and not needed code is removed.
> > > 
> > > For the 2nd
> > >  1: set default cpu type with MachineClass::default_cpu_type and
> > >  2: use generic cpu_model parsing that done before machine_init()
> > > is run and:
> > > 2.1: drop custom cpu_model parsing where pattern is:
> > >typename = object_class_get_name(
> > >cpu_class_by_name(TYPE_ARM_CPU, cpu_model))
> > >[parse_features(typename, cpu_model, ) ]
> > > 
> > > 2.2: or replace cpu_generic_init() which does what
> > >  2.1 does + create_cpu(typename) with just
> > >  create_cpu(machine->cpu_type)
> > > as result cpu_name -> cpu_type translation is done using
> > > generic machine code one including parsing optional features
> > > if supported/present (removes a bunch of duplicated cpu_model
> > > parsing code) and default cpu type is defined in an uniform way
> > > within machine_class_init callbacks instead of adhoc places
> > > in boadr's machine_init code.
> > > 
> > > Signed-off-by: Igor Mammedov 
> > > ---
> [...]
> 
> > > @@ -285,20 +259,16 @@ static void armv7m_reset(void *opaque)
> > > Returns the ARMv7M device.  */
> > >  
> > >  DeviceState *armv7m_init(MemoryRegion *system_memory, int mem_size, int 
> > > num_irq,
> > > -  const char *kernel_filename, const char *cpu_model)
> > > +  const char *kernel_filename, const char *cpu_type)
> > >  {
> > >  DeviceState *armv7m;
> > >  
> > > -if (cpu_model == NULL) {
> > > -cpu_model = "cortex-m3";
> > > -}
> > > -  
> > 
> > I was going to suggest doing the default_cpu_type stuff in a
> > separate patch, but it might require touching those lines twice.
> > So I guess this is OK.
> I've have tried it, but yes it's more changes and there is also
> chicken/egg problem, cleanest way I've stopped at is to get rid of
> cpu_model fallback + cpu_generic_init() in one go.

OK

> 
>  
> > >  armv7m = qdev_create(NULL, "armv7m");
> > >  qdev_prop_set_uint32(armv7m, "num-irq", num_irq);
> > > -qdev_prop_set_string(armv7m, "cpu-model", cpu_model);
> > > +qdev_prop_set_string(armv7m, "cpu-type", cpu_type);
> > >  object_property_set_link(OBJECT(armv7m), OBJECT(get_system_memory()),
> > >   "memory", _abort);
> > > -/* This will exit with an error if the user passed us a bad 
> > > cpu_model */
> > > +/* This will exit with an error if the user passed us a bad cpu_type 
> > > */
> > >  qdev_init_nofail(armv7m);
> > >  
> > >  armv7m_load_kernel(ARM_CPU(first_cpu), kernel_filename, mem_size);
> [...]
> 
> > > diff --git a/hw/arm/highbank.c b/hw/arm/highbank.c
> > > index 20e60f1..0d7190a 100644
> > > --- a/hw/arm/highbank.c
> > > +++ b/hw/arm/highbank.c
> > > @@ -219,7 +219,6 @@ enum cxmachines {
> > >  static void calxeda_init(MachineState *machine, enum cxmachines 
> > > machine_id)
> > >  {
> > >  ram_addr_t ram_size = machine->ram_size;
> > > -const char *cpu_model = machine->cpu_model;
> > >  const char *kernel_filename = machine->kernel_filename;
> > >  const char *kernel_cmdline = machine->kernel_cmdline;
> > >  const char *initrd_filename = machine->initrd_filename;
> > > @@ -236,19 +235,20 @@ static void calxeda_init(MachineState *machine, 
> > > enum cxmachines machine_id)
> > >  
> > >  switch (machine_id) {
> > >  case CALXEDA_HIGHBANK:
> > > -cpu_model = "cortex-a9";
> > > +machine->cpu_type = ARM_CPU_TYPE_NAME("cortex-a9");
> > >  break;
> > >  case CALXEDA_MIDWAY:
> > > -cpu_model = "cortex-a15";
> > > +machine->cpu_type = ARM_CPU_TYPE_NAME("cortex-a15");
> > >  break;
> > > +default:
> > > +assert(0);
> > >  }  
> > 
> > Why not delete this switch statement completely and set
> > default_cpu_type at midway_class_init() and
> > highbank_class_init()?
> it would allow '-cpu foo' to take effect which isn't what current code does,
> as series 

Re: [Qemu-devel] [PATCH v5 3/3] watchdog: Allow setting action on the fly

[Daniel P. Berrange]

On Thu, Sep 07, 2017 at 10:05:26AM +0200, Michal Privoznik wrote:
> Currently, the only time that users can set watchdog action is at
> the start as all we expose is this -watchdog-action command line
> argument. This is suboptimal when users want to plug the device
> later via monitor. Alternatively, they might want to change the
> action for already existing device on the fly.
> 
> Inspired by: https://bugzilla.redhat.com/show_bug.cgi?id=1447169
> 
> Signed-off-by: Michal Privoznik 
> ---
>  hw/watchdog/watchdog.c | 8 +++-
>  qapi-schema.json   | 9 +
>  2 files changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/watchdog/watchdog.c b/hw/watchdog/watchdog.c
> index 0d3eeed187..670114ecfe 100644
> --- a/hw/watchdog/watchdog.c
> +++ b/hw/watchdog/watchdog.c
> @@ -29,6 +29,7 @@
>  #include "qapi-event.h"
>  #include "hw/nmi.h"
>  #include "qemu/help_option.h"
> +#include "qmp-commands.h"
>  
>  static WatchdogAction watchdog_action = WATCHDOG_ACTION_RESET;
>  static QLIST_HEAD(watchdog_list, WatchdogTimerModel) watchdog_list;
> @@ -85,7 +86,7 @@ int select_watchdog_action(const char *p)
>  g_free(qapi_value);
>  if (action < 0)
>  return -1;
> -watchdog_action = action;
> +qmp_watchdog_set_action(action, _abort);
>  return 0;
>  }
>  
> @@ -142,3 +143,8 @@ void watchdog_perform_action(void)
>  assert(0);
>  }
>  }
> +
> +void qmp_watchdog_set_action(WatchdogAction action, Error **errp)
> +{
> +watchdog_action = action;
> +}
> diff --git a/qapi-schema.json b/qapi-schema.json
> index f3af2cb851..f5db401838 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -3143,3 +3143,12 @@
>  # Since 2.9
>  ##
>  { 'command': 'query-vm-generation-id', 'returns': 'GuidInfo' }
> +
> +##
> +# @watchdog-set-action:
> +#
> +# Set watchdog action
> +#
> +# Since 2.11

Not sure how much it matters, but the standard syntax has a ':' following
the 'Since' word

I do notice that query-vm-generation-id violates this rule though, which
I what I guess you copied ?

> +##
> +{ 'command': 'watchdog-set-action', 'data' : {'action': 'WatchdogAction'} }
> --

Assuming the ':' is added in next posting (or by the committer), then

Reviewed-by: Daniel P. Berrange 

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 :|

Re: [Qemu-devel] [PATCH 02/27] libvhost-user: drop dependency on glib

[Marc-André Lureau]

Hi

- Original Message -
> Hi Marc-André,
> 
> On 08/23/2017 01:19 PM, Marc-André Lureau wrote:
> > libvhost-user is meant to be free of glib dependency. Make sure it is
> > by droping qemu/osdep.h (which included glib.h)
> > 
> > This fixes a bad malloc()/g_free() pair.
> > 
> > Signed-off-by: Marc-André Lureau 
> > ---
> >   contrib/libvhost-user/libvhost-user.c | 25 ++---
> >   1 file changed, 22 insertions(+), 3 deletions(-)
> > 
> > diff --git a/contrib/libvhost-user/libvhost-user.c
> > b/contrib/libvhost-user/libvhost-user.c
> > index 35fa0c5e56..bb294c6ef7 100644
> > --- a/contrib/libvhost-user/libvhost-user.c
> > +++ b/contrib/libvhost-user/libvhost-user.c
> > @@ -13,11 +13,22 @@
> >* later.  See the COPYING file in the top-level directory.
> >*/
> >   
> > -#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> >   #include 
> > +#include 
> >   #include 
> >   
> >   #include "qemu/atomic.h"
> > +#include "qemu/compiler.h"
> >   
> >   #include "libvhost-user.h"
> >   
> > @@ -34,6 +45,14 @@
> >   }   \
> >   } while (0)
> >   
> > +#ifndef MIN
> > +#define MIN(x, y) ({\
> > +typeof(x) _min1 = (x);  \
> > +typeof(y) _min2 = (y);  \
> > +(void) (&_min1 == &_min2);  \
> > +_min1 < _min2 ? _min1 : _min2; })
> 
> why not add this in qemu/compiler.h instead?

It's a special case here, because libvhost-user doesn't depend on glib. The 
rest of qemu does. Since MIN/MAX is defined by glib, I don't think 
qemu/compiler.h should define it.

> 
> > +#endif
> > +
> >   static const char *
> >   vu_request_to_string(int req)
> >   {
> > @@ -81,7 +100,7 @@ vu_panic(VuDev *dev, const char *msg, ...)
> >   va_list ap;
> >   
> >   va_start(ap, msg);
> > -buf = g_strdup_vprintf(msg, ap);
> > +vasprintf(, msg, ap);
> >   va_end(ap);
> >   
> >   dev->broken = true;
> > @@ -840,7 +859,7 @@ vu_dispatch(VuDev *dev)
> >   success = true;
> >   
> >   end:
> > -g_free(vmsg.data);
> > +free(vmsg.data);
> >   return success;
> >   }
> >   
> > 
> 

Re: [Qemu-devel] [PATCH 02/27] libvhost-user: drop dependency on glib

[Philippe Mathieu-Daudé]

On 09/12/2017 10:13 AM, Marc-André Lureau wrote:

Hi

- Original Message -

Hi Marc-André,

On 08/23/2017 01:19 PM, Marc-André Lureau wrote:

libvhost-user is meant to be free of glib dependency. Make sure it is
by droping qemu/osdep.h (which included glib.h)

This fixes a bad malloc()/g_free() pair.

Signed-off-by: Marc-André Lureau 
---
   contrib/libvhost-user/libvhost-user.c | 25 ++---
   1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/contrib/libvhost-user/libvhost-user.c
b/contrib/libvhost-user/libvhost-user.c
index 35fa0c5e56..bb294c6ef7 100644
--- a/contrib/libvhost-user/libvhost-user.c
+++ b/contrib/libvhost-user/libvhost-user.c
@@ -13,11 +13,22 @@
* later.  See the COPYING file in the top-level directory.
*/
   


/* this code avoids GLib dependency */


-#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
   #include 
+#include 
   #include 
   
   #include "qemu/atomic.h"

+#include "qemu/compiler.h"
   
   #include "libvhost-user.h"
   
@@ -34,6 +45,14 @@

   }   \
   } while (0)
   
+#ifndef MIN


/* usually provided by GLib */


+#define MIN(x, y) ({\
+typeof(x) _min1 = (x);  \
+typeof(y) _min2 = (y);  \
+(void) (&_min1 == &_min2);  \
+_min1 < _min2 ? _min1 : _min2; })


why not add this in qemu/compiler.h instead?


It's a special case here, because libvhost-user doesn't depend on glib. The 
rest of qemu does. Since MIN/MAX is defined by glib, I don't think 
qemu/compiler.h should define it.


OK, with some comments about GLib Independence:

Reviewed-by: Philippe Mathieu-Daudé 






+#endif
+
   static const char *
   vu_request_to_string(int req)
   {
@@ -81,7 +100,7 @@ vu_panic(VuDev *dev, const char *msg, ...)
   va_list ap;
   
   va_start(ap, msg);

-buf = g_strdup_vprintf(msg, ap);
+vasprintf(, msg, ap);
   va_end(ap);
   
   dev->broken = true;

@@ -840,7 +859,7 @@ vu_dispatch(VuDev *dev)
   success = true;
   
   end:

-g_free(vmsg.data);
+free(vmsg.data);
   return success;
   }
   

Re: [Qemu-devel] [PATCH v7 09/38] libqos: Track QTestState with QVirtioBus

[Eric Blake]

On 09/12/2017 02:21 AM, Thomas Huth wrote:
> On 11.09.2017 19:19, Eric Blake wrote:
>> When initializing a QVirtioDevice (which always has an associated
>> QVirtioBus), we want to track which QTestState to use for all
>> I/O processed through that bus and device.  Copy the paradigm
>> used for QPCIBus, and track the test state at the bus level; this
>> in turn requires a separate bus object per device (and associated
>> cleanup) rather than just sharing a const version of the dispatch
>> table.
> I fail to see why we need a separate bus object here for each device.
> The bus is only available one time, not multiple times, isn't it? So
> there should also only be one bus object floating around, not multiple
> ones... or do I miss something?

You are right that there is only one bus for the machine - the problem
is that the object representing the bus is dynamically created on the
fly at the point where the device is first grabbed, rather than up front
as part of creating the machine (in other words, the device search is
not performed on a pre-existing bus object).

Contrast qpci_device_find() (lookup based on a pre-existing bus) with
qvirtio_mmio_init_device() (lookup that did not use a pre-existing bus);
also note that qvirtio_pci_device_find() takes a pre-existing QPCIBus
(since on that architecture, the QVirtioBus is itself a device on the
QPCIBus).

I suppose that we could indeed refactor the code to require callers to
create the QVirtioBus object up front, and then make the device lookup
(both qvirtio_mmio_init_device() and qvirtio_pci_device_find()) take a
QVirtioBus parameter instead of QTestState or QPCIBus.  That's slightly
more work, but I'm happy to attempt it if you think it will be better.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v7 10/38] libqos: Move/rename qpci_unplug_acpi_device_test() to pci.c

[Eric Blake]

On 09/12/2017 02:29 AM, Thomas Huth wrote:
> On 11.09.2017 19:19, Eric Blake wrote:
>> Commit 2f8b2767 originally added qpci_plug_device_test() and
>> qpci_unplug_acpi_device_test() as a pair, both in pci-pc.c.
>> Later, commit cf716b31 moved one half of the pair to pci.c
>> when adding PPC64 support.  Keep the implementations of the
>> two functions together, and shorten the name to
>> qpci_unplug_device_test(), since all callers use the two
>> functions in tandem.
>>

> 
> No, that's a bad idea. ACPI and that outb() is clearly something
> specific to x86, so this should not reside in pci.c but in pci-pc.c
> 
> We might be able to unify this - I've had a similar patch here:
> 
>  https://patchwork.kernel.org/patch/9905031/
> 
> ... but I think this needs some more careful thinking and discussion, so
> I'd suggest that you remove this from your already huge patch series for
> now and we fix it later instead.

Okay, I'm fine dropping this patch, and can base my respin on top of
your cleanup instead.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] question： I found a bug which will lead to qemu crash

[WangJie (Captain)]

Hi, Eric
I used git-bisect and fount the patch you commited（throttle: Remove block from 
group on hot-unplug） fixed the bug which I presented to Kevin

the patch which fixed the bug is： 
https://github.com/qemu/qemu/commit/1606e4cf8a976513ecac70ad6642a7ec45744cf5#diff-7cb66df56045598b75a219eebc27efb6


But the condition which I made to causes crash is differ in the condition you  
described in patch info, is it the same reason?

I feel very confused, please tell me, thank you :>


On 2017/9/12 19:17, WangJie (Captain) wrote:
> Hi, Kevin.
>
> I found a bug about qemu-kvm(version 2.7.0-rc0 adn 2.8.1). but qemu 2.6.0 and 
> current master is OK.
> So I git-bisect the master branch，and I found the patch you commited (block: 
> Decouple throttling from BlockDriverState) lead the bug into qemu.
>
> The patch which lead the bug into qemu: 
> (https://github.com/qemu/qemu/commit/7ca7f0f6db1fedd28d490795d778cf23979a2aa7#diff-ea36ba0f79150cc299732696a069caba)
>
> Because the current master is OK. So I think you had fixed it , can you tell 
> me which patch fixed the bug?Thank you :>
>
>
> the bug is that: qemu will crash when loop to attach and detach a disk which 
> configured qos to a VM for a while.
>
>
> *Segmentation fault info(qemu 2.7.0-rc0):*
> Using host libthread_db library "/lib64/libthread_db.so.1".
> Core was generated by `/usr/bin/qemu-kvm -name 
> guest=wangjie-i-clone203_rhel_7.3_64_guestosdev,debug-t'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x7fe960413e3c in throttle_group_next_blk (blk=0x11) at 
> block/throttle-groups.c:160
> 160ThrottleState *ts = blkp->throttle_state;
> Missing separate debuginfos, use: debuginfo-install glib2-2.40.0-4.x86_64 
> glibc-2.17-157.h5.x86_64 libaio-0.3.109-13.x86_64 libgcc-4.8.3-10.h1.x86_64 
> nettle-2.7.1-4.h1.x86_64 numactl-libs-2.0.9-4.x86_64 pixman-0.32.4-3.x86_64 
> zlib-1.2.7-14.x86_64
> (gdb) bt
> #0  0x7fe960413e3c in throttle_group_next_blk (blk=0x11) at 
> block/throttle-groups.c:160
> #1  0x7fe960413eff in next_throttle_token (blk=0x7fe963f5c400, 
> is_write=false) at block/throttle-groups.c:192
> #2  0x7fe9604141a8 in throttle_group_co_io_limits_intercept 
> (blk=0x7fe963f5c400, bytes=512, is_write=false)
> at block/throttle-groups.c:303
> #3  0x7fe960400048 in blk_co_preadv (blk=0x7fe963f5c400, offset=0, 
> bytes=512, qiov=0x7ffc37ee8aa0, flags=(unknown: 0))
> at block/block-backend.c:728
> #4  0x7fe960400159 in blk_read_entry (opaque=0x7ffc37ee8ac0) at 
> block/block-backend.c:769
> #5  0x7fe96048f4d7 in coroutine_trampoline (i0=1678853408, i1=32745) at 
> util/coroutine-ucontext.c:78
> #6  0x7fe95dfdacf0 in ?? () from /lib64/libc.so.6
> #7  0x7ffc37ee9c00 in ?? ()
> #8  0x in ?? ()
>
>
>
> *Segmentation fault info(qemu 2.8.1):*
> Program received signal SIGSEGV, Segmentation fault.
> 0x7f5469220607 in blk_has_pending_reqs (blk=0x7f54672a0032, 
> is_write=false) at block/throttle-groups.c:184
> 184return blkp->pending_reqs[is_write];
> (gdb) bt
> #0  0x7f5469220607 in blk_has_pending_reqs (blk=0x7f54672a0032, 
> is_write=false) at block/throttle-groups.c:184
> #1  0x7f54692206a8 in next_throttle_token (blk=0x7f546b6cd120, 
> is_write=false) at block/throttle-groups.c:207
> #2  0x7f5469220984 in throttle_group_co_io_limits_intercept 
> (blk=0x7f546b6cd120, bytes=512, is_write=false)
> at block/throttle-groups.c:322
> #3  0x7f546920bc79 in blk_co_preadv (blk=0x7f546b6cd120, offset=0, 
> bytes=512, qiov=0x7ffcc7355060, flags=0)
> at block/block-backend.c:815
> #4  0x7f546920bddf in blk_read_entry (opaque=0x7ffcc7355080) at 
> block/block-backend.c:865
> #5  0x7f54692a00f0 in coroutine_trampoline (i0=-588050448, i1=32595) at 
> util/coroutine-ucontext.c:79
> #6  0x7f5466f34cf0 in ?? () from /lib64/libc.so.6
> #7  0x7f53f27fa9e0 in ?? ()
> #8  0x in ?? ()
>
>
> *The way how to find the bug as follows:*
> *1、start a VM*
>
>
> *2、attach and detach a disk for a while，the configure of the disk (add-1.xml) 
> as follows*
> 
> 
> 
> 
> 
> 3000
> 3000
> 12000
> 12000
> 
> 
>
>
> *3、run below script for a while，the qemu process of  VM will crash*
> ret=1
> while [ $ret -ne 0 ]; do
> virsh attach-device i-clone203_rhel_7.3_64_guestosdev add-1.xml
> sleep 2
> virsh detach-device i-clone203_rhel_7.3_64_guestosdev add-1.xml
> done
>

Re: [Qemu-devel] [PATCH] scripts: let checkpatch.pl process an entire GIT branch

[John Snow]

On 09/12/2017 12:24 PM, Paolo Bonzini wrote:
> On 12/09/2017 18:22, Daniel P. Berrange wrote:
>> On Tue, Sep 12, 2017 at 06:14:57PM +0200, Paolo Bonzini wrote:
>>> On 12/09/2017 18:12, Daniel P. Berrange wrote:
 On Tue, Sep 12, 2017 at 05:52:18PM +0200, Paolo Bonzini wrote:
> On 12/09/2017 12:46, Daniel P. Berrange wrote:
>> Currently before submitting a series, devs should run checkpatch.pl
>> across each patch to be submitted. This can be automated using a
>> command such as:
>>
>>   git rebase -i master -x 'git show | ./scripts/checkpatch.pl -'
>>
>> This is rather long winded to type, so this patch introduces a new
>> flag '--branch' to checkpatch.pl which instructs it to check every
>> patch on the current GIT branch.
>
> Great idea, though I'm not sure about having a default.  And to keep it
> easy to invoke, having a sole argument that ends with ".." might DWIM
> and enable --branch too...

 I think it is beneficial to have a default, as I figure the majority
 of contributors are working on a branch that's rebased against master..
 Half as many characters to type in the common case :-)
>>>
>>> With the DWIM option "--branch" and "master.." are exactly the same
>>> length. :)
>>
>> Oh hang on. I think I misunderstood what you suggested. I thought you
>> meant  'checkpatch.pl --branch master..', but IIUC you actually mean
>> 'checkpatch.pl master..' with no flag. That would work with me.
> 
> Yes, basically if length(argv) == 1 and argv[0] ends with ".." then
> enable branch.  The default for --branch with no ARGV could be
> "origin/master.."---or it could ask git-config for the upstream tracking
> branch but maybe that's too much to ask.
> 
> Paolo
> 

~Crazy suggestion~ is that the default could actually be "@{upstream}.."
which will default to whatever you've configured the upstream to be in
the branch you're working in.

Downside is that if you don't set the tracking branch during branch
creation (`git checkout -b myTopic origin/master`) or at a later date
(`git branch --set-upstream-to=origin/master`) that this reference won't
resolve.

You can check and see if it resolves to anything programmatically, though:

jhuston@probe (review) ~/s/qemu> git rev-parse "@{upstream}"
04ef33052c205170c92df21ca0b4be4f3b102188
jhuston@probe (review) ~/s/qemu> echo $status
0


jhuston@probe (master) ~/s/qemu> git checkout -b foobar
Switched to a new branch 'foobar'
jhuston@probe (foobar) ~/s/qemu> git rev-parse "@{upstream}"
fatal: no upstream configured for branch 'foobar'
jhuston@probe (foobar) ~/s/qemu> echo $status
128

[Qemu-devel] [PATCH 01/19] target/arm: Implement MSR/MRS access to NS banked registers

[Peter Maydell]

In v8M the MSR and MRS instructions have extra register value
encodings to allow secure code to access the non-secure banked
version of various special registers.

(We don't implement the MSPLIM_NS or PSPLIM_NS aliases, because
we don't currently implement the stack limit registers at all.)

Signed-off-by: Peter Maydell 
---
 target/arm/helper.c | 110 
 1 file changed, 110 insertions(+)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index 4f41841..f4f2a87 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -8892,12 +8892,68 @@ uint32_t HELPER(v7m_mrs)(CPUARMState *env, uint32_t reg)
 break;
 case 20: /* CONTROL */
 return env->v7m.control[env->v7m.secure];
+case 0x94: /* CONTROL_NS */
+/* We have to handle this here because unprivileged Secure code
+ * can read the NS CONTROL register.
+ */
+if (!env->v7m.secure) {
+return 0;
+}
+return env->v7m.control[M_REG_NS];
 }
 
 if (el == 0) {
 return 0; /* unprivileged reads others as zero */
 }
 
+if (arm_feature(env, ARM_FEATURE_M_SECURITY)) {
+switch (reg) {
+case 0x88: /* MSP_NS */
+if (!env->v7m.secure) {
+return 0;
+}
+return env->v7m.other_ss_msp;
+case 0x89: /* PSP_NS */
+if (!env->v7m.secure) {
+return 0;
+}
+return env->v7m.other_ss_psp;
+case 0x90: /* PRIMASK_NS */
+if (!env->v7m.secure) {
+return 0;
+}
+return env->v7m.primask[M_REG_NS];
+case 0x91: /* BASEPRI_NS */
+if (!env->v7m.secure) {
+return 0;
+}
+return env->v7m.basepri[M_REG_NS];
+case 0x93: /* FAULTMASK_NS */
+if (!env->v7m.secure) {
+return 0;
+}
+return env->v7m.faultmask[M_REG_NS];
+case 0x98: /* SP_NS */
+{
+/* This gives the non-secure SP selected based on whether we're
+ * currently in handler mode or not, using the NS CONTROL.SPSEL.
+ */
+bool spsel = env->v7m.control[M_REG_NS] & R_V7M_CONTROL_SPSEL_MASK;
+
+if (!env->v7m.secure) {
+return 0;
+}
+if (!arm_v7m_is_handler_mode(env) && spsel) {
+return env->v7m.other_ss_psp;
+} else {
+return env->v7m.other_ss_msp;
+}
+}
+default:
+break;
+}
+}
+
 switch (reg) {
 case 8: /* MSP */
 return (env->v7m.control[env->v7m.secure] & R_V7M_CONTROL_SPSEL_MASK) ?
@@ -8936,6 +8992,60 @@ void HELPER(v7m_msr)(CPUARMState *env, uint32_t maskreg, 
uint32_t val)
 return;
 }
 
+if (arm_feature(env, ARM_FEATURE_M_SECURITY)) {
+switch (reg) {
+case 0x88: /* MSP_NS */
+if (!env->v7m.secure) {
+return;
+}
+env->v7m.other_ss_msp = val;
+return;
+case 0x89: /* PSP_NS */
+if (!env->v7m.secure) {
+return;
+}
+env->v7m.other_ss_psp = val;
+return;
+case 0x90: /* PRIMASK_NS */
+if (!env->v7m.secure) {
+return;
+}
+env->v7m.primask[M_REG_NS] = val & 1;
+return;
+case 0x91: /* BASEPRI_NS */
+if (!env->v7m.secure) {
+return;
+}
+env->v7m.basepri[M_REG_NS] = val & 0xff;
+return;
+case 0x93: /* FAULTMASK_NS */
+if (!env->v7m.secure) {
+return;
+}
+env->v7m.faultmask[M_REG_NS] = val & 1;
+return;
+case 0x98: /* SP_NS */
+{
+/* This gives the non-secure SP selected based on whether we're
+ * currently in handler mode or not, using the NS CONTROL.SPSEL.
+ */
+bool spsel = env->v7m.control[M_REG_NS] & R_V7M_CONTROL_SPSEL_MASK;
+
+if (!env->v7m.secure) {
+return;
+}
+if (!arm_v7m_is_handler_mode(env) && spsel) {
+env->v7m.other_ss_psp = val;
+} else {
+env->v7m.other_ss_msp = val;
+}
+return;
+}
+default:
+break;
+}
+}
+
 switch (reg) {
 case 0 ... 7: /* xPSR sub-fields */
 /* only APSR is actually writable */
-- 
2.7.4

[Qemu-devel] [PATCH 12/19] nvic: In escalation to HardFault, support HF not being priority -1

[Peter Maydell]

When escalating to HardFault, we must go into Lockup if we
can't take the synchronous HardFault because the current
execution priority is already at or below the priority of
HardFault. In v7M HF is always priority -1 so a simple < 0
comparison sufficed; in v8M the priority of HardFault can
vary depending on whether it is a Secure or NonSecure
HardFault, so we must check against the priority of the
HardFault exception vector we're about to use.

Signed-off-by: Peter Maydell 
---
 hw/intc/armv7m_nvic.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/hw/intc/armv7m_nvic.c b/hw/intc/armv7m_nvic.c
index 3361a28..c4670f7 100644
--- a/hw/intc/armv7m_nvic.c
+++ b/hw/intc/armv7m_nvic.c
@@ -487,18 +487,8 @@ void armv7m_nvic_set_pending(void *opaque, int irq, bool 
secure)
 }
 
 if (escalate) {
-if (running < 0) {
-/* We want to escalate to HardFault but we can't take a
- * synchronous HardFault at this point either. This is a
- * Lockup condition due to a guest bug. We don't model
- * Lockup, so report via cpu_abort() instead.
- */
-cpu_abort(>cpu->parent_obj,
-  "Lockup: can't escalate %d to HardFault "
-  "(current priority %d)\n", irq, running);
-}
 
-/* We can do the escalation, so we take HardFault instead.
+/* We need to escalate this exception to a synchronous HardFault.
  * If BFHFNMINS is set then we escalate to the banked HF for
  * the target security state of the original exception; otherwise
  * we take a Secure HardFault.
@@ -511,6 +501,17 @@ void armv7m_nvic_set_pending(void *opaque, int irq, bool 
secure)
 } else {
 vec = >vectors[irq];
 }
+if (running <= vec->prio) {
+/* We want to escalate to HardFault but we can't take the
+ * synchronous HardFault at this point either. This is a
+ * Lockup condition due to a guest bug. We don't model
+ * Lockup, so report via cpu_abort() instead.
+ */
+cpu_abort(>cpu->parent_obj,
+  "Lockup: can't escalate %d to HardFault "
+  "(current priority %d)\n", irq, running);
+}
+
 /* HF may be banked but there is only one shared HFSR */
 s->cpu->env.v7m.hfsr |= R_V7M_HFSR_FORCED_MASK;
 }
-- 
2.7.4

[Qemu-devel] [PATCH 19/19] nvic: Support banked exceptions in acknowledge and complete

[Peter Maydell]

Update armv7m_nvic_acknowledge_irq() and armv7m_nvic_complete_irq()
to handle banked exceptions:
 * acknowledge needs to use the correct vector, which may be
   in sec_vectors[]
 * acknowledge needs to return to its caller whether the
   exception should be taken to secure or non-secure state
 * complete needs its caller to tell it whether the exception
   being completed is a secure one or not

Signed-off-by: Peter Maydell 
---
 target/arm/cpu.h  | 15 +--
 hw/intc/armv7m_nvic.c | 26 --
 target/arm/helper.c   |  8 +---
 hw/intc/trace-events  |  4 ++--
 4 files changed, 40 insertions(+), 13 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 02be3ca..9c336bc 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -1476,18 +1476,29 @@ static inline bool 
armv7m_nvic_can_take_pending_exception(void *opaque)
  * of architecturally banked exceptions.
  */
 void armv7m_nvic_set_pending(void *opaque, int irq, bool secure);
-void armv7m_nvic_acknowledge_irq(void *opaque);
+/**
+ * armv7m_nvic_acknowledge_irq: make highest priority pending exception active
+ * @opaque: the NVIC
+ *
+ * Move the current highest priority pending exception from the pending
+ * state to the active state, and update v7m.exception to indicate that
+ * it is the exception currently being handled.
+ *
+ * Returns: true if exception should be taken to Secure state, false for NS
+ */
+bool armv7m_nvic_acknowledge_irq(void *opaque);
 /**
  * armv7m_nvic_complete_irq: complete specified interrupt or exception
  * @opaque: the NVIC
  * @irq: the exception number to complete
+ * @secure: true if this exception was secure
  *
  * Returns: -1 if the irq was not active
  *   1 if completing this irq brought us back to base (no active irqs)
  *   0 if there is still an irq active after this one was completed
  * (Ignoring -1, this is the same as the RETTOBASE value before completion.)
  */
-int armv7m_nvic_complete_irq(void *opaque, int irq);
+int armv7m_nvic_complete_irq(void *opaque, int irq, bool secure);
 /**
  * armv7m_nvic_raw_execution_priority: return the raw execution priority
  * @opaque: the NVIC
diff --git a/hw/intc/armv7m_nvic.c b/hw/intc/armv7m_nvic.c
index 9613990..078532a 100644
--- a/hw/intc/armv7m_nvic.c
+++ b/hw/intc/armv7m_nvic.c
@@ -586,24 +586,32 @@ void armv7m_nvic_set_pending(void *opaque, int irq, bool 
secure)
 }
 
 /* Make pending IRQ active.  */
-void armv7m_nvic_acknowledge_irq(void *opaque)
+bool armv7m_nvic_acknowledge_irq(void *opaque)
 {
 NVICState *s = (NVICState *)opaque;
 CPUARMState *env = >cpu->env;
 const int pending = s->vectpending;
 const int running = nvic_exec_prio(s);
 VecInfo *vec;
+bool targets_secure;
 
 assert(pending > ARMV7M_EXCP_RESET && pending < s->num_irq);
 
-vec = >vectors[pending];
+if (s->vectpending_is_s_banked) {
+vec = >sec_vectors[pending];
+targets_secure = true;
+} else {
+vec = >vectors[pending];
+targets_secure = !exc_is_banked(s->vectpending) &&
+exc_targets_secure(s, s->vectpending);
+}
 
 assert(vec->enabled);
 assert(vec->pending);
 
 assert(s->vectpending_prio < running);
 
-trace_nvic_acknowledge_irq(pending, s->vectpending_prio);
+trace_nvic_acknowledge_irq(pending, s->vectpending_prio, targets_secure);
 
 vec->active = 1;
 vec->pending = 0;
@@ -611,9 +619,11 @@ void armv7m_nvic_acknowledge_irq(void *opaque)
 env->v7m.exception = s->vectpending;
 
 nvic_irq_update(s);
+
+return targets_secure;
 }
 
-int armv7m_nvic_complete_irq(void *opaque, int irq)
+int armv7m_nvic_complete_irq(void *opaque, int irq, bool secure)
 {
 NVICState *s = (NVICState *)opaque;
 VecInfo *vec;
@@ -621,9 +631,13 @@ int armv7m_nvic_complete_irq(void *opaque, int irq)
 
 assert(irq > ARMV7M_EXCP_RESET && irq < s->num_irq);
 
-vec = >vectors[irq];
+if (secure && exc_is_banked(irq)) {
+vec = >sec_vectors[irq];
+} else {
+vec = >vectors[irq];
+}
 
-trace_nvic_complete_irq(irq);
+trace_nvic_complete_irq(irq, secure);
 
 if (!vec->active) {
 /* Tell the caller this was an illegal exception return */
diff --git a/target/arm/helper.c b/target/arm/helper.c
index b64acd8..8be78ea 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -6218,6 +6218,7 @@ static void do_v7m_exception_exit(ARMCPU *cpu)
 bool return_to_sp_process = false;
 bool return_to_handler = false;
 bool rettobase = false;
+bool exc_secure = false;
 
 /* We can only get here from an EXCP_EXCEPTION_EXIT, and
  * gen_bx_excret() enforces the architectural rule
@@ -6256,16 +6257,17 @@ static void do_v7m_exception_exit(ARMCPU *cpu)
  * which security state's faultmask to clear. (v8M ARM ARM R_KBNF.)
  */
 if (arm_feature(env, ARM_FEATURE_M_SECURITY)) {
-int es = excret & R_V7M_EXCRET_ES_MASK;

Re: [Qemu-devel] Monitor socket will close after parse command error. Qemu-2.6.2

[Dr. David Alan Gilbert]

* Sam (batmanu...@gmail.com) wrote:
> [gangyewei-3@yf-mos-test-net07 tests]$ telnet 127.0.0.1 55919
> Trying 127.0.0.1...
> Connected to 127.0.0.1.
> Escape character is '^]'.
> QEMU 2.6.2 monitor - type 'help' for more information
> (qemu) chardev-add
> socket,id=char-test_intf1,path=/usr/local/var/run/openvswitch/test_intf1,server=on
> chardev-add
> socket,id=char-test_intf1,path=/usr/local/var/run/openvswitch/test_intf1,server=on
> (qemu)
> (qemu) netdev_add
> vhost-user,id=test_intf1,chardev=char-test_intf1,vhostforce=on
> netdev_add vhost-user,id=test_intf1,chardev=char-test_intf1,vhostforce=on
> (qemu)
> (qemu) device_add
> virtio-net-pci,netdev=test_intf1,mac=00:22:79:29:d2:6c,id=netdev-test_intf1
> device_add
> virtio-net-pci,netdev=test_intf1,mac=00:22:79:29:d2:6c,id=netdev-test_intf1
> (qemu)
> (qemu) device_del netdev-test_intf1
> device_del netdev-test_intf1
> (qemu)
> (qemu) netdev_del test_intf1
> netdev_del test_intf1
> (qemu)
> (qemu) chardev-remove char-test_intf1
> chardev-remove char-test_intf1
> Chardev 'char-test_intf1' is busy
> (qemu)
> (qemu) chardev-remove char-test_intf1
> chardev-remove char-test_intf1
> Chardev 'char-test_intf1' is busy
> (qemu)
> (qemu) chardev-remove char-test_intf1
> chardev-remove char-test_intf1
> Chardev 'char-test_intf1' is busy
> (qemu)
> (qemu) chardev-add
> socket,id=char-test_intf1,path=/usr/local/var/run/openvswitch/test_intf1,server=on
> chardev-add
> socket,id=char-test_intf1,path=/usr/local/var/run/openvswitch/test_intf1,server=on
> Duplicate ID 'char-test_intf1' for chardev
> Parsing chardev args failed
> (qemu)
> (qemu) ^[[A^[[A
> chardev-remove char-test_intf1
> Chardev 'char-test_intf1' is busy
> (qemu)
> (qemu)
> 
> (qemu)
> (qemu)
> 
> (qemu)
> (qemu) netdev_add
> vhost-user,id=test_intf1,chardev=char-test_intf1,vhostforce=on
> netdev_add vhost-user,id=test_intf1,chardev=char-test_intf1,vhostforce=on
> Connection closed by foreign host.

Is QEMU just crashing at that point?  i.e. segfaulting or aborting?

Dave

> 2017-09-08 11:32 GMT+08:00 Sam :
> 
> > BTW, same result while using `telnet 127.0.0.1 55919`, which means also
> > have the two problem in the email before.
> >
> > 2017-09-08 11:23 GMT+08:00 Sam :
> >
> >> Hi all,
> >>
> >> I'm using HMP socket to send command to add netdev, my command like this:
> >>
> >> [gangyewei-3@yf-mos-test-net07 tests]$ sudo  python monitor.py 55919
> >>> (qemu):
> >>>  Connected to qemu monitor ...
> >>> on_monitor_open
> >>> ds
> >>> (qemu):
> >>> {'return': ["unknown command: 'ds'"]}
> >>> chardev-add socket,id=char-test_intf1,path=/usr/local/var/run/openvswitc
> >>> h/test_intf1,server=on
> >>> (qemu):
> >>> \{'return': []}
> >>> netdev_add vhost-user,id=test_intf1,chardev=char-test_intf1,vhostforce=
> >>> on
> >>> (qemu):
> >>> {'return': ["unknown command: '\\netdev_add'"]}
> >>> netdev_add vhost-user,id=test_intf1,chardev=char-test_intf1,vhostforce=
> >>> on
> >>> (qemu):
> >>> {'return': []}
> >>> device_add virtio-net-pci,netdev=test_intf1,mac=00:22:79:29:d2:6c,id=
> >>> netdev-test_intf1
> >>> (qemu):
> >>> {'return': []}
> >>> device_del netdev-test_intf1
> >>> (qemu):
> >>> {'return': []}
> >>> netdev_del test_intf1
> >>> (qemu):
> >>> {'return': []}
> >>> chardev-remove char-test_intf1
> >>> (qemu):
> >>> {'return': ["Chardev 'char-test_intf1' is busy"]}
> >>> chardev-remove char-test_intf1
> >>> (qemu):
> >>> {'return': ["Chardev 'char-test_intf1' is busy"]}
> >>> ds
> >>> (qemu):
> >>> {'return': ["unknown command: 'ds'"]}
> >>> chardev-add socket,id=char-test_intf1,path=/usr/local/var/run/openvswitc
> >>> h/test_intf1,server=on
> >>> (qemu):
> >>> {'return': ["Duplicate ID 'char-test_intf1' for chardev", 'Parsing
> >>> chardev args failed']}
> >>> netdev_add vhost-user,id=test_intf1,chardev=char-test_intf1,vhostforce=
> >>> on
> >>> (qemu):
> >>> on_monitor_close
> >>> Disconnect ...
> >>> Bye...
> >>> [gangyewei-3@yf-mos-test-net07 tests]$ telnet 127.0.0.1 55919
> >>> Trying 127.0.0.1...
> >>> telnet: connect to address 127.0.0.1: Connection refused
> >>
> >>
> >> the monitor.py is same like telnet, which send command to 127.0.0.1:55919
> >> socket.
> >> At the last 5th line, you could see "on_monitor_close", this is because
> >> server side of 127.0.0.1:55919 socket is down.
> >>
> >> I have few questions:
> >> 1. Why I got "{'return': ["Chardev 'char-test_intf1' is busy"]}" while
> >> using "chardev-remove char-test_intf1"?
> >> 2. Why the server side will close while get "{'return': ["Duplicate ID
> >> 'char-test_intf1' for chardev", 'Parsing chardev args failed']}" and then
> >> send same command?
> >>
> >> Thank you~
> >>
> >
> >
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

[Qemu-devel] [PATCH 17/19] nvic: Make ICSR banked for v8M

[Peter Maydell]

The ICSR NVIC register is banked for v8M. This doesn't
require any new state, but it does mean that some bits
are controlled by BFHNFNMINS and some bits must work
with the correct banked exception. There is also a new
in v8M PENDNMICLR bit.

Signed-off-by: Peter Maydell 
---
 hw/intc/armv7m_nvic.c | 45 -
 1 file changed, 32 insertions(+), 13 deletions(-)

diff --git a/hw/intc/armv7m_nvic.c b/hw/intc/armv7m_nvic.c
index 5e5aecd..21fd199 100644
--- a/hw/intc/armv7m_nvic.c
+++ b/hw/intc/armv7m_nvic.c
@@ -703,7 +703,7 @@ static uint32_t nvic_readl(NVICState *s, uint32_t offset, 
MemTxAttrs attrs)
 }
 case 0xd00: /* CPUID Base.  */
 return cpu->midr;
-case 0xd04: /* Interrupt Control State.  */
+case 0xd04: /* Interrupt Control State (ICSR) */
 /* VECTACTIVE */
 val = cpu->env.v7m.exception;
 /* VECTPENDING */
@@ -716,19 +716,32 @@ static uint32_t nvic_readl(NVICState *s, uint32_t offset, 
MemTxAttrs attrs)
 if (nvic_rettobase(s)) {
 val |= (1 << 11);
 }
-/* PENDSTSET */
-if (s->vectors[ARMV7M_EXCP_SYSTICK].pending) {
-val |= (1 << 26);
-}
-/* PENDSVSET */
-if (s->vectors[ARMV7M_EXCP_PENDSV].pending) {
-val |= (1 << 28);
+if (attrs.secure) {
+/* PENDSTSET */
+if (s->sec_vectors[ARMV7M_EXCP_SYSTICK].pending) {
+val |= (1 << 26);
+}
+/* PENDSVSET */
+if (s->sec_vectors[ARMV7M_EXCP_PENDSV].pending) {
+val |= (1 << 28);
+}
+} else {
+/* PENDSTSET */
+if (s->vectors[ARMV7M_EXCP_SYSTICK].pending) {
+val |= (1 << 26);
+}
+/* PENDSVSET */
+if (s->vectors[ARMV7M_EXCP_PENDSV].pending) {
+val |= (1 << 28);
+}
 }
 /* NMIPENDSET */
-if (s->vectors[ARMV7M_EXCP_NMI].pending) {
+if ((cpu->env.v7m.aircr & R_V7M_AIRCR_BFHFNMINS_MASK) &&
+s->vectors[ARMV7M_EXCP_NMI].pending) {
 val |= (1 << 31);
 }
-/* ISRPREEMPT not implemented */
+/* ISRPREEMPT: RES0 when halting debug not implemented */
+/* STTNS: RES0 for the Main Extension */
 return val;
 case 0xd08: /* Vector Table Offset.  */
 return cpu->env.v7m.vecbase[attrs.secure];
@@ -953,9 +966,15 @@ static void nvic_writel(NVICState *s, uint32_t offset, 
uint32_t value,
 nvic_irq_update(s);
 break;
 }
-case 0xd04: /* Interrupt Control State.  */
-if (value & (1 << 31)) {
-armv7m_nvic_set_pending(s, ARMV7M_EXCP_NMI, false);
+case 0xd04: /* Interrupt Control State (ICSR) */
+if (cpu->env.v7m.aircr & R_V7M_AIRCR_BFHFNMINS_MASK) {
+if (value & (1 << 31)) {
+armv7m_nvic_set_pending(s, ARMV7M_EXCP_NMI, false);
+} else if (value & (1 << 30) &&
+   arm_feature(>env, ARM_FEATURE_V8)) {
+/* PENDNMICLR didn't exist in v7M */
+armv7m_nvic_clear_pending(s, ARMV7M_EXCP_NMI, false);
+}
 }
 if (value & (1 << 28)) {
 armv7m_nvic_set_pending(s, ARMV7M_EXCP_PENDSV, attrs.secure);
-- 
2.7.4

Re: [Qemu-devel] [PATCH v2 07/16] target/arm: Align vector registers

[Peter Maydell]

On 12 September 2017 at 17:25, Richard Henderson
 wrote:
> Signed-off-by: Richard Henderson 
> ---
>  target/arm/cpu.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index 98b9b26fd3..419f008277 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -486,7 +486,7 @@ typedef struct CPUARMState {
>   * the two execution states, and means we do not need to explicitly
>   * map these registers when changing states.
>   */
> -float64 regs[64];
> +float64 regs[64] __attribute__((aligned(16)));
>
>  uint32_t xregs[16];
>  /* We store these fpcsr fields separately for convenience.  */
> --
> 2.13.5

I notice we have a QEMU_ALIGNED() macro to wrap the __attribute__,
though we use it less often than not at the moment...

thanks
-- PMM

Re: [Qemu-devel] [PATCH v4 1/8] hw/i386: Improve some of the warning messages

[Eduardo Habkost]

On Mon, Sep 11, 2017 at 12:52:43PM -0700, Alistair Francis wrote:
> Signed-off-by: Alistair Francis 
> Suggested-by: Eduardo Habkost 
> Cc: Eduardo Habkost 
> ---
> V4:
>  - Fixup pc_q35.c message
> V3:
>  - Improve the messages
> 

Reviewed-by: Eduardo Habkost 

-- 
Eduardo

Re: [Qemu-devel] [PATCH v2 07/16] target/arm: Align vector registers

[Philippe Mathieu-Daudé]

Hi Richard,

On 09/12/2017 01:25 PM, Richard Henderson wrote:

Signed-off-by: Richard Henderson 
---
  target/arm/cpu.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 98b9b26fd3..419f008277 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -486,7 +486,7 @@ typedef struct CPUARMState {
   * the two execution states, and means we do not need to explicitly
   * map these registers when changing states.
   */
-float64 regs[64];
+float64 regs[64] __attribute__((aligned(16)));


I understand this should be aligned to the biggest vector register the 
host support, i.e. for AVX-512 this would be QEMU_ALIGNED(64), is it 
correct?


I'd rather use a #define such HOST_VECTOR_LENGTH_BITS_MAX and 
QEMU_ALIGNED(HOST_VECTOR_LENGTH_BITS_MAX / BITS_PER_BYTE) or directly 
QEMU_ALIGNED(HOST_VECTOR_LENGTH_MAX), using the define makes it 
self-explanatory. Or shorter:


float64 regs[64] QEMU_ALIGNED(HOST_VECTOR_SIZE);

What do you think?

Regards,

Phil.

  
  uint32_t xregs[16];

  /* We store these fpcsr fields separately for convenience.  */

[Qemu-devel] [PATCH 03/19] nvic: Add cached vectpending_is_s_banked state

[Peter Maydell]

With banked exceptions, just the exception number in
s->vectpending is no longer sufficient to uniquely identify
the pending exception. Add a vectpending_is_s_banked bool
which is true if the exception is using the sec_vectors[]
array.

Signed-off-by: Peter Maydell 
---
 include/hw/intc/armv7m_nvic.h | 11 +--
 hw/intc/armv7m_nvic.c |  1 +
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/include/hw/intc/armv7m_nvic.h b/include/hw/intc/armv7m_nvic.h
index 317601e..87c78b3 100644
--- a/include/hw/intc/armv7m_nvic.h
+++ b/include/hw/intc/armv7m_nvic.h
@@ -57,10 +57,17 @@ typedef struct NVICState {
 VecInfo sec_vectors[NVIC_INTERNAL_VECTORS];
 uint32_t prigroup;
 
-/* vectpending and exception_prio are both cached state that can
- * be recalculated from the vectors[] array and the prigroup field.
+/* The following fields are all cached state that can be recalculated
+ * from the vectors[] and sec_vectors[] arrays and the prigroup field:
+ *  - vectpending
+ *  - vectpending_is_secure
+ *  - exception_prio
  */
 unsigned int vectpending; /* highest prio pending enabled exception */
+/* true if vectpending is a banked secure exception, ie it is in
+ * sec_vectors[] rather than vectors[]
+ */
+bool vectpending_is_s_banked;
 int exception_prio; /* group prio of the highest prio active exception */
 
 MemoryRegion sysregmem;
diff --git a/hw/intc/armv7m_nvic.c b/hw/intc/armv7m_nvic.c
index 694b9e0..417a456 100644
--- a/hw/intc/armv7m_nvic.c
+++ b/hw/intc/armv7m_nvic.c
@@ -1250,6 +1250,7 @@ static void armv7m_nvic_reset(DeviceState *dev)
 
 s->exception_prio = NVIC_NOEXC_PRIO;
 s->vectpending = 0;
+s->vectpending_is_s_banked = false;
 }
 
 static void nvic_systick_trigger(void *opaque, int n, int level)
-- 
2.7.4

[Qemu-devel] [PATCH 05/19] nvic: Implement AIRCR changes for v8M

[Peter Maydell]

The Application Interrupt and Reset Control Register has some changes
for v8M:
 * new bits SYSRESETREQS, BFHFNMINS and PRIS: these all have
   real state if the security extension is implemented and otherwise
   are constant
 * the PRIGROUP field is banked between security states
 * non-secure code can be blocked from using the SYSRESET bit
   to reset the system if SYSRESETREQS is set

Implement the new state and the changes to register read and write.
For the moment we ignore the effects of the secure PRIGROUP.
We will implement the effects of PRIS and BFHFNMIS later.

Signed-off-by: Peter Maydell 
---
 include/hw/intc/armv7m_nvic.h |  3 ++-
 target/arm/cpu.h  | 12 +++
 hw/intc/armv7m_nvic.c | 49 +--
 target/arm/cpu.c  |  7 +++
 4 files changed, 59 insertions(+), 12 deletions(-)

diff --git a/include/hw/intc/armv7m_nvic.h b/include/hw/intc/armv7m_nvic.h
index 329774e..e96e488 100644
--- a/include/hw/intc/armv7m_nvic.h
+++ b/include/hw/intc/armv7m_nvic.h
@@ -55,7 +55,8 @@ typedef struct NVICState {
  * Entries in sec_vectors[] for non-banked exception numbers are unused.
  */
 VecInfo sec_vectors[NVIC_INTERNAL_VECTORS];
-uint32_t prigroup;
+/* The PRIGROUP field in AIRCR is banked */
+uint32_t prigroup[M_REG_NUM_BANKS];
 
 /* The following fields are all cached state that can be recalculated
  * from the vectors[] and sec_vectors[] arrays and the prigroup field:
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 5a1f957..7e661c8 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -449,6 +449,7 @@ typedef struct CPUARMState {
 int exception;
 uint32_t primask[M_REG_NUM_BANKS];
 uint32_t faultmask[M_REG_NUM_BANKS];
+uint32_t aircr; /* only holds r/w state if security extn implemented */
 uint32_t secure; /* Is CPU in Secure state? (not guest visible) */
 } v7m;
 
@@ -1200,6 +1201,17 @@ FIELD(V7M_CCR, STKALIGN, 9, 1)
 FIELD(V7M_CCR, DC, 16, 1)
 FIELD(V7M_CCR, IC, 17, 1)
 
+/* V7M AIRCR bits */
+FIELD(V7M_AIRCR, VECTRESET, 0, 1)
+FIELD(V7M_AIRCR, VECTCLRACTIVE, 1, 1)
+FIELD(V7M_AIRCR, SYSRESETREQ, 2, 1)
+FIELD(V7M_AIRCR, SYSRESETREQS, 3, 1)
+FIELD(V7M_AIRCR, PRIGROUP, 8, 3)
+FIELD(V7M_AIRCR, BFHFNMINS, 13, 1)
+FIELD(V7M_AIRCR, PRIS, 14, 1)
+FIELD(V7M_AIRCR, ENDIANNESS, 15, 1)
+FIELD(V7M_AIRCR, VECTKEY, 16, 16)
+
 /* V7M CFSR bits for MMFSR */
 FIELD(V7M_CFSR, IACCVIOL, 0, 1)
 FIELD(V7M_CFSR, DACCVIOL, 1, 1)
diff --git a/hw/intc/armv7m_nvic.c b/hw/intc/armv7m_nvic.c
index 8388d64..585b1a7 100644
--- a/hw/intc/armv7m_nvic.c
+++ b/hw/intc/armv7m_nvic.c
@@ -129,7 +129,7 @@ static bool nvic_isrpending(NVICState *s)
  */
 static inline uint32_t nvic_gprio_mask(NVICState *s)
 {
-return ~0U << (s->prigroup + 1);
+return ~0U << (s->prigroup[M_REG_NS] + 1);
 }
 
 /* Recompute vectpending and exception_prio */
@@ -451,8 +451,21 @@ static uint32_t nvic_readl(NVICState *s, uint32_t offset, 
MemTxAttrs attrs)
 return val;
 case 0xd08: /* Vector Table Offset.  */
 return cpu->env.v7m.vecbase[attrs.secure];
-case 0xd0c: /* Application Interrupt/Reset Control.  */
-return 0xfa05 | (s->prigroup << 8);
+case 0xd0c: /* Application Interrupt/Reset Control (AIRCR) */
+val = 0xfa05 | (s->prigroup[attrs.secure] << 8);
+if (attrs.secure) {
+/* s->aircr stores PRIS, BFHFNMINS, SYSRESETREQS */
+val |= cpu->env.v7m.aircr;
+} else {
+if (arm_feature(>env, ARM_FEATURE_V8)) {
+/* BFHFNMINS is R/O from NS; other bits are RAZ/WI. If
+ * security isn't supported then BFHFNMINS is RAO (and
+ * the bit in env.v7m.aircr is always set).
+ */
+val |= cpu->env.v7m.aircr & R_V7M_AIRCR_BFHFNMINS_MASK;
+}
+}
+return val;
 case 0xd10: /* System Control.  */
 /* TODO: Implement SLEEPONEXIT.  */
 return 0;
@@ -660,22 +673,35 @@ static void nvic_writel(NVICState *s, uint32_t offset, 
uint32_t value,
 case 0xd08: /* Vector Table Offset.  */
 cpu->env.v7m.vecbase[attrs.secure] = value & 0xff80;
 break;
-case 0xd0c: /* Application Interrupt/Reset Control.  */
-if ((value >> 16) == 0x05fa) {
-if (value & 4) {
-qemu_irq_pulse(s->sysresetreq);
+case 0xd0c: /* Application Interrupt/Reset Control (AIRCR) */
+if ((value >> R_V7M_AIRCR_VECTKEY_SHIFT) == 0x05fa) {
+if (value & R_V7M_AIRCR_SYSRESETREQ_MASK) {
+if (attrs.secure ||
+!(cpu->env.v7m.aircr & R_V7M_AIRCR_SYSRESETREQS_MASK)) {
+qemu_irq_pulse(s->sysresetreq);
+}
 }
-if (value & 2) {
+if (value & R_V7M_AIRCR_VECTCLRACTIVE_MASK) {
 qemu_log_mask(LOG_GUEST_ERROR,
 

[Qemu-devel] [PATCH 09/19] nvic: Make set_pending and clear_pending take a secure parameter

[Peter Maydell]

Make the armv7m_nvic_set_pending() and armv7m_nvic_clear_pending()
functions take a bool indicating whether to pend the secure
or non-secure version of a banked interrupt, and update the
callsites accordingly.

In most callsites we can simply pass the correct security
state in; in a couple of cases we use TODO comments to indicate
that we will return the code in a subsequent commit.

Signed-off-by: Peter Maydell 
---
 target/arm/cpu.h  | 14 ++-
 hw/intc/armv7m_nvic.c | 64 ++-
 target/arm/helper.c   | 24 +++
 hw/intc/trace-events  |  4 ++--
 4 files changed, 77 insertions(+), 29 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 7e661c8..7a93354 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -1463,7 +1463,19 @@ static inline bool 
armv7m_nvic_can_take_pending_exception(void *opaque)
 return true;
 }
 #endif
-void armv7m_nvic_set_pending(void *opaque, int irq);
+/**
+ * armv7m_nvic_set_pending: mark the specified exception as pending
+ * @opaque: the NVIC
+ * @irq: the exception number to mark pending
+ * @secure: false for non-banked exceptions or for the nonsecure
+ * version of a banked exception, true for the secure version of a banked
+ * exception.
+ *
+ * Marks the specified exception as pending. Note that we will assert()
+ * if @secure is true and @irq does not specify one of the fixed set
+ * of architecturally banked exceptions.
+ */
+void armv7m_nvic_set_pending(void *opaque, int irq, bool secure);
 void armv7m_nvic_acknowledge_irq(void *opaque);
 /**
  * armv7m_nvic_complete_irq: complete specified interrupt or exception
diff --git a/hw/intc/armv7m_nvic.c b/hw/intc/armv7m_nvic.c
index fb824e6..852db11 100644
--- a/hw/intc/armv7m_nvic.c
+++ b/hw/intc/armv7m_nvic.c
@@ -384,31 +384,50 @@ static void nvic_irq_update(NVICState *s)
 qemu_set_irq(s->excpout, lvl);
 }
 
-static void armv7m_nvic_clear_pending(void *opaque, int irq)
+/**
+ * armv7m_nvic_clear_pending: mark the specified exception as not pending
+ * @opaque: the NVIC
+ * @irq: the exception number to mark as not pending
+ * @secure: false for non-banked exceptions or for the nonsecure
+ * version of a banked exception, true for the secure version of a banked
+ * exception.
+ *
+ * Marks the specified exception as not pending. Note that we will assert()
+ * if @secure is true and @irq does not specify one of the fixed set
+ * of architecturally banked exceptions.
+ */
+static void armv7m_nvic_clear_pending(void *opaque, int irq, bool secure)
 {
 NVICState *s = (NVICState *)opaque;
 VecInfo *vec;
 
 assert(irq > ARMV7M_EXCP_RESET && irq < s->num_irq);
 
-vec = >vectors[irq];
-trace_nvic_clear_pending(irq, vec->enabled, vec->prio);
+if (secure) {
+assert(exc_is_banked(irq));
+vec = >sec_vectors[irq];
+} else {
+vec = >vectors[irq];
+}
+trace_nvic_clear_pending(irq, secure, vec->enabled, vec->prio);
 if (vec->pending) {
 vec->pending = 0;
 nvic_irq_update(s);
 }
 }
 
-void armv7m_nvic_set_pending(void *opaque, int irq)
+void armv7m_nvic_set_pending(void *opaque, int irq, bool secure)
 {
 NVICState *s = (NVICState *)opaque;
+bool banked = exc_is_banked(irq);
 VecInfo *vec;
 
 assert(irq > ARMV7M_EXCP_RESET && irq < s->num_irq);
+assert(!secure || banked);
 
-vec = >vectors[irq];
-trace_nvic_set_pending(irq, vec->enabled, vec->prio);
+vec = (banked && secure) ? >sec_vectors[irq] : >vectors[irq];
 
+trace_nvic_set_pending(irq, secure, vec->enabled, vec->prio);
 
 if (irq >= ARMV7M_EXCP_HARD && irq < ARMV7M_EXCP_PENDSV) {
 /* If a synchronous exception is pending then it may be
@@ -454,9 +473,20 @@ void armv7m_nvic_set_pending(void *opaque, int irq)
   "(current priority %d)\n", irq, running);
 }
 
-/* We can do the escalation, so we take HardFault instead */
+/* We can do the escalation, so we take HardFault instead.
+ * If BFHFNMINS is set then we escalate to the banked HF for
+ * the target security state of the original exception; otherwise
+ * we take a Secure HardFault.
+ */
 irq = ARMV7M_EXCP_HARD;
-vec = >vectors[irq];
+if (arm_feature(>cpu->env, ARM_FEATURE_M_SECURITY) &&
+(secure ||
+ !(s->cpu->env.v7m.aircr & R_V7M_AIRCR_BFHFNMINS_MASK))) {
+vec = >sec_vectors[irq];
+} else {
+vec = >vectors[irq];
+}
+/* HF may be banked but there is only one shared HFSR */
 s->cpu->env.v7m.hfsr |= R_V7M_HFSR_FORCED_MASK;
 }
 }
@@ -551,7 +581,7 @@ static void set_irq_level(void *opaque, int n, int level)
 if (level != vec->level) {
 vec->level = level;
 if (level) {
-armv7m_nvic_set_pending(s,