[PATCH] MAINTAINERS: Change to my personal email address

2019-10-29 Thread Palmer Dabbelt
I'm leaving SiFive in a bit less than two weeks, which means I'll be
losing my @sifive email address.  I don't have my new email address yet,
so I'm switching over to my personal address instead.

Signed-off-by: Palmer Dabbelt 
Signed-off-by: Palmer Dabbelt 
---
 MAINTAINERS | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 325e67a04eee..20445f353e7a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -259,7 +259,7 @@ F: include/hw/ppc/
 F: disas/ppc.c
 
 RISC-V TCG CPUs
-M: Palmer Dabbelt 
+M: Palmer Dabbelt 
 M: Alistair Francis 
 M: Sagar Karandikar 
 M: Bastian Koppelmann 
@@ -2392,7 +2392,7 @@ F: tcg/ppc/
 F: disas/ppc.c
 
 RISC-V TCG target
-M: Palmer Dabbelt 
+M: Palmer Dabbelt 
 M: Alistair Francis 
 L: qemu-ri...@nongnu.org
 S: Maintained
-- 
2.21.0




RE: [PATCH v2] qcow2-bitmap: Fix uint64_t left-shift overflow

2019-10-29 Thread Tuguoyi
On 29.10.2019 19:57 Vladimir Sementsov-Ogievskiy wrote:
> 29.10.2019 14:14, Max Reitz wrote:
> > On 28.10.19 07:33, Tuguoyi wrote:
> >> In check_constraints_on_bitmap(), the sanity check on the granularity
> >> will cause uint64_t integer left-shift overflow when cluster_size is
> >> 2M and the granularity is BIGGER than 32K. As a result, for a qcow2
> >> disk with cluster_size set to 2M, we could not even create a dirty
> >> bitmap with default granularity. This patch fix the issue by dividing
> >> @len by granularity instead.
> >>
> >> Signed-off-by: Guoyi Tu 
> >> ---
> >>   block/qcow2-bitmap.c | 4 ++--
> >>   1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/block/qcow2-bitmap.c b/block/qcow2-bitmap.c index
> >> 98294a7..71ac822 100644
> >> --- a/block/qcow2-bitmap.c
> >> +++ b/block/qcow2-bitmap.c
> >> @@ -172,8 +172,8 @@ static int
> check_constraints_on_bitmap(BlockDriverState *bs,
> >>   }
> >>
> >>   if ((len > (uint64_t)BME_MAX_PHYS_SIZE << granularity_bits) ||

Here is the same problem, we need also to calculate the number of bits instead 
of bytes.

> >> -(len > (uint64_t)BME_MAX_TABLE_SIZE * s->cluster_size <<
> >> -   granularity_bits))
> >> +(DIV_ROUND_UP(len, granularity) >
> (uint64_t)BME_MAX_TABLE_SIZE *
> >> +s->cluster_size))
> >
> > This didn’t change because of this patch, but doesn’t this comparison
> > need a conversion of bits to bytes somewhere?
> >
> > len / granularity gives us the number of bits needed for the bitmap.
> >
> > BME_MAX_TABLE_SIZE is, as far as I can see, a number of bitmap
> > clusters, so multiplying it by the cluster size gives the number of
> > bytes in the bitmap.  But the number of bits is eight times higher.
> 
> I think you are right. It would be better to fix it in the same patch..
> 

I think it would be better to add a inline function to calculate the max bytes 
of bitmap with given virtual size and granularity.

I'll send another patch later

> >
> > Another topic: Isn’t BME_MAX_TABLE_SIZE too big?
> 
> Maybe) Still, I don't sure that we need to change it..
> 
> >  As it is, bitmap
> > tables can have a size of 1 GB, and that’s the table alone.  Depending
> > on the cluster size, the bitmap would take up at least 64 GB and cover
> > at least 32 TB (at a granularity of 512 bytes).
> >
> > Max
> >
> >>   {
> >>   error_setg(errp, "Too much space will be occupied by the
> bitmap. "
> >>  "Use larger granularity");
> >>
> >
> >
> 
> 
> --
> Best regards,
> Vladimir


[Bug 1850570] [NEW] Cannot use usb-host on Mac OS

2019-10-29 Thread John Canada
Public bug reported:

Usb-host will not work on Mac OS 10.15.  Qemu runs, though it gives
these errors and the drive does not show up.  Also, when Qemu is
starting the drive ejects and remounts twice. Qemu built with
./configure --target-list=i386-softmmu,x86_64-softmmu --enable-sdl
--disable-cocoa --enable-sdl-image.

qemu-system-i386 image.qcow -usb -device usb-kbd  -device 
usb-host,vendorid=0x0781,productid=0x5571
libusb: error [darwin_claim_interface] USBInterfaceOpen: another process has 
device opened for exclusive access
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] USBInterfaceOpen: another process has 
device opened for exclusive access
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] interface not found
libusb: error [darwin_claim_interface] interface not found

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  Cannot use usb-host on Mac OS

Status in QEMU:
  New

Bug description:
  Usb-host will not work on Mac OS 10.15.  Qemu runs, though it gives
  these errors and the drive does not show up.  Also, when Qemu is
  starting the drive ejects and remounts twice. Qemu built with
  ./configure --target-list=i386-softmmu,x86_64-softmmu --enable-sdl
  --disable-cocoa --enable-sdl-image.

  qemu-system-i386 image.qcow -usb -device usb-kbd  -device 
usb-host,vendorid=0x0781,productid=0x5571
  libusb: error [darwin_claim_interface] USBInterfaceOpen: another process has 
device opened for exclusive access
  libusb: error [darwin_claim_interface] interface not found
  libusb: error [darwin_claim_interface] interface not found
  libusb: error [darwin_claim_interface] interface not found
  libusb: error [darwin_claim_interface] interface not found
  libusb: error [darwin_claim_interface] interface not found
  libusb: error [darwin_claim_interface] interface not found
  libusb: error [darwin_claim_interface] interface not found
  libusb: error [darwin_claim_interface] interface not found
  libusb: error [darwin_claim_interface] interface not found
  libusb: error [darwin_claim_interface] interface not found
  libusb: error [darwin_claim_interface] interface not found
  libusb: error [darwin_claim_interface] interface not found
  libusb: error [darwin_claim_interface] interface not found
  libusb: error [darwin_claim_interface] interface not found
  libusb: error [darwin_claim_interface] interface not found
  libusb: error [darwin_claim_interface] USBInterfaceOpen: another process has 
device opened for exclusive access
  libusb: error [darwin_claim_interface] interface not found
  libusb: error [darwin_claim_interface] interface not found
  libusb: error [darwin_claim_interface] interface not found
  libusb: error [darwin_claim_interface] interface not found
  libusb: error [darwin_claim_interface] interface not found
  libusb: error [darwin_claim_interface] interface not found
  libusb: error [darwin_claim_interface] interface not found
  libusb: error [darwin_claim_interface] interface not found
  libusb: error [darwin_claim_interface] interface not found
  libusb: error [darwin_claim_interface] interface not found
  libusb: error [darwin_claim_interface] interface not found
  libusb: error [darwin_claim_interface] interface 

[PATCH] remove unnecessary ifdef TARGET_RISCV64

2019-10-29 Thread hiroyuki . obinata
From: "hiroyuki.obinata" 

Signed-off-by: Hiroyuki Obinata 
---
 target/riscv/translate.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/target/riscv/translate.c b/target/riscv/translate.c
index adeddb85f6..5c4dd21a98 100644
--- a/target/riscv/translate.c
+++ b/target/riscv/translate.c
@@ -64,12 +64,10 @@ static const int tcg_memop_lookup[8] = {
 [0] = MO_SB,
 [1] = MO_TESW,
 [2] = MO_TESL,
+[3] = MO_TEQ,
 [4] = MO_UB,
 [5] = MO_TEUW,
-#ifdef TARGET_RISCV64
-[3] = MO_TEQ,
 [6] = MO_TEUL,
-#endif
 };
 #endif
 
-- 
2.17.1




Re: [PULL 0/16] Python (acceptance tests) queue, 2019-10-28

2019-10-29 Thread Cleber Rosa
On Tue, Oct 29, 2019 at 05:58:13PM -0400, Cleber Rosa wrote:
> On Tue, Oct 29, 2019 at 05:51:28PM -0400, Cleber Rosa wrote:
> > On Tue, Oct 29, 2019 at 09:13:45PM +, Peter Maydell wrote:
> > > On Mon, 28 Oct 2019 at 23:50, Cleber Rosa  wrote:
> > > >
> > > > The following changes since commit 
> > > > aaffb853359829a37daaf883c773e8320b55c723:
> > > >
> > > >   Merge remote-tracking branch 
> > > > 'remotes/maxreitz/tags/pull-block-2019-10-28' into staging (2019-10-28 
> > > > 14:40:01 +)
> > > >
> > > > are available in the Git repository at:
> > > >
> > > >   git://github.com/clebergnu/qemu.git tags/python-next-pull-request
> > > >
> > > > for you to fetch changes up to efdb45bfd72745038909dfd1e970a827cb8d5d7e:
> > > >
> > > >   tests/boot_linux_console: Run BusyBox on 5KEc 64-bit cpu (2019-10-28 
> > > > 19:04:04 -0400)
> > > >
> > > > 
> > > 
> > > Hi; unless my scripts are driving gpg wrong, this seems to
> > > have been signed with an expired gpg key:
> > > 
> > > gpg: Signature made Mon 28 Oct 2019 23:43:11 GMT
> > > gpg:using RSA key 7ABB96EB8B46B94D5E0FE9BB657E8D33A5F209F3
> > > gpg: Good signature from "Cleber Rosa " [expired]
> > > gpg: Note: This key has expired!
> > > Primary key fingerprint: 7ABB 96EB 8B46 B94D 5E0F  E9BB 657E 8D33 A5F2 
> > > 09F3
> > > 
> > > 
> > > thanks
> > > -- PMM
> > 
> > Hi Peter,
> > 
> > Nothing wrong with your scripts.  I updated my key about a week ago,
> > but I'm almost certain that the key servers that I sent it to was
> > acting funky.
> > 
> > After some further pushes, I see it on:
> > 
> >   
> > http://keys.gnupg.net/pks/lookup?op=vindex=on=0x657E8D33A5F209F3
> > 
> > ---
> > 
> > Search results for '0x657e8d33a5f209f3'
> > Type bits/keyID cr. time   exp time   key expir
> > pub  4096R/A5F209F3 2014-10-16
> >  Fingerprint=7ABB 96EB 8B46 B94D 5E0F  E9BB 657E 8D33 A5F2 09F3 
> > 
> > uid Cleber Rosa 
> > sig  sig3  A5F209F3 2014-10-16 __ 2019-10-15 [selfsig]
> > sig  sig   7657B59A 2014-10-16 __ __ Rudá Moura 
> > 
> > sig  sig   2527436A 2019-03-05 __ __ Eric Blake 
> > 
> > sig  sig   984DC5A6 2019-03-06 __ __ Eduardo Habkost 
> > 
> > sig  sig3  96799EF4 2019-03-06 __ __ Bandan Das 
> > 
> > sig  sig3  A5F209F3 2019-10-22 __ 2024-10-20 [selfsig]
> > 
> > sub  4096R/5B75AD33 2014-10-16
> > sig sbind  A5F209F3 2014-10-16 __ 2019-10-15 []
> > sig sbind  A5F209F3 2019-10-22 __ 2024-10-20 []
> > 
> > ---
> > 
> > And with a fresh environment:
> > 
> >   $ podman run --rm -ti fedora:30
> >   [root@afba6c046a22 /]# gpg --search-key 657E8D33A5F209F3
> >   gpg: directory '/root/.gnupg' created
> >   gpg: keybox '/root/.gnupg/pubring.kbx' created
> >   gpg: data source: https://51.38.91.189:443
> >   (1) Cleber Rosa 
> > 4096 bit RSA key 657E8D33A5F209F3, created: 2014-10-16, 
> > expires: 2024-10-20
> >   Keys 1-1 of 1 for "657E8D33A5F209F3".  Enter number(s), N)ext, or Q)uit > 
> > 1
> >   gpg: key 657E8D33A5F209F3: 4 signatures not checked due to missing keys
> >   gpg: /root/.gnupg/trustdb.gpg: trustdb created
> >   gpg: key 657E8D33A5F209F3: public key "Cleber Rosa " 
> > imported
> >   gpg: no ultimately trusted keys found
> >   gpg: Total number processed: 1
> >   gpg:   imported: 1
> > 
> > ---
> > 
> > So I guess "all" you'd need is a refresh.  Sorry for the inconvenience,
> > and let me know if there's anything else I can do.
> > 
> > - Cleber.
> 
> OK, so now I don't see the updated key anymore on the public key servers,
> which confirms that I'm doing something wrong.
> 
> I'm trying to fix that situation.  Sorry for the inconvenience again.
> 
> - Cleber.

I'm now getting the updated key on every single server I've tried.

Any further feedback/request is highly appreciated.

Thanks,
- Cleber.




[PULL 14/14] virtio: Use auto rcu_read macros

2019-10-29 Thread Michael S. Tsirkin
From: "Dr. David Alan Gilbert" 

Use RCU_READ_LOCK_GUARD and WITH_RCU_READ_LOCK_GUARD
to replace the manual rcu_read_(un)lock calls.

I think the only change is virtio_load which was missing unlocks
in error paths; those end up being fatal errors so it's not
that important anyway.

Signed-off-by: Dr. David Alan Gilbert 
Message-Id: <20191028161109.60205-1-dgilb...@redhat.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/virtio/virtio.c | 65 --
 1 file changed, 23 insertions(+), 42 deletions(-)

diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 6348cd30e9..762df12f4c 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -387,7 +387,8 @@ static inline void vring_set_avail_event(VirtQueue *vq, 
uint16_t val)
 
 static void virtio_queue_split_set_notification(VirtQueue *vq, int enable)
 {
-rcu_read_lock();
+RCU_READ_LOCK_GUARD();
+
 if (virtio_vdev_has_feature(vq->vdev, VIRTIO_RING_F_EVENT_IDX)) {
 vring_set_avail_event(vq, vring_avail_idx(vq));
 } else if (enable) {
@@ -399,7 +400,6 @@ static void virtio_queue_split_set_notification(VirtQueue 
*vq, int enable)
 /* Expose avail event/used flags before caller checks the avail idx. */
 smp_mb();
 }
-rcu_read_unlock();
 }
 
 static void virtio_queue_packed_set_notification(VirtQueue *vq, int enable)
@@ -408,7 +408,7 @@ static void virtio_queue_packed_set_notification(VirtQueue 
*vq, int enable)
 VRingPackedDescEvent e;
 VRingMemoryRegionCaches *caches;
 
-rcu_read_lock();
+RCU_READ_LOCK_GUARD();
 caches  = vring_get_region_caches(vq);
 vring_packed_event_read(vq->vdev, >used, );
 
@@ -429,7 +429,6 @@ static void virtio_queue_packed_set_notification(VirtQueue 
*vq, int enable)
 /* Expose avail event/used flags before caller checks the avail idx. */
 smp_mb();
 }
-rcu_read_unlock();
 }
 
 void virtio_queue_set_notification(VirtQueue *vq, int enable)
@@ -577,9 +576,8 @@ static int virtio_queue_split_empty(VirtQueue *vq)
 return 0;
 }
 
-rcu_read_lock();
+RCU_READ_LOCK_GUARD();
 empty = vring_avail_idx(vq) == vq->last_avail_idx;
-rcu_read_unlock();
 return empty;
 }
 
@@ -601,12 +599,8 @@ static int virtio_queue_packed_empty_rcu(VirtQueue *vq)
 
 static int virtio_queue_packed_empty(VirtQueue *vq)
 {
-bool empty;
-
-rcu_read_lock();
-empty = virtio_queue_packed_empty_rcu(vq);
-rcu_read_unlock();
-return empty;
+RCU_READ_LOCK_GUARD();
+return virtio_queue_packed_empty_rcu(vq);
 }
 
 int virtio_queue_empty(VirtQueue *vq)
@@ -859,10 +853,9 @@ void virtqueue_flush(VirtQueue *vq, unsigned int count)
 void virtqueue_push(VirtQueue *vq, const VirtQueueElement *elem,
 unsigned int len)
 {
-rcu_read_lock();
+RCU_READ_LOCK_GUARD();
 virtqueue_fill(vq, elem, len, 0);
 virtqueue_flush(vq, 1);
-rcu_read_unlock();
 }
 
 /* Called within rcu_read_lock().  */
@@ -943,7 +936,8 @@ static void virtqueue_split_get_avail_bytes(VirtQueue *vq,
 int64_t len = 0;
 int rc;
 
-rcu_read_lock();
+RCU_READ_LOCK_GUARD();
+
 idx = vq->last_avail_idx;
 total_bufs = in_total = out_total = 0;
 
@@ -1033,7 +1027,6 @@ done:
 if (out_bytes) {
 *out_bytes = out_total;
 }
-rcu_read_unlock();
 return;
 
 err:
@@ -1083,7 +1076,7 @@ static void virtqueue_packed_get_avail_bytes(VirtQueue 
*vq,
 VRingPackedDesc desc;
 bool wrap_counter;
 
-rcu_read_lock();
+RCU_READ_LOCK_GUARD();
 idx = vq->last_avail_idx;
 wrap_counter = vq->last_avail_wrap_counter;
 total_bufs = in_total = out_total = 0;
@@ -1176,7 +1169,6 @@ done:
 if (out_bytes) {
 *out_bytes = out_total;
 }
-rcu_read_unlock();
 return;
 
 err:
@@ -1360,7 +1352,7 @@ static void *virtqueue_split_pop(VirtQueue *vq, size_t sz)
 VRingDesc desc;
 int rc;
 
-rcu_read_lock();
+RCU_READ_LOCK_GUARD();
 if (virtio_queue_empty_rcu(vq)) {
 goto done;
 }
@@ -1469,7 +1461,6 @@ static void *virtqueue_split_pop(VirtQueue *vq, size_t sz)
 trace_virtqueue_pop(vq, elem, elem->in_num, elem->out_num);
 done:
 address_space_cache_destroy(_desc_cache);
-rcu_read_unlock();
 
 return elem;
 
@@ -1494,7 +1485,7 @@ static void *virtqueue_packed_pop(VirtQueue *vq, size_t 
sz)
 uint16_t id;
 int rc;
 
-rcu_read_lock();
+RCU_READ_LOCK_GUARD();
 if (virtio_queue_packed_empty_rcu(vq)) {
 goto done;
 }
@@ -1600,7 +1591,6 @@ static void *virtqueue_packed_pop(VirtQueue *vq, size_t 
sz)
 trace_virtqueue_pop(vq, elem, elem->in_num, elem->out_num);
 done:
 address_space_cache_destroy(_desc_cache);
-rcu_read_unlock();
 
 return elem;
 
@@ -2437,13 +2427,10 @@ static bool virtio_should_notify(VirtIODevice *vdev, 
VirtQueue *vq)
 
 void virtio_notify_irqfd(VirtIODevice *vdev, VirtQueue *vq)
 {
-bool should_notify;
-

[PATCH 0/2] Acceptance test: update kernel used on m68k/q800 test

2019-10-29 Thread Cleber Rosa
The boot_linux_console.py:BootLinuxConsole.test_m68k_q800 was very
recently merged, but between its last review and now, the Kernel
package used went missing.

This updates the Kernel package, and protects the test from failing
if it gets updated again.

Cleber Rosa (2):
  Acceptance test: cancel test if m68k kernel packages goes missing
  Acceptance test: update kernel for m68k/q800 test

 tests/acceptance/boot_linux_console.py | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

-- 
2.21.0




[PATCH 2/2] Acceptance test: update kernel for m68k/q800 test

2019-10-29 Thread Cleber Rosa
There's an updated version of the Debian package containing the m68k
Kernel.

Now, if the package gets updated again, the test won't fail, but will
be canceled.  A more permanent solution is certainly needed.

Signed-off-by: Cleber Rosa 
---
 tests/acceptance/boot_linux_console.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/acceptance/boot_linux_console.py 
b/tests/acceptance/boot_linux_console.py
index c439fd90fc..8f676d8e92 100644
--- a/tests/acceptance/boot_linux_console.py
+++ b/tests/acceptance/boot_linux_console.py
@@ -385,14 +385,14 @@ class BootLinuxConsole(Test):
 :avocado: tags=machine:q800
 """
 deb_url = ('http://ftp.ports.debian.org/debian-ports/pool-m68k/main'
-   '/l/linux/kernel-image-5.2.0-2-m68k-di_5.2.9-2_m68k.udeb')
-deb_hash = '0797e05129595f22f3c0142db5e199769a723bf9'
+   '/l/linux/kernel-image-5.3.0-1-m68k-di_5.3.7-1_m68k.udeb')
+deb_hash = '044954bb9be4160a3ce81f8bc1b5e856b75cccd1'
 try:
 deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash)
 except OSError as exp:
 self.cancel(exp)
 kernel_path = self.extract_from_deb(deb_path,
-'/boot/vmlinux-5.2.0-2-m68k')
+'/boot/vmlinux-5.3.0-1-m68k')
 
 self.vm.set_machine('q800')
 self.vm.set_console()
-- 
2.21.0




[PATCH 1/2] Acceptance test: cancel test if m68k kernel packages goes missing

2019-10-29 Thread Cleber Rosa
The Linux kernel that is extracted from a Debian package for the q800
machine test is hosted on a "pool" location.  AFAICT, it gets updated
without too much ceremony, and I don't see any archival location that
is stable enough.

For now, to avoid test errors, let's cancel the test if fetching the
package fails.

Signed-off-by: Cleber Rosa 
---
 tests/acceptance/boot_linux_console.py | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tests/acceptance/boot_linux_console.py 
b/tests/acceptance/boot_linux_console.py
index df27813c78..c439fd90fc 100644
--- a/tests/acceptance/boot_linux_console.py
+++ b/tests/acceptance/boot_linux_console.py
@@ -387,7 +387,10 @@ class BootLinuxConsole(Test):
 deb_url = ('http://ftp.ports.debian.org/debian-ports/pool-m68k/main'
'/l/linux/kernel-image-5.2.0-2-m68k-di_5.2.9-2_m68k.udeb')
 deb_hash = '0797e05129595f22f3c0142db5e199769a723bf9'
-deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash)
+try:
+deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash)
+except OSError as exp:
+self.cancel(exp)
 kernel_path = self.extract_from_deb(deb_path,
 '/boot/vmlinux-5.2.0-2-m68k')
 
-- 
2.21.0




[PULL 11/14] vfio: unplug failover primary device before migration

2019-10-29 Thread Michael S. Tsirkin
From: Jens Freimann 

As usual block all vfio-pci devices from being migrated, but make an
exception for failover primary devices. This is achieved by setting
unmigratable to 0 but also add a migration blocker for all vfio-pci
devices except failover primary devices. These will be unplugged before
migration happens by the migration handler of the corresponding
virtio-net standby device.

Signed-off-by: Jens Freimann 
Acked-by: Alex Williamson 
Message-Id: <20191029114905.6856-12-jfreim...@redhat.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/vfio/pci.c | 26 --
 hw/vfio/pci.h |  1 +
 2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 12fac39804..e6569a7968 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -40,6 +40,7 @@
 #include "pci.h"
 #include "trace.h"
 #include "qapi/error.h"
+#include "migration/blocker.h"
 
 #define TYPE_VFIO_PCI "vfio-pci"
 #define PCI_VFIO(obj)OBJECT_CHECK(VFIOPCIDevice, obj, TYPE_VFIO_PCI)
@@ -2732,6 +2733,17 @@ static void vfio_realize(PCIDevice *pdev, Error **errp)
 return;
 }
 
+if (!pdev->failover_pair_id) {
+error_setg(>migration_blocker,
+"VFIO device doesn't support migration");
+ret = migrate_add_blocker(vdev->migration_blocker, );
+if (err) {
+error_propagate(errp, err);
+error_free(vdev->migration_blocker);
+return;
+}
+}
+
 vdev->vbasedev.name = g_path_get_basename(vdev->vbasedev.sysfsdev);
 vdev->vbasedev.ops = _pci_ops;
 vdev->vbasedev.type = VFIO_DEVICE_TYPE_PCI;
@@ -3008,6 +3020,10 @@ out_teardown:
 vfio_bars_exit(vdev);
 error:
 error_prepend(errp, VFIO_MSG_PREFIX, vdev->vbasedev.name);
+if (vdev->migration_blocker) {
+migrate_del_blocker(vdev->migration_blocker);
+error_free(vdev->migration_blocker);
+}
 }
 
 static void vfio_instance_finalize(Object *obj)
@@ -3019,6 +3035,10 @@ static void vfio_instance_finalize(Object *obj)
 vfio_bars_finalize(vdev);
 g_free(vdev->emulated_config_bits);
 g_free(vdev->rom);
+if (vdev->migration_blocker) {
+migrate_del_blocker(vdev->migration_blocker);
+error_free(vdev->migration_blocker);
+}
 /*
  * XXX Leaking igd_opregion is not an oversight, we can't remove the
  * fw_cfg entry therefore leaking this allocation seems like the safest
@@ -3151,11 +3171,6 @@ static Property vfio_pci_dev_properties[] = {
 DEFINE_PROP_END_OF_LIST(),
 };
 
-static const VMStateDescription vfio_pci_vmstate = {
-.name = "vfio-pci",
-.unmigratable = 1,
-};
-
 static void vfio_pci_dev_class_init(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
@@ -3163,7 +3178,6 @@ static void vfio_pci_dev_class_init(ObjectClass *klass, 
void *data)
 
 dc->reset = vfio_pci_reset;
 dc->props = vfio_pci_dev_properties;
-dc->vmsd = _pci_vmstate;
 dc->desc = "VFIO-based PCI device assignment";
 set_bit(DEVICE_CATEGORY_MISC, dc->categories);
 pdc->realize = vfio_realize;
diff --git a/hw/vfio/pci.h b/hw/vfio/pci.h
index 834a90d646..b329d50338 100644
--- a/hw/vfio/pci.h
+++ b/hw/vfio/pci.h
@@ -168,6 +168,7 @@ typedef struct VFIOPCIDevice {
 bool no_vfio_ioeventfd;
 bool enable_ramfb;
 VFIODisplay *dpy;
+Error *migration_blocker;
 } VFIOPCIDevice;
 
 uint32_t vfio_pci_read_config(PCIDevice *pdev, uint32_t addr, int len);
-- 
MST




[PULL 10/14] net/virtio: add failover support

2019-10-29 Thread Michael S. Tsirkin
From: Jens Freimann 

This patch adds support to handle failover device pairs of a virtio-net
device and a (vfio-)pci device, where the virtio-net acts as the standby
device and the (vfio-)pci device as the primary.

The general idea is that we have a pair of devices, a (vfio-)pci and a
emulated (virtio-net) device. Before migration the vfio device is
unplugged and data flows to the emulated device, on the target side
another (vfio-)pci device is plugged in to take over the data-path. In the
guest the net_failover module will pair net devices with the same MAC
address.

To achieve this we need:

1. Provide a callback function for the should_be_hidden DeviceListener.
   It is called when the primary device is plugged in. Evaluate the QOpt
   passed in to check if it is the matching primary device. It returns
   if the device should be hidden or not.
   When it should be hidden it stores the device options in the VirtioNet
   struct and the device is added once the VIRTIO_NET_F_STANDBY feature is
   negotiated during virtio feature negotiation.

   If the virtio-net devices are not realized at the time the (vfio-)pci
   devices are realized, we need to connect the devices later. This way
   we make sure primary and standby devices can be specified in any
   order.

2. Register a callback for migration status notifier. When called it
   will unplug its primary device before the migration happens.

3. Register a callback for the migration code that checks if a device
   needs to be unplugged from the guest.

Signed-off-by: Jens Freimann 
Message-Id: <20191029114905.6856-11-jfreim...@redhat.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 MAINTAINERS|   1 +
 docs/virtio-net-failover.rst   |  68 
 hw/net/virtio-net.c| 302 +
 include/hw/virtio/virtio-net.h |  12 ++
 include/hw/virtio/virtio.h |   1 +
 5 files changed, 384 insertions(+)
 create mode 100644 docs/virtio-net-failover.rst

diff --git a/MAINTAINERS b/MAINTAINERS
index 325e67a04e..c958fc71ea 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1435,6 +1435,7 @@ S: Odd Fixes
 F: hw/net/
 F: include/hw/net/
 F: tests/virtio-net-test.c
+F: docs/virtio-net-failover.rst
 T: git https://github.com/jasowang/qemu.git net
 
 Parallel NOR Flash devices
diff --git a/docs/virtio-net-failover.rst b/docs/virtio-net-failover.rst
new file mode 100644
index 00..22f64c7bc8
--- /dev/null
+++ b/docs/virtio-net-failover.rst
@@ -0,0 +1,68 @@
+
+QEMU virtio-net standby (net_failover)
+
+
+This document explains the setup and usage of virtio-net standby feature which
+is used to create a net_failover pair of devices.
+
+The general idea is that we have a pair of devices, a (vfio-)pci and a
+virtio-net device. Before migration the vfio device is unplugged and data flows
+through the virtio-net device, on the target side another vfio-pci device is
+plugged in to take over the data-path. In the guest the net_failover kernel
+module will pair net devices with the same MAC address.
+
+The two devices are called primary and standby device. The fast hardware based
+networking device is called the primary device and the virtio-net device is the
+standby device.
+
+Restrictions
+
+
+Currently only PCIe devices are allowed as primary devices, this restriction
+can be lifted in the future with enhanced QEMU support. Also, only networking
+devices are allowed as primary device. The user needs to ensure that primary
+and standby devices are not plugged into the same PCIe slot.
+
+Usecase
+---
+
+  Virtio-net standby allows easy migration while using a passed-through fast
+  networking device by falling back to a virtio-net device for the duration of
+  the migration. It is like a simple version of a bond, the difference is that 
it
+  requires no configuration in the guest. When a guest is live-migrated to
+  another host QEMU will unplug the primary device via the PCIe based hotplug
+  handler and traffic will go through the virtio-net device.  On the target
+  system the primary device will be automatically plugged back and the
+  net_failover module registers it again as the primary device.
+
+Usage
+-
+
+  The primary device can be hotplugged or be part of the startup configuration
+
+  -device virtio-net-pci,netdev=hostnet1,id=net1,mac=52:54:00:6f:55:cc, \
+bus=root2,failover=on
+
+  With the parameter failover=on the VIRTIO_NET_F_STANDBY feature will be 
enabled.
+
+  -device vfio-pci,host=5e:00.2,id=hostdev0,bus=root1,failover_pair_id=net1
+
+  failover_pair_id references the id of the virtio-net standby device. This
+  is only for pairing the devices within QEMU. The guest kernel module
+  net_failover will match devices with identical MAC addresses.
+
+Hotplug
+---
+
+  Both primary and standby device can be hotplugged via the QEMU monitor.  Note
+  that if the virtio-net device is plugged first a 

[PULL 09/14] libqos: tolerate wait-unplug migration state

2019-10-29 Thread Michael S. Tsirkin
From: Jens Freimann 

Signed-off-by: Jens Freimann 
Message-Id: <20191029114905.6856-10-jfreim...@redhat.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 tests/libqos/libqos.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tests/libqos/libqos.c b/tests/libqos/libqos.c
index d71557c5cb..f229eb2cb8 100644
--- a/tests/libqos/libqos.c
+++ b/tests/libqos/libqos.c
@@ -125,7 +125,8 @@ void migrate(QOSState *from, QOSState *to, const char *uri)
 break;
 }
 
-if ((strcmp(st, "setup") == 0) || (strcmp(st, "active") == 0)) {
+if ((strcmp(st, "setup") == 0) || (strcmp(st, "active") == 0)
+|| (strcmp(st, "wait-unplug") == 0)) {
 qobject_unref(rsp);
 g_usleep(5000);
 continue;
-- 
MST




[PULL 13/14] virtio_net: use RCU_READ_LOCK_GUARD

2019-10-29 Thread Michael S. Tsirkin
From: "Dr. David Alan Gilbert" 

Use RCU_READ_LOCK_GUARD rather than the manual rcu_read_(un)lock call.

Signed-off-by: Dr. David Alan Gilbert 
Message-Id: <20191025103403.120616-3-dgilb...@redhat.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/net/virtio-net.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 314f365e7c..97a5113f7e 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -1490,12 +1490,9 @@ static ssize_t virtio_net_receive_rcu(NetClientState 
*nc, const uint8_t *buf,
 static ssize_t virtio_net_do_receive(NetClientState *nc, const uint8_t *buf,
   size_t size)
 {
-ssize_t r;
+RCU_READ_LOCK_GUARD();
 
-rcu_read_lock();
-r = virtio_net_receive_rcu(nc, buf, size);
-rcu_read_unlock();
-return r;
+return virtio_net_receive_rcu(nc, buf, size);
 }
 
 static void virtio_net_rsc_extract_unit4(VirtioNetRscChain *chain,
-- 
MST




[PULL 02/14] pci: add option for net failover

2019-10-29 Thread Michael S. Tsirkin
From: Jens Freimann 

This patch adds a failover_pair_id property to PCIDev which is
used to link the primary device in a failover pair (the PCI dev) to
a standby (a virtio-net-pci) device.

It only supports ethernet devices. Also currently it only supports
PCIe devices. The requirement for PCIe is because it doesn't support
other hotplug controllers at the moment. The failover functionality can
be added to other hotplug controllers like ACPI, SHCP,... later on.

Signed-off-by: Jens Freimann 
Message-Id: <20191029114905.6856-3-jfreim...@redhat.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/pci/pci.c | 31 +++
 include/hw/pci/pci.h |  3 +++
 2 files changed, 34 insertions(+)

diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index aa05c2b9b2..824ab4ed7b 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -75,6 +75,8 @@ static Property pci_props[] = {
 QEMU_PCIE_LNKSTA_DLLLA_BITNR, true),
 DEFINE_PROP_BIT("x-pcie-extcap-init", PCIDevice, cap_present,
 QEMU_PCIE_EXTCAP_INIT_BITNR, true),
+DEFINE_PROP_STRING("failover_pair_id", PCIDevice,
+   failover_pair_id),
 DEFINE_PROP_END_OF_LIST()
 };
 
@@ -2077,6 +2079,7 @@ static void pci_qdev_realize(DeviceState *qdev, Error 
**errp)
 ObjectClass *klass = OBJECT_CLASS(pc);
 Error *local_err = NULL;
 bool is_default_rom;
+uint16_t class_id;
 
 /* initialize cap_present for pci_is_express() and pci_config_size(),
  * Note that hybrid PCIs are not set automatically and need to manage
@@ -2101,6 +2104,34 @@ static void pci_qdev_realize(DeviceState *qdev, Error 
**errp)
 }
 }
 
+if (pci_dev->failover_pair_id) {
+if (!pci_bus_is_express(pci_get_bus(pci_dev))) {
+error_setg(errp, "failover primary device must be on "
+ "PCIExpress bus");
+error_propagate(errp, local_err);
+pci_qdev_unrealize(DEVICE(pci_dev), NULL);
+return;
+}
+class_id = pci_get_word(pci_dev->config + PCI_CLASS_DEVICE);
+if (class_id != PCI_CLASS_NETWORK_ETHERNET) {
+error_setg(errp, "failover primary device is not an "
+ "Ethernet device");
+error_propagate(errp, local_err);
+pci_qdev_unrealize(DEVICE(pci_dev), NULL);
+return;
+}
+if (!(pci_dev->cap_present & QEMU_PCI_CAP_MULTIFUNCTION)
+&& (PCI_FUNC(pci_dev->devfn) == 0)) {
+qdev->allow_unplug_during_migration = true;
+} else {
+error_setg(errp, "failover: primary device must be in its own "
+  "PCI slot");
+error_propagate(errp, local_err);
+pci_qdev_unrealize(DEVICE(pci_dev), NULL);
+return;
+}
+}
+
 /* rom loading */
 is_default_rom = false;
 if (pci_dev->romfile == NULL && pc->romfile != NULL) {
diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index f3f0ffd5fb..69d1f0228b 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -352,6 +352,9 @@ struct PCIDevice {
 MSIVectorUseNotifier msix_vector_use_notifier;
 MSIVectorReleaseNotifier msix_vector_release_notifier;
 MSIVectorPollNotifier msix_vector_poll_notifier;
+
+/* ID of standby device in net_failover pair */
+char *failover_pair_id;
 };
 
 void pci_register_bar(PCIDevice *pci_dev, int region_num,
-- 
MST




[PULL 01/14] qdev/qbus: add hidden device support

2019-10-29 Thread Michael S. Tsirkin
From: Jens Freimann 

This adds support for hiding a device to the qbus and qdev APIs.  The
first user of this will be the virtio-net failover feature but the API
introduced with this patch could be used to implement other features as
well, for example hiding pci devices when a pci bus is powered off.

qdev_device_add() is modified to check for a failover_pair_id
argument in the option string. A DeviceListener callback
should_be_hidden() is added. It can be used by a standby device to
inform qdev that this device should not be added now. The standby device
handler can store the device options to plug the device in at a later
point in time.

One reason for hiding the device is that we don't want to expose both
devices to the guest kernel until the respective virtio feature bit
VIRTIO_NET_F_STANDBY was negotiated and we know that the devices will be
handled correctly by the guest.

More information on the kernel feature this is using:
 https://www.kernel.org/doc/html/latest/networking/net_failover.html

An example where the primary device is a vfio-pci device and the standby
device is a virtio-net device:

A device is hidden when it has an "failover_pair_id" option, e.g.

 -device virtio-net-pci,...,failover=on,...
 -device vfio-pci,...,failover_pair_id=net1,...

Signed-off-by: Jens Freimann 
Message-Id: <20191029114905.6856-2-jfreim...@redhat.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/core/qdev.c | 24 
 include/hw/qdev-core.h | 29 +
 qdev-monitor.c | 41 +
 vl.c   |  6 --
 4 files changed, 94 insertions(+), 6 deletions(-)

diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index cbad6c1d55..3b8d43d0fd 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -212,6 +212,30 @@ void device_listener_unregister(DeviceListener *listener)
 QTAILQ_REMOVE(_listeners, listener, link);
 }
 
+bool qdev_should_hide_device(QemuOpts *opts)
+{
+int rc = -1;
+DeviceListener *listener;
+
+QTAILQ_FOREACH(listener, _listeners, link) {
+   if (listener->should_be_hidden) {
+/*
+ * should_be_hidden_will return
+ *  1 if device matches opts and it should be hidden
+ *  0 if device matches opts and should not be hidden
+ *  -1 if device doesn't match ops
+ */
+rc = listener->should_be_hidden(listener, opts);
+}
+
+if (rc > 0) {
+break;
+}
+}
+
+return rc > 0;
+}
+
 void qdev_set_legacy_instance_id(DeviceState *dev, int alias_id,
  int required_for_version)
 {
diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index aa123f88cb..710981af36 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -78,6 +78,19 @@ typedef void (*BusUnrealize)(BusState *bus, Error **errp);
  * respective parent types.
  *   
  * 
+ *
+ * # Hiding a device #
+ * To hide a device, a DeviceListener function should_be_hidden() needs to
+ * be registered.
+ * It can be used to defer adding a device and therefore hide it from the
+ * guest. The handler registering to this DeviceListener can save the QOpts
+ * passed to it for re-using it later and must return that it wants the device
+ * to be/remain hidden or not. When the handler function decides the device
+ * shall not be hidden it will be added in qdev_device_add() and
+ * realized as any other device. Otherwise qdev_device_add() will return early
+ * without adding the device. The guest will not see a "hidden" device
+ * until it was marked don't hide and qdev_device_add called again.
+ *
  */
 typedef struct DeviceClass {
 /*< private >*/
@@ -154,6 +167,12 @@ struct DeviceState {
 struct DeviceListener {
 void (*realize)(DeviceListener *listener, DeviceState *dev);
 void (*unrealize)(DeviceListener *listener, DeviceState *dev);
+/*
+ * This callback is called upon init of the DeviceState and allows to
+ * inform qdev that a device should be hidden, depending on the device
+ * opts, for example, to hide a standby device.
+ */
+int (*should_be_hidden)(DeviceListener *listener, QemuOpts *device_opts);
 QTAILQ_ENTRY(DeviceListener) link;
 };
 
@@ -451,4 +470,14 @@ static inline bool qbus_is_hotpluggable(BusState *bus)
 void device_listener_register(DeviceListener *listener);
 void device_listener_unregister(DeviceListener *listener);
 
+/**
+ * @qdev_should_hide_device:
+ * @opts: QemuOpts as passed on cmdline.
+ *
+ * Check if a device should be added.
+ * When a device is added via qdev_device_add() this will be called,
+ * and return if the device should be added now or not.
+ */
+bool qdev_should_hide_device(QemuOpts *opts);
+
 #endif
diff --git a/qdev-monitor.c b/qdev-monitor.c
index 148df9cacf..ffa08c670f 100644
--- a/qdev-monitor.c
+++ b/qdev-monitor.c
@@ -32,9 +32,11 @@
 #include "qemu/help_option.h"
 #include 

[PULL 12/14] virtio/vhost: Use auto_rcu_read macros

2019-10-29 Thread Michael S. Tsirkin
From: "Dr. David Alan Gilbert" 

Use RCU_READ_LOCK_GUARD instead of manual rcu_read_(un)lock

Signed-off-by: Dr. David Alan Gilbert 
Message-Id: <20191025103403.120616-2-dgilb...@redhat.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/virtio/vhost.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index 99de5f196f..4da0d5a6c5 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -924,7 +924,7 @@ int vhost_device_iotlb_miss(struct vhost_dev *dev, uint64_t 
iova, int write)
 uint64_t uaddr, len;
 int ret = -EFAULT;
 
-rcu_read_lock();
+RCU_READ_LOCK_GUARD();
 
 trace_vhost_iotlb_miss(dev, 1);
 
@@ -956,8 +956,6 @@ int vhost_device_iotlb_miss(struct vhost_dev *dev, uint64_t 
iova, int write)
 trace_vhost_iotlb_miss(dev, 2);
 
 out:
-rcu_read_unlock();
-
 return ret;
 }
 
-- 
MST




[PULL 07/14] migration: allow unplug during migration for failover devices

2019-10-29 Thread Michael S. Tsirkin
From: Jens Freimann 

In "b06424de62 migration: Disable hotplug/unplug during migration" we
added a check to disable unplug for all devices until we have figured
out what works. For failover primary devices qdev_unplug() is called
from the migration handler, i.e. during migration.

This patch adds a flag to DeviceState which is set to false for all
devices and makes an exception for PCI devices that are also
primary devices in a failover pair.

Signed-off-by: Jens Freimann 
Message-Id: <20191029114905.6856-8-jfreim...@redhat.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/core/qdev.c | 1 +
 hw/pci/pci.c   | 1 +
 include/hw/qdev-core.h | 1 +
 qdev-monitor.c | 2 +-
 4 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 3b8d43d0fd..cf1ba28fe3 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -996,6 +996,7 @@ static void device_initfn(Object *obj)
 
 dev->instance_id_alias = -1;
 dev->realized = false;
+dev->allow_unplug_during_migration = false;
 
 object_property_add_bool(obj, "realized",
  device_get_realized, device_set_realized, NULL);
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 824ab4ed7b..c68498c0de 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -2130,6 +2130,7 @@ static void pci_qdev_realize(DeviceState *qdev, Error 
**errp)
 pci_qdev_unrealize(DEVICE(pci_dev), NULL);
 return;
 }
+qdev->allow_unplug_during_migration = true;
 }
 
 /* rom loading */
diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index 710981af36..1518495b1e 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -156,6 +156,7 @@ struct DeviceState {
 bool pending_deleted_event;
 QemuOpts *opts;
 int hotplugged;
+bool allow_unplug_during_migration;
 BusState *parent_bus;
 QLIST_HEAD(, NamedGPIOList) gpios;
 QLIST_HEAD(, BusState) child_bus;
diff --git a/qdev-monitor.c b/qdev-monitor.c
index ffa08c670f..e6b112eb0a 100644
--- a/qdev-monitor.c
+++ b/qdev-monitor.c
@@ -851,7 +851,7 @@ void qdev_unplug(DeviceState *dev, Error **errp)
 return;
 }
 
-if (!migration_is_idle()) {
+if (!migration_is_idle() && !dev->allow_unplug_during_migration) {
 error_setg(errp, "device_del not allowed while migrating");
 return;
 }
-- 
MST




[PULL 06/14] qapi: add failover negotiated event

2019-10-29 Thread Michael S. Tsirkin
From: Jens Freimann 

This event is sent to let libvirt know that VIRTIO_NET_F_STANDBY feature
is enabled. The primary device this virtio-net (standby) device is
associated with, is now hotplugged by the virtio-net device.

Signed-off-by: Jens Freimann 
Message-Id: <20191029114905.6856-7-jfreim...@redhat.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
Acked-by: Markus Armbruster 
---
 qapi/net.json | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/qapi/net.json b/qapi/net.json
index 4c96137811..335295be50 100644
--- a/qapi/net.json
+++ b/qapi/net.json
@@ -735,3 +735,22 @@
 ##
 { 'command': 'announce-self', 'boxed': true,
   'data' : 'AnnounceParameters'}
+
+##
+# @FAILOVER_NEGOTIATED:
+#
+# Emitted when VIRTIO_NET_F_STANDBY was enabled during feature negotiation.
+# Failover primary devices which were hidden (not hotplugged when requested)
+# before will now be hotplugged by the virtio-net standby device.
+#
+# device-id: QEMU device id of the unplugged device
+# Since: 4.2
+#
+# Example:
+#
+# <- { "event": "FAILOVER_NEGOTIATED",
+#  "data": "net1" }
+#
+##
+{ 'event': 'FAILOVER_NEGOTIATED',
+  'data': {'device-id': 'str'} }
-- 
MST




[PULL 08/14] migration: add new migration state wait-unplug

2019-10-29 Thread Michael S. Tsirkin
From: Jens Freimann 

This patch adds a new migration state called wait-unplug.  It is entered
after the SETUP state if failover devices are present. It will transition
into ACTIVE once all devices were succesfully unplugged from the guest.

So if a guest doesn't respond or takes long to honor the unplug request
the user will see the migration state 'wait-unplug'.

In the migration thread we query failover devices if they're are still
pending the guest unplug. When all are unplugged the migration
continues. If one device won't unplug migration will stay in wait_unplug
state.

Signed-off-by: Jens Freimann 
Reviewed-by: Dr. David Alan Gilbert 
Message-Id: <20191029114905.6856-9-jfreim...@redhat.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 include/migration/vmstate.h |  2 ++
 migration/migration.c   | 21 +
 migration/migration.h   |  3 +++
 migration/savevm.c  | 31 +++
 migration/savevm.h  |  2 ++
 qapi/migration.json |  5 -
 6 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/include/migration/vmstate.h b/include/migration/vmstate.h
index b9ee563aa4..ac4f46a67d 100644
--- a/include/migration/vmstate.h
+++ b/include/migration/vmstate.h
@@ -186,6 +186,8 @@ struct VMStateDescription {
 int (*pre_save)(void *opaque);
 int (*post_save)(void *opaque);
 bool (*needed)(void *opaque);
+bool (*dev_unplug_pending)(void *opaque);
+
 const VMStateField *fields;
 const VMStateDescription **subsections;
 };
diff --git a/migration/migration.c b/migration/migration.c
index 4133ed2684..354ad072fa 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -52,6 +52,7 @@
 #include "hw/qdev-properties.h"
 #include "monitor/monitor.h"
 #include "net/announce.h"
+#include "qemu/queue.h"
 
 #define MAX_THROTTLE  (32 << 20)  /* Migration transfer speed throttling */
 
@@ -819,6 +820,7 @@ bool migration_is_setup_or_active(int state)
 case MIGRATION_STATUS_SETUP:
 case MIGRATION_STATUS_PRE_SWITCHOVER:
 case MIGRATION_STATUS_DEVICE:
+case MIGRATION_STATUS_WAIT_UNPLUG:
 return true;
 
 default:
@@ -954,6 +956,9 @@ static void fill_source_migration_info(MigrationInfo *info)
 case MIGRATION_STATUS_CANCELLED:
 info->has_status = true;
 break;
+case MIGRATION_STATUS_WAIT_UNPLUG:
+info->has_status = true;
+break;
 }
 info->status = s->state;
 }
@@ -1694,6 +1699,7 @@ bool migration_is_idle(void)
 case MIGRATION_STATUS_COLO:
 case MIGRATION_STATUS_PRE_SWITCHOVER:
 case MIGRATION_STATUS_DEVICE:
+case MIGRATION_STATUS_WAIT_UNPLUG:
 return false;
 case MIGRATION_STATUS__MAX:
 g_assert_not_reached();
@@ -3264,6 +3270,19 @@ static void *migration_thread(void *opaque)
 
 qemu_savevm_state_setup(s->to_dst_file);
 
+if (qemu_savevm_nr_failover_devices()) {
+migrate_set_state(>state, MIGRATION_STATUS_SETUP,
+  MIGRATION_STATUS_WAIT_UNPLUG);
+
+while (s->state == MIGRATION_STATUS_WAIT_UNPLUG &&
+   qemu_savevm_state_guest_unplug_pending()) {
+qemu_sem_timedwait(>wait_unplug_sem, 250);
+}
+
+migrate_set_state(>state, MIGRATION_STATUS_WAIT_UNPLUG,
+MIGRATION_STATUS_ACTIVE);
+}
+
 s->setup_time = qemu_clock_get_ms(QEMU_CLOCK_HOST) - setup_start;
 migrate_set_state(>state, MIGRATION_STATUS_SETUP,
   MIGRATION_STATUS_ACTIVE);
@@ -3511,6 +3530,7 @@ static void migration_instance_finalize(Object *obj)
 qemu_mutex_destroy(>qemu_file_lock);
 g_free(params->tls_hostname);
 g_free(params->tls_creds);
+qemu_sem_destroy(>wait_unplug_sem);
 qemu_sem_destroy(>rate_limit_sem);
 qemu_sem_destroy(>pause_sem);
 qemu_sem_destroy(>postcopy_pause_sem);
@@ -3556,6 +3576,7 @@ static void migration_instance_init(Object *obj)
 qemu_sem_init(>postcopy_pause_rp_sem, 0);
 qemu_sem_init(>rp_state.rp_sem, 0);
 qemu_sem_init(>rate_limit_sem, 0);
+qemu_sem_init(>wait_unplug_sem, 0);
 qemu_mutex_init(>qemu_file_lock);
 }
 
diff --git a/migration/migration.h b/migration/migration.h
index 4f2fe193dc..79b3dda146 100644
--- a/migration/migration.h
+++ b/migration/migration.h
@@ -206,6 +206,9 @@ struct MigrationState
 /* Flag set once the migration thread called bdrv_inactivate_all */
 bool block_inactive;
 
+/* Migration is waiting for guest to unplug device */
+QemuSemaphore wait_unplug_sem;
+
 /* Migration is paused due to pause-before-switchover */
 QemuSemaphore pause_sem;
 
diff --git a/migration/savevm.c b/migration/savevm.c
index 8d95e261f6..966a9c3bdb 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -1113,6 +1113,37 @@ void qemu_savevm_state_header(QEMUFile *f)
 }
 }
 
+int qemu_savevm_nr_failover_devices(void)
+{
+SaveStateEntry *se;
+int n = 0;
+
+QTAILQ_FOREACH(se, 

[PULL 03/14] pci: mark devices partially unplugged

2019-10-29 Thread Michael S. Tsirkin
From: Jens Freimann 

Only the guest unplug request was triggered. This is needed for
the failover feature. In case of a failed migration we need to
plug the device back to the guest.

Signed-off-by: Jens Freimann 
Message-Id: <20191029114905.6856-4-jfreim...@redhat.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/pci/pcie.c| 3 +++
 include/hw/pci/pci.h | 1 +
 2 files changed, 4 insertions(+)

diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
index a6beb567bd..19363ff8ce 100644
--- a/hw/pci/pcie.c
+++ b/hw/pci/pcie.c
@@ -456,6 +456,9 @@ static void pcie_unplug_device(PCIBus *bus, PCIDevice *dev, 
void *opaque)
 {
 HotplugHandler *hotplug_ctrl = qdev_get_hotplug_handler(DEVICE(dev));
 
+if (dev->partially_hotplugged) {
+return;
+}
 hotplug_handler_unplug(hotplug_ctrl, DEVICE(dev), _abort);
 object_unparent(OBJECT(dev));
 }
diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index 69d1f0228b..db75c6dfd0 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -265,6 +265,7 @@ typedef struct PCIReqIDCache PCIReqIDCache;
 
 struct PCIDevice {
 DeviceState qdev;
+bool partially_hotplugged;
 
 /* PCI config space */
 uint8_t *config;
-- 
MST




[PULL 00/14] virtio: features, cleanups

2019-10-29 Thread Michael S. Tsirkin
The following changes since commit 16884391c750d0c5e863f55ad7146fc5181e:

  Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2019-10-29' into 
staging (2019-10-29 20:06:08 +)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream

for you to fetch changes up to b5f53d04a5a567ac70d33ec95628d35583eba600:

  virtio: Use auto rcu_read macros (2019-10-29 18:56:45 -0400)


virtio: features, cleanups

virtio net failover
rcu cleanup

Signed-off-by: Michael S. Tsirkin 


Dr. David Alan Gilbert (3):
  virtio/vhost: Use auto_rcu_read macros
  virtio_net: use RCU_READ_LOCK_GUARD
  virtio: Use auto rcu_read macros

Jens Freimann (11):
  qdev/qbus: add hidden device support
  pci: add option for net failover
  pci: mark devices partially unplugged
  pci: mark device having guest unplug request pending
  qapi: add unplug primary event
  qapi: add failover negotiated event
  migration: allow unplug during migration for failover devices
  migration: add new migration state wait-unplug
  libqos: tolerate wait-unplug migration state
  net/virtio: add failover support
  vfio: unplug failover primary device before migration

 qapi/migration.json|  24 +++-
 qapi/net.json  |  19 +++
 hw/vfio/pci.h  |   1 +
 include/hw/pci/pci.h   |   4 +
 include/hw/qdev-core.h |  30 
 include/hw/virtio/virtio-net.h |  12 ++
 include/hw/virtio/virtio.h |   1 +
 include/migration/vmstate.h|   2 +
 migration/migration.h  |   3 +
 migration/savevm.h |   2 +
 hw/core/qdev.c |  25 
 hw/net/virtio-net.c| 309 -
 hw/pci/pci.c   |  32 +
 hw/pci/pcie.c  |   6 +
 hw/vfio/pci.c  |  26 +++-
 hw/virtio/vhost.c  |   4 +-
 hw/virtio/virtio.c |  65 +++--
 migration/migration.c  |  21 +++
 migration/savevm.c |  31 +
 qdev-monitor.c |  43 +-
 tests/libqos/libqos.c  |   3 +-
 vl.c   |   6 +-
 MAINTAINERS|   1 +
 docs/virtio-net-failover.rst   |  68 +
 24 files changed, 673 insertions(+), 65 deletions(-)
 create mode 100644 docs/virtio-net-failover.rst




[PULL 05/14] qapi: add unplug primary event

2019-10-29 Thread Michael S. Tsirkin
From: Jens Freimann 

This event is emitted when we sent a request to unplug a
failover primary device from the Guest OS and it includes the
device id of the primary device.

Signed-off-by: Jens Freimann 
Message-Id: <20191029114905.6856-6-jfreim...@redhat.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
Acked-by: Markus Armbruster 
---
 qapi/migration.json | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/qapi/migration.json b/qapi/migration.json
index 82feb5bd39..e9e7a97c03 100644
--- a/qapi/migration.json
+++ b/qapi/migration.json
@@ -1448,3 +1448,22 @@
 # Since: 3.0
 ##
 { 'command': 'migrate-pause', 'allow-oob': true }
+
+##
+# @UNPLUG_PRIMARY:
+#
+# Emitted from source side of a migration when migration state is
+# WAIT_UNPLUG. Device was unplugged by guest operating system.
+# Device resources in QEMU are kept on standby to be able to re-plug it in case
+# of migration failure.
+#
+# @device-id: QEMU device id of the unplugged device
+#
+# Since: 4.2
+#
+# Example:
+#   {"event": "UNPLUG_PRIMARY", "data": {"device-id": "hostdev0"} }
+#
+##
+{ 'event': 'UNPLUG_PRIMARY',
+  'data': { 'device-id': 'str' } }
-- 
MST




[PULL 04/14] pci: mark device having guest unplug request pending

2019-10-29 Thread Michael S. Tsirkin
From: Jens Freimann 

Set pending_deleted_event in DeviceState for failover
primary devices that were successfully unplugged by the Guest OS.

Signed-off-by: Jens Freimann 
Message-Id: <20191029114905.6856-5-jfreim...@redhat.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/pci/pcie.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
index 19363ff8ce..08718188bb 100644
--- a/hw/pci/pcie.c
+++ b/hw/pci/pcie.c
@@ -457,6 +457,7 @@ static void pcie_unplug_device(PCIBus *bus, PCIDevice *dev, 
void *opaque)
 HotplugHandler *hotplug_ctrl = qdev_get_hotplug_handler(DEVICE(dev));
 
 if (dev->partially_hotplugged) {
+dev->qdev.pending_deleted_event = false;
 return;
 }
 hotplug_handler_unplug(hotplug_ctrl, DEVICE(dev), _abort);
@@ -476,6 +477,8 @@ void pcie_cap_slot_unplug_request_cb(HotplugHandler 
*hotplug_dev,
 return;
 }
 
+dev->pending_deleted_event = true;
+
 /* In case user cancel the operation of multi-function hot-add,
  * remove the function that is unexposed to guest individually,
  * without interaction with guest.
-- 
MST




Re: RFC: New device for zero-copy VM memory access

2019-10-29 Thread geoff
Just to follow this up, here is a sample client application for this 
device


https://gist.github.com/gnif/77e7fb54604b42a1a98ecb8bf3d2cf46

-Geoff

On 2019-10-30 01:31, ge...@hostfission.com wrote:

Hi All,

Over the past week, I have been working to come up with a solution to 
the
memory transfer performance issues that hinder the Looking Glass 
Project.


Currently Looking Glass works by using the IVSHMEM shared memory device 
which
is fed by an application that captures the guest's video output. While 
this
works it is sub-optimal because we first have to perform a CPU copy of 
the
captured frame into shared RAM, and then back out again for display. 
Because
the destination buffers are allocated by closed proprietary code 
(DirectX, or
NVidia NvFBC) there is no way to have the frame placed directly into 
the

IVSHMEM shared ram.

This new device, currently named `introspection` (which needs a more 
suitable
name, porthole perhaps?), provides a means of translating guest 
physical
addresses to host virtual addresses, and finally to the host offsets in 
RAM for
file-backed memory guests. It does this by means of a simple protocol 
over a
unix socket (chardev) which is supplied the appropriate fd for the VM's 
system
RAM. The guest (in this case, Windows), when presented with the address 
of a
userspace buffer and size, will mlock the appropriate pages into RAM 
and pass

guest physical addresses to the virtual device.

This device and the windows driver have been designed in such a way 
that it's a
utility device for any project and/or application that could make use 
of it.
The PCI subsystem vendor and device ID are used to provide a means of 
device
identification in cases where multiple devices may be in use for 
differing
applications. This also allows one common driver to be used for any 
other

projects wishing to build on this device.

My ultimate goal is to get this to a state where it could be accepted 
upstream
into Qemu at which point Looking Glass would be modified to use it 
instead of

the IVSHMEM device.

My git repository with the new device can be found at:
https://github.com/gnif/qemu

The new device is:
https://github.com/gnif/qemu/blob/master/hw/misc/introspection.c

Looking Glass:
https://looking-glass.hostfission.com/

The windows driver, while working, needs some cleanup before the source 
is

published. I intend to maintain both this device and the windows driver
including producing a signed Windows 10 driver if Redhat are unwilling 
or

unable.

Kind Regards,
Geoffrey McRae

HostFission
https://hostfission.com




Re: [PATCH 00/30] virtiofs daemon (base)

2019-10-29 Thread Michael S. Tsirkin
On Mon, Oct 21, 2019 at 11:58:02AM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert" 
> 
> Hi,
>   This is the 1st set for the virtiofsd - a daemon
> that implements the user space side of virtiofs.
> 
>   The kernel and qemu device parts recently went in,
> so the daemon is the only thing missing to have a working
> set.


So I went back and forth on this but this is huge
and there's not a lot of time for review.
So I parked it + the security patches on a next branch in my tree.
I will rebase once after rc1 is out, and then stop.


>   This set is the absolute minimal base set of patches;
> it's not yet safe to use (from security or correctness);
> 
> I'll follow up with ~3 more series in the next few days
> with:
> 
> a) Security patches that add sandboxing and checking
>compared with normal fuse - that makes it safe.
> b) Performance improvements including threading
> c) Other fixes, including correctness.
> 
> but, this is a good start and gets things rolling.
> 
> The set pulls in a big chunk of the upstream libfuse library
> (unmodified so that it's easy to check it really is upstream),
> chops all the stuff out we don't need and then adds the
> new transport we need.
> 
> For new files I've formatted the code according to qemu
> standards; for files that are from upstream libfuse
> I've kept with their standards for ease of future updating.
> 
> We can't just link with libfuse, since we have to make ABI incompatible
> changes for the new transport.
> 
> Running this daemon is typically done with:
> 
>./virtiofsd -o vhost_user_socket=/path/socket -o source=/path/to/fs
> 
> connected to a qemu that's then started with:
>-chardev socket,id=char0,path=/path/socket -device 
> vhost-user-fs-pci,queue-size=1024,chardev=char0,tag=myfs
> 
> and then in the guest mount with:
>mount -t virtiofs myfs /mnt
> 
> Our development branch is: 
> https://gitlab.com/virtio-fs/qemu/tree/virtio-fs-dev
> 
> Dave
> 
> 
> Dr. David Alan Gilbert (22):
>   virtiofsd: Pull in upstream headers
>   virtiofsd: Pull in kernel's fuse.h
>   virtiofsd: Add auxiliary .c's
>   virtiofsd: Add fuse_lowlevel.c
>   virtiofsd: Add passthrough_ll
>   virtiofsd: Trim down imported files
>   virtiofsd: Fix fuse_daemonize ignored return values
>   virtiofsd: Fix common header and define for QEMU builds
>   virtiofsd: fuse: Make iov_length usable outside fuse_lowlevel.c
>   virtiofsd: Add options for virtio
>   virtiofsd: Open vhost connection instead of mounting
>   virtiofsd: Start wiring up vhost-user
>   virtiofsd: Add main virtio loop
>   virtiofsd: get/set features callbacks
>   virtiofsd: Start queue threads
>   virtiofsd: Poll kick_fd for queue
>   virtiofsd: Start reading commands from queue
>   virtiofsd: Send replies to messages
>   virtiofsd: Keep track of replies
>   virtiofsd: Add Makefile wiring for virtiofsd contrib
>   virtiofsd: Fast path for virtio read
>   virtiofs: Add maintainers entry
> 
> Stefan Hajnoczi (7):
>   virtiofsd: remove mountpoint dummy argument
>   virtiofsd: remove unused notify reply support
>   virtiofsd: add -o source=PATH to help output
>   virtiofsd: add --fd=FDNUM fd passing option
>   virtiofsd: make -f (foreground) the default
>   virtiofsd: add vhost-user.json file
>   virtiofsd: add --print-capabilities option
> 
> Vivek Goyal (1):
>   virtiofsd: Make fsync work even if only inode is passed in
> 
>  .gitignore  |1 +
>  MAINTAINERS |8 +
>  Makefile|9 +
>  Makefile.objs   |1 +
>  contrib/virtiofsd/50-qemu-virtiofsd.json.in |5 +
>  contrib/virtiofsd/Makefile.objs |   10 +
>  contrib/virtiofsd/buffer.c  |  318 +++
>  contrib/virtiofsd/fuse.h| 1268 ++
>  contrib/virtiofsd/fuse_common.h |  823 +++
>  contrib/virtiofsd/fuse_i.h  |  131 ++
>  contrib/virtiofsd/fuse_kernel.h |  858 +++
>  contrib/virtiofsd/fuse_log.c|   40 +
>  contrib/virtiofsd/fuse_log.h|   82 +
>  contrib/virtiofsd/fuse_loop_mt.c|   54 +
>  contrib/virtiofsd/fuse_lowlevel.c   | 2302 +++
>  contrib/virtiofsd/fuse_lowlevel.h   | 2024 
>  contrib/virtiofsd/fuse_misc.h   |   59 +
>  contrib/virtiofsd/fuse_opt.c|  422 
>  contrib/virtiofsd/fuse_opt.h|  271 +++
>  contrib/virtiofsd/fuse_signals.c|   90 +
>  contrib/virtiofsd/fuse_virtio.c |  717 ++
>  contrib/virtiofsd/fuse_virtio.h |   33 +
>  contrib/virtiofsd/helper.c  |  300 +++
>  contrib/virtiofsd/passthrough_helpers.h |   76 +
>  contrib/virtiofsd/passthrough_ll.c  | 1341 +++
>  docs/interop/vhost-user.json|4 +-
>  26 files changed, 11246 

Re: [PATCH v6 0/11] add failover feature for assigned network devices

2019-10-29 Thread Michael S. Tsirkin
On Fri, Oct 25, 2019 at 02:19:19PM +0200, Jens Freimann wrote:
> This is implementing the host side of the net_failover concept
> (https://www.kernel.org/doc/html/latest/networking/net_failover.html)

OK so I put this on a next branch for now, to merge after the release.
I plan to rebase it after rc1, and then stop rebasing.


> Changes since v5:
> * rename net_failover_pair_id parameter/property to failover_pair_id
> * in PCI code use pci_bus_is_express(). This won't fail on functions > 0
> * make sure primary and standby can't be added to same PCI slot
> * add documentation file in docs/ to virtio-net patch, add file to
>MAINTAINERS (added to networking devices section)
> * add comment to QAPI event for failover negotiation, try to improve
>commit message 
> 
> The general idea is that we have a pair of devices, a vfio-pci and a
> virtio-net device. Before migration the vfio device is unplugged and data
> flows to the virtio-net device, on the target side another vfio-pci device
> is plugged in to take over the data-path. In the guest the net_failover
> module will pair net devices with the same MAC address.
> 
> * Patch 1 adds the infrastructure to hide the device for the qbus and qdev 
> APIs
> 
> * Patch 2 adds checks to PCIDevice for only allowing ethernet devices as
>   failover primary and only PCIExpress capable devices
> 
> * Patch 3 sets a new flag for PCIDevice 'partially_hotplugged' which we
>   use to skip the unrealize code path when doing a unplug of the primary
>   device
> 
> * Patch 4 sets the pending_deleted_event before triggering the guest
>   unplug request
> 
> * Patch 5 and 6 add new qmp events, one sends the device id of a device
>   that was just requested to be unplugged from the guest and another one
>   to let libvirt know if VIRTIO_NET_F_STANDBY was negotiated
> 
> * Patch 7 make sure that we can unplug the vfio-device before
>   migration starts
> 
> * Patch 8 adds a new migration state that is entered while we wait for
>   devices to be unplugged by guest OS
> 
> * Patch 9 just adds the new migration state to a check in libqos code
> 
> * Patch 10 In the second patch the virtio-net uses the API to defer adding 
> the vfio
>   device until the VIRTIO_NET_F_STANDBY feature is acked. It also
>   implements the migration handler to unplug the device from the guest and
>   re-plug in case of migration failure
> 
> * Patch 11 allows migration for failover vfio-pci devices
> 
> Previous discussion:
>   RFC v1 https://patchwork.ozlabs.org/cover/989098/
>   RFC v2 https://www.mail-archive.com/qemu-devel@nongnu.org/msg606906.html
>   v1: https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg03968.html
>   v2: https://www.mail-archive.com/qemu-devel@nongnu.org/msg635214.html
>   v3: https://patchew.org/QEMU/2019102015.11785-1-jfreim...@redhat.com/
>   v4: https://patchew.org/QEMU/20191018202040.30349-1-jfreim...@redhat.com/
>   v5: https://patchew.org/QEMU/20191023082711.16694-1-jfreim...@redhat.com/
> 
> To summarize concerns/feedback from previous discussion:
> 1.- guest OS can reject or worse _delay_ unplug by any amount of time.
>   Migration might get stuck for unpredictable time with unclear reason.
>   This approach combines two tricky things, hot/unplug and migration.
>   -> We need to let libvirt know what's happening. Add new qmp events
>  and a new migration state. When a primary device is (partially)
>  unplugged (only from guest) we send a qmp event with the device id. When
>  it is unplugged from the guest the DEVICE_DELETED event is sent.
>  Migration will enter the wait-unplug state while waiting for the guest
>  os to unplug all primary devices and then move on with migration.
> 2. PCI devices are a precious ressource. The primary device should never
>   be added to QEMU if it won't be used by guest instead of hiding it in
>   QEMU.
>   -> We only hotplug the device when the standby feature bit was
>  negotiated. We save the device cmdline options until we need it for
>  qdev_device_add()
>  Hiding a device can be a useful concept to model. For example a
>  pci device in a powered-off slot could be marked as hidden until the 
> slot is
>  powered on (mst).
> 3. Management layer software should handle this. Open Stack already has
>   components/code to handle unplug/replug VFIO devices and metadata to
>   provide to the guest for detecting which devices should be paired.
>   -> An approach that includes all software from firmware to
>  higher-level management software wasn't tried in the last years. This is
>  an attempt to keep it simple and contained in QEMU as much as possible.
>  One of the problems that stopped management software and libvirt from
>  implementing this idea is that it can't be sure that it's possible to
>  re-plug the primary device. By not freeing the devices resources in QEMU
>  and only asking the guest OS to unplug it is possible to re-plug the
>  device in case 

[PATCH] linux-user: Support for NETLINK socket options

2019-10-29 Thread Josh Kunz
This change includes support for all AF_NETLINK socket options up to about
kernel version 5.4 (5.4 is not formally released at the time of writing).
Socket options that were introduced in kernel versions before the oldest
currently stable kernel version are guarded by kernel version macros.

This change has been built under gcc 8.3, and clang 9.0, and it passes
`make check`. The netlink options have been tested by emulating some
non-trival software that uses NETLINK socket options, but they have
not been exaustively verified.

Signed-off-by: Josh Kunz 
---
 linux-user/syscall.c | 98 
 1 file changed, 98 insertions(+)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 530c843303..cbfb8380a9 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -2247,6 +2247,38 @@ set_timeout:
 return -TARGET_EFAULT;
ret = get_errno(setsockopt(sockfd, SOL_SOCKET, optname, , 
sizeof(val)));
 break;
+#ifdef SOL_NETLINK
+case SOL_NETLINK:
+switch (optname) {
+case NETLINK_PKTINFO:
+case NETLINK_ADD_MEMBERSHIP:
+case NETLINK_DROP_MEMBERSHIP:
+case NETLINK_BROADCAST_ERROR:
+case NETLINK_NO_ENOBUFS:
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 2, 0)
+case NETLINK_LISTEN_ALL_NSID:
+case NETLINK_CAP_ACK:
+#endif /* LINUX_VERSION_CODE >= KERNEL_VERSION(4, 2, 0) */
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 12, 0)
+case NETLINK_EXT_ACK:
+#endif /* LINUX_VERSION_CODE >= KERNEL_VERSION(4, 12, 0) */
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 20, 0)
+case NETLINK_GET_STRICT_CHK:
+#endif /* LINUX_VERSION_CODE >= KERNEL_VERSION(4, 12, 0) */
+break;
+default:
+goto unimplemented;
+}
+val = 0;
+if (optlen < sizeof(uint32_t)) {
+return -TARGET_EINVAL;
+}
+if (get_user_u32(val, optval_addr)) {
+return -TARGET_EFAULT;
+}
+ret = get_errno(setsockopt(sockfd, SOL_NETLINK, optname, , 
sizeof(val)));
+break;
+#endif /* SOL_NETLINK */
 default:
 unimplemented:
 gemu_log("Unsupported setsockopt level=%d optname=%d\n", level, 
optname);
@@ -2531,6 +2563,72 @@ static abi_long do_getsockopt(int sockfd, int level, int 
optname,
 break;
 }
 break;
+#ifdef SOL_NETLINK
+case SOL_NETLINK:
+switch (optname) {
+case NETLINK_PKTINFO:
+case NETLINK_BROADCAST_ERROR:
+case NETLINK_NO_ENOBUFS:
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 2, 0)
+case NETLINK_LISTEN_ALL_NSID:
+case NETLINK_CAP_ACK:
+#endif /* LINUX_VERSION_CODE >= KERNEL_VERSION(4, 2, 0) */
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 12, 0)
+case NETLINK_EXT_ACK:
+#endif /* LINUX_VERSION_CODE >= KERNEL_VERSION(4, 12, 0) */
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 20, 0)
+case NETLINK_GET_STRICT_CHK:
+#endif /* LINUX_VERSION_CODE >= KERNEL_VERSION(4, 12, 0) */
+if (get_user_u32(len, optlen)) {
+return -TARGET_EFAULT;
+}
+if (len != sizeof(val)) {
+return -TARGET_EINVAL;
+}
+lv = len;
+ret = get_errno(getsockopt(sockfd, level, optname, , ));
+if (ret < 0) {
+return ret;
+}
+if (put_user_u32(lv, optlen)
+|| put_user_u32(val, optval_addr)) {
+return -TARGET_EFAULT;
+}
+break;
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 2, 0)
+case NETLINK_LIST_MEMBERSHIPS:
+{
+if (get_user_u32(len, optlen)) {
+return -TARGET_EFAULT;
+}
+if (len < 0) {
+return -TARGET_EINVAL;
+}
+uint32_t *results = lock_user(VERIFY_WRITE, optval_addr, len, 1);
+if (!results) {
+return -TARGET_EFAULT;
+}
+lv = len;
+ret = get_errno(getsockopt(sockfd, level, optname, results, ));
+if (ret < 0) {
+unlock_user(results, optval_addr, 0);
+return ret;
+}
+/* swap host endianess to target endianess. */
+for (int i = 0; i < (len / sizeof(uint32_t)); i++) {
+results[i] = tswap32(results[i]);
+}
+if (put_user_u32(lv, optlen)) {
+return -TARGET_EFAULT;
+}
+unlock_user(results, optval_addr, 0);
+break;
+}
+#endif /* LINUX_VERSION_CODE >= KERNEL_VERSION(4, 2, 0) */
+default:
+goto unimplemented;
+}
+#endif /* SOL_NETLINK */
 default:
 unimplemented:
 gemu_log("getsockopt level=%d optname=%d not yet supported\n",
-- 
2.24.0.rc0.303.g954a862665-goog




Re: [PATCH v6 06/11] qapi: add failover negotiated event

2019-10-29 Thread Michael S. Tsirkin
On Fri, Oct 25, 2019 at 07:39:21PM +0200, Jens Freimann wrote:
> On Fri, Oct 25, 2019 at 04:03:54PM +0200, Markus Armbruster wrote:
> > Bear with me, I know next to nothing about failover.
> > 
> > Jens Freimann  writes:
> > 
> > > This event is sent to let libvirt know that VIRTIO_NET_F_STANDBY feature
> > > was enabled. The primary device this virtio-net device is associated
> > > with, will now be hotplugged via qdev_device_add().
> > 
> > Passive voice deftly avoids telling the reader who will do the
> > hot-plugging.  Intentional?
> 
> Not really, it's in the comment to the event. The hotplug will be
> done by the virtio-net device code that activates the feature, in
> virtio_net_set_features().
> 
> > 
> > > Signed-off-by: Jens Freimann 
> > > Acked-by: Cornelia Huck 
> > > ---
> > >  qapi/net.json | 19 +++
> > >  1 file changed, 19 insertions(+)
> > > 
> > > diff --git a/qapi/net.json b/qapi/net.json
> > > index 728990f4fb..ea64f7 100644
> > > --- a/qapi/net.json
> > > +++ b/qapi/net.json
> > > @@ -737,3 +737,22 @@
> > >  ##
> > >  { 'command': 'announce-self', 'boxed': true,
> > >'data' : 'AnnounceParameters'}
> > > +
> > > +##
> > > +# @FAILOVER_NEGOTIATED:
> > > +#
> > > +# Emitted when VIRTIO_NET_F_STANDBY was enabled during feature 
> > > negotiation.
> > > +# Failover primary devices which were hidden (not hotplugged when 
> > > requested)
> > > +# before will now be hotplugged by the virtio-net standby device.
> > > +#
> > > +# device-id: QEMU device id of the unplugged device
> > 
> > @device-id is new since v5.
> > 
> > A quick skim of
> > https://www.kernel.org/doc/html/latest/networking/net_failover.html
> > tells me there are three devices involved: master, primary slave,
> > standby slave.  Which one is @device-id?  Or am I confused?
> 
> Yes, the device-id is new and it's the device-id of the standby (i.e.
> virtio-net) device.
> 
> regards,
> Jens

And now I am confused.
How is standby "the unplugged device"?
Why not just say "the standby device"?

-- 
MST



Re: [PULL 00/20] hw/i386/pc: Split PIIX3 southbridge from i440FX northbridge

2019-10-29 Thread Aleksandar Markovic
On Tuesday, October 29, 2019, Philippe Mathieu-Daudé 
wrote:

> Hi Aleksandar,
>
> On 10/29/19 6:18 AM, Aleksandar Markovic wrote:
>
>>
>>
>> On Monday, October 28, 2019, Philippe Mathieu-Daudé > > wrote:
>>
>> Hi Peter,
>>
>> This is a X86/MIPS pull, Paolo and Aleksandar are OK I send it:
>>
>> https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg04959.html
>> 
>>
>> Regards,
>>
>> Phil.
>>
>>
>> Does this pull request apply on the current code base directly, or is
>> dependant on prior application of other pull requests?
>>
>
> I'm not sure I understand the question, this is a pull request, so it has
> been tested on the commit on the last master commit (yesterday),
> the cover says commit '9bb7350232'. Is there a problem?


My question was crystal clear, I can't believe you couldn't understand it.

There is no problem in that case (if your request applies on the master at
the moment of the submission),, but you for unknown reason mentioned in
another message that you plan to submit your pull request AFTER merging
Paolo's pull request, creating a confusion whether these pull request
depend each on another.

I am happy if this pull request is finally merged.

I supported this series from the outset, and I still support it, and think
it is a truly valuable reorganization of involved QEMU segment, and I
salute its integration. But I did not like the process of integration that
I thought would be a smooth sailing, but because of surrounding
self-imposed circumstances, it became at times very rocky road. I advise
you that, in future, you try to do one thing at the time, and I think you
can achieve far more that way, even if this does not look that way at furst
glance.

Still, you deserve all kudos for the series!

Yours,
Aleksandar



>
> The following changes since commit
>> 9bb73502321d46f4d320fa17aa38201445783fc4:
>>
>>Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into
>> staging (2019-10-28 13:32:40 +)
>>
>> are available in the Git repository at:
>>
>> https://gitlab.com/philmd/qemu.git
>> 
>> tags/pc_split_i440fx_piix-pull-request
>>
>> for you to fetch changes up to d1389352cde824ce8dab7c1a2ded15
>> 0df6add124:
>>
>>hw/pci-host/i440fx: Remove the last PIIX3 traces (2019-10-28
>> 16:12:29 +0100)
>>
>> 
>> The i440FX northbridge is only used by the PC machine, while the
>> PIIX southbridge is also used by the Malta MIPS machine.
>>
>> Split the PIIX3 southbridge from i440FX northbridge.
>>
>> 
>>
>> Hervé Poussineau (5):
>>piix4: Add the Reset Control Register
>>piix4: Add an i8259 Interrupt Controller as specified in datasheet
>>piix4: Rename PIIX4 object to piix4-isa
>>piix4: Add an i8257 DMA Controller as specified in datasheet
>>piix4: Add an i8254 PIT Controller as specified in datasheet
>>
>> Philippe Mathieu-Daudé (15):
>>MAINTAINERS: Keep PIIX4 South Bridge separate from PC Chipsets
>>Revert "irq: introduce qemu_irq_proxy()"
>>piix4: Add a MC146818 RTC Controller as specified in datasheet
>>hw/mips/mips_malta: Create IDE hard drive array dynamically
>>hw/mips/mips_malta: Extract the PIIX4 creation code as
>> piix4_create()
>>hw/isa/piix4: Move piix4_create() to hw/isa/piix4.c
>>hw/i386: Remove obsolete LoadStateHandler::load_state_old handlers
>>hw/pci-host/piix: Extract piix3_create()
>>hw/pci-host/piix: Move RCR_IOPORT register definition
>>hw/pci-host/piix: Define and use the PIIX IRQ Route Control
>> Registers
>>hw/pci-host/piix: Move i440FX declarations to hw/pci-host/i440fx.h
>>hw/pci-host/piix: Fix code style issues
>>hw/pci-host/piix: Extract PIIX3 functions to hw/isa/piix3.c
>>hw/pci-host: Rename incorrectly named 'piix' as 'i440fx'
>>hw/pci-host/i440fx: Remove the last PIIX3 traces
>>
>>   MAINTAINERS  |  14 +-
>>   hw/acpi/pcihp.c  |   2 +-
>>   hw/acpi/piix4.c  |  42 +--
>>   hw/core/irq.c|  14 -
>>   hw/i386/Kconfig  |   3 +-
>>   hw/i386/acpi-build.c |   5 +-
>>   hw/i386/pc_piix.c|  10 +-
>>   hw/i386/xen/xen-hvm.c|   5 +-
>>   hw/intc/apic_common.c|  49 
>>   hw/isa/Kconfig   |   4 +
>>   hw/isa/Makefile.objs |   1 +
>>   hw/isa/piix3.c   | 399 +
>>   hw/isa/piix4.c   | 151 ++-
>>   hw/mips/gt64xxx_pci.c|   5 +-
>>   hw/mips/mips_malta.c  

Re: [PATCH v35 00/13] QEMU AVR 8 bit cores

2019-10-29 Thread Michael Rolnik
Hi Aleksandar.

I appreciate it.

Regards,
Michael

On Tue, Oct 29, 2019 at 11:43 PM Aleksandar Markovic
 wrote:
>
>
>
> On Tuesday, October 29, 2019, Michael Rolnik  wrote:
>>
>> This series of patches adds 8bit AVR cores to QEMU.
>
>
> Hi Michael,
>
> I am going to take more detailed look at your series as soon as these hectic 
> days around softfreeze/hardfreeze days pass. It is definitely a series that 
> needed a lot of hard work, and it deserves to be seriously considered.
>
> Yours, Aleksandar
>
>
>>
>> All instruction, except BREAK/DES/SPM/SPMX, are implemented. Not fully 
>> tested yet.
>> However I was able to execute simple code with functions. e.g fibonacci 
>> calculation.
>> This series of patches include a non real, sample board.
>> No fuses support yet. PC is set to 0 at reset.
>>
>> the patches include the following
>> 1. just a basic 8bit AVR CPU, without instruction decoding or translation
>> 2. CPU features which allow define the following 8bit AVR cores
>>  avr1
>>  avr2 avr25
>>  avr3 avr31 avr35
>>  avr4
>>  avr5 avr51
>>  avr6
>>  xmega2 xmega4 xmega5 xmega6 xmega7
>> 3. a definition of sample machine with SRAM, FLASH and CPU which allows to 
>> execute simple code
>> 4. encoding for all AVR instructions
>> 5. interrupt handling
>> 6. helpers for IN, OUT, SLEEP, WBR & unsupported instructions
>> 7. a decoder which given an opcode decides what istruction it is
>> 8. translation of AVR instruction into TCG
>> 9. all features together
>>
>> changes since v3
>> 1. rampD/X/Y/Z registers are encoded as 0x00ff (instead of 0x00ff) 
>> for faster address manipulaton
>> 2. ffs changed to ctz32
>> 3. duplicate code removed at avr_cpu_do_interrupt
>> 4. using andc instead of not + and
>> 5. fixing V flag calculation in varios instructions
>> 6. freeing local variables in PUSH
>> 7. tcg_const_local_i32 -> tcg_const_i32
>> 8. using sextract32 instead of my implementation
>> 9. fixing BLD instruction
>> 10.xor(r) instead of 0xff - r at COM
>> 11.fixing MULS/MULSU not to modify inputs' content
>> 12.using SUB for NEG
>> 13.fixing tcg_gen_qemu_ld/st call in XCH
>>
>> changes since v4
>> 1. target is now defined as big endian in order to optimize push_ret/pop_ret
>> 2. all style warnings are fixed
>> 3. adding cpu_set/get_sreg functions
>> 4. simplifying gen_goto_tb as there is no real paging
>> 5. env->pc -> env->pc_w
>> 6. making flag dump more compact
>> 7. more spacing
>> 8. renaming CODE/DATA_INDEX -> MMU_CODE/DATA_IDX
>> 9. removing avr_set_feature
>> 10. SPL/SPH set bug fix
>> 11. switching stb_phys to cpu_stb_data
>> 12. cleaning up avr_decode
>> 13. saving sreg, rampD/X/Y/Z, eind in HW format (savevm)
>> 14. saving CPU features (savevm)
>>
>> changes since v5
>> 1. BLD bug fix
>> 2. decoder generator is added
>>
>> chages since v6
>> 1. using cpu_get_sreg/cpu_set_sreg in 
>> avr_cpu_gdb_read_register/avr_cpu_gdb_write_register
>> 2. configure the target as little endian because otherwise GDB does not work
>> 3. fixing and testing gen_push_ret/gen_pop_ret
>>
>> changes since v7
>> 1. folding back v6
>> 2. logging at helper_outb and helper_inb are done for non supported yet 
>> registers only
>> 3. MAINTAINERS updated
>>
>> changes since v8
>> 1. removing hw/avr from hw/Makefile.obj as it should not be built for all
>> 2. making linux compilable
>> 3. testing on
>> a. Mac, Apple LLVM version 7.0.0
>> b. Ubuntu 12.04, gcc 4.9.2
>> c. Fedora 23, gcc 5.3.1
>> 4. folding back some patches
>> 5. translation bug fixes for ORI, CPI, XOR instructions
>> 6. propper handling of cpu register writes though memory
>>
>> changes since v9
>> 1. removing forward declarations of static functions
>> 2. disabling debug prints
>> 3. switching to case range instead of if else if ...
>> 4. LD/ST IN/OUT accessing CPU maintainder registers are not routed to any 
>> device
>> 5. commenst about sample board and sample IO device added
>> 6. sample board description is more descriptive now
>> 7. memory_region_allocate_system_memory is used to create RAM
>> 8. now there are helper_fullrd & helper_fullwr when LD/ST try to access 
>> registers
>>
>> changes since v10
>> 1. movig back fullwr & fullrd into the commit where outb and inb were 
>> introduced
>> 2. changing tlb_fill function signature
>> 3. adding empty line between functions
>> 4. adding newline on the last line of the file
>> 5. using tb->flags to generae full access ST/LD instructions
>> 6. fixing SBRC bug
>> 7. folding back 10th commit
>> 8. whenever a new file is introduced it's added to Makefile.objs
>>
>> changes since v11
>> 1. updating to v2.7.0-rc
>> 2. removing assignment to env->fullacc from gen_intermediate_code
>>
>> changes since v12
>> 1. fixing spacing
>> 2. fixing get/put_segment functions
>> 3. removing target-avr/machine.h file
>> 4. VMSTATE_SINGLE_TEST -> VMSTATE_SINGLE
>> 5. comment spelling
>> 6. removing hw/avr/sample_io.c
>> 7. char const* -> const char*
>> 8. proper ram allocation
>> 9. 

Re: [PULL 0/16] Python (acceptance tests) queue, 2019-10-28

2019-10-29 Thread Cleber Rosa
On Tue, Oct 29, 2019 at 05:51:28PM -0400, Cleber Rosa wrote:
> On Tue, Oct 29, 2019 at 09:13:45PM +, Peter Maydell wrote:
> > On Mon, 28 Oct 2019 at 23:50, Cleber Rosa  wrote:
> > >
> > > The following changes since commit 
> > > aaffb853359829a37daaf883c773e8320b55c723:
> > >
> > >   Merge remote-tracking branch 
> > > 'remotes/maxreitz/tags/pull-block-2019-10-28' into staging (2019-10-28 
> > > 14:40:01 +)
> > >
> > > are available in the Git repository at:
> > >
> > >   git://github.com/clebergnu/qemu.git tags/python-next-pull-request
> > >
> > > for you to fetch changes up to efdb45bfd72745038909dfd1e970a827cb8d5d7e:
> > >
> > >   tests/boot_linux_console: Run BusyBox on 5KEc 64-bit cpu (2019-10-28 
> > > 19:04:04 -0400)
> > >
> > > 
> > 
> > Hi; unless my scripts are driving gpg wrong, this seems to
> > have been signed with an expired gpg key:
> > 
> > gpg: Signature made Mon 28 Oct 2019 23:43:11 GMT
> > gpg:using RSA key 7ABB96EB8B46B94D5E0FE9BB657E8D33A5F209F3
> > gpg: Good signature from "Cleber Rosa " [expired]
> > gpg: Note: This key has expired!
> > Primary key fingerprint: 7ABB 96EB 8B46 B94D 5E0F  E9BB 657E 8D33 A5F2 09F3
> > 
> > 
> > thanks
> > -- PMM
> 
> Hi Peter,
> 
> Nothing wrong with your scripts.  I updated my key about a week ago,
> but I'm almost certain that the key servers that I sent it to was
> acting funky.
> 
> After some further pushes, I see it on:
> 
>   
> http://keys.gnupg.net/pks/lookup?op=vindex=on=0x657E8D33A5F209F3
> 
> ---
> 
> Search results for '0x657e8d33a5f209f3'
> Type bits/keyID cr. time   exp time   key expir
> pub  4096R/A5F209F3 2014-10-16
>Fingerprint=7ABB 96EB 8B46 B94D 5E0F  E9BB 657E 8D33 A5F2 09F3 
> 
> uid Cleber Rosa 
> sig  sig3  A5F209F3 2014-10-16 __ 2019-10-15 [selfsig]
> sig  sig   7657B59A 2014-10-16 __ __ Rudá Moura 
> 
> sig  sig   2527436A 2019-03-05 __ __ Eric Blake 
> 
> sig  sig   984DC5A6 2019-03-06 __ __ Eduardo Habkost 
> 
> sig  sig3  96799EF4 2019-03-06 __ __ Bandan Das 
> 
> sig  sig3  A5F209F3 2019-10-22 __ 2024-10-20 [selfsig]
> 
> sub  4096R/5B75AD33 2014-10-16
> sig sbind  A5F209F3 2014-10-16 __ 2019-10-15 []
> sig sbind  A5F209F3 2019-10-22 __ 2024-10-20 []
> 
> ---
> 
> And with a fresh environment:
> 
>   $ podman run --rm -ti fedora:30
>   [root@afba6c046a22 /]# gpg --search-key 657E8D33A5F209F3
>   gpg: directory '/root/.gnupg' created
>   gpg: keybox '/root/.gnupg/pubring.kbx' created
>   gpg: data source: https://51.38.91.189:443
>   (1) Cleber Rosa 
> 4096 bit RSA key 657E8D33A5F209F3, created: 2014-10-16, expires: 
> 2024-10-20
>   Keys 1-1 of 1 for "657E8D33A5F209F3".  Enter number(s), N)ext, or Q)uit > 1
>   gpg: key 657E8D33A5F209F3: 4 signatures not checked due to missing keys
>   gpg: /root/.gnupg/trustdb.gpg: trustdb created
>   gpg: key 657E8D33A5F209F3: public key "Cleber Rosa " 
> imported
>   gpg: no ultimately trusted keys found
>   gpg: Total number processed: 1
>   gpg:   imported: 1
> 
> ---
> 
> So I guess "all" you'd need is a refresh.  Sorry for the inconvenience,
> and let me know if there's anything else I can do.
> 
> - Cleber.

OK, so now I don't see the updated key anymore on the public key servers,
which confirms that I'm doing something wrong.

I'm trying to fix that situation.  Sorry for the inconvenience again.

- Cleber.




Re: [PULL 0/16] Python (acceptance tests) queue, 2019-10-28

2019-10-29 Thread Cleber Rosa
On Tue, Oct 29, 2019 at 09:13:45PM +, Peter Maydell wrote:
> On Mon, 28 Oct 2019 at 23:50, Cleber Rosa  wrote:
> >
> > The following changes since commit aaffb853359829a37daaf883c773e8320b55c723:
> >
> >   Merge remote-tracking branch 
> > 'remotes/maxreitz/tags/pull-block-2019-10-28' into staging (2019-10-28 
> > 14:40:01 +)
> >
> > are available in the Git repository at:
> >
> >   git://github.com/clebergnu/qemu.git tags/python-next-pull-request
> >
> > for you to fetch changes up to efdb45bfd72745038909dfd1e970a827cb8d5d7e:
> >
> >   tests/boot_linux_console: Run BusyBox on 5KEc 64-bit cpu (2019-10-28 
> > 19:04:04 -0400)
> >
> > 
> 
> Hi; unless my scripts are driving gpg wrong, this seems to
> have been signed with an expired gpg key:
> 
> gpg: Signature made Mon 28 Oct 2019 23:43:11 GMT
> gpg:using RSA key 7ABB96EB8B46B94D5E0FE9BB657E8D33A5F209F3
> gpg: Good signature from "Cleber Rosa " [expired]
> gpg: Note: This key has expired!
> Primary key fingerprint: 7ABB 96EB 8B46 B94D 5E0F  E9BB 657E 8D33 A5F2 09F3
> 
> 
> thanks
> -- PMM

Hi Peter,

Nothing wrong with your scripts.  I updated my key about a week ago,
but I'm almost certain that the key servers that I sent it to was
acting funky.

After some further pushes, I see it on:

  
http://keys.gnupg.net/pks/lookup?op=vindex=on=0x657E8D33A5F209F3

---

Search results for '0x657e8d33a5f209f3'
Type bits/keyID cr. time   exp time   key expir
pub  4096R/A5F209F3 2014-10-16
 Fingerprint=7ABB 96EB 8B46 B94D 5E0F  E9BB 657E 8D33 A5F2 09F3 

uid Cleber Rosa 
sig  sig3  A5F209F3 2014-10-16 __ 2019-10-15 [selfsig]
sig  sig   7657B59A 2014-10-16 __ __ Rudá Moura 

sig  sig   2527436A 2019-03-05 __ __ Eric Blake 

sig  sig   984DC5A6 2019-03-06 __ __ Eduardo Habkost 

sig  sig3  96799EF4 2019-03-06 __ __ Bandan Das 

sig  sig3  A5F209F3 2019-10-22 __ 2024-10-20 [selfsig]

sub  4096R/5B75AD33 2014-10-16
sig sbind  A5F209F3 2014-10-16 __ 2019-10-15 []
sig sbind  A5F209F3 2019-10-22 __ 2024-10-20 []

---

And with a fresh environment:

  $ podman run --rm -ti fedora:30
  [root@afba6c046a22 /]# gpg --search-key 657E8D33A5F209F3
  gpg: directory '/root/.gnupg' created
  gpg: keybox '/root/.gnupg/pubring.kbx' created
  gpg: data source: https://51.38.91.189:443
  (1) Cleber Rosa 
4096 bit RSA key 657E8D33A5F209F3, created: 2014-10-16, expires: 
2024-10-20
  Keys 1-1 of 1 for "657E8D33A5F209F3".  Enter number(s), N)ext, or Q)uit > 1
  gpg: key 657E8D33A5F209F3: 4 signatures not checked due to missing keys
  gpg: /root/.gnupg/trustdb.gpg: trustdb created
  gpg: key 657E8D33A5F209F3: public key "Cleber Rosa " 
imported
  gpg: no ultimately trusted keys found
  gpg: Total number processed: 1
  gpg:   imported: 1

---

So I guess "all" you'd need is a refresh.  Sorry for the inconvenience,
and let me know if there's anything else I can do.

- Cleber.




Re: [PATCH v35 00/13] QEMU AVR 8 bit cores

2019-10-29 Thread Aleksandar Markovic
On Tuesday, October 29, 2019, Michael Rolnik  wrote:

> This series of patches adds 8bit AVR cores to QEMU.


Hi Michael,

I am going to take more detailed look at your series as soon as these
hectic days around softfreeze/hardfreeze days pass. It is definitely a
series that needed a lot of hard work, and it deserves to be seriously
considered.

Yours, Aleksandar



> All instruction, except BREAK/DES/SPM/SPMX, are implemented. Not fully
> tested yet.
> However I was able to execute simple code with functions. e.g fibonacci
> calculation.
> This series of patches include a non real, sample board.
> No fuses support yet. PC is set to 0 at reset.
>
> the patches include the following
> 1. just a basic 8bit AVR CPU, without instruction decoding or translation
> 2. CPU features which allow define the following 8bit AVR cores
>  avr1
>  avr2 avr25
>  avr3 avr31 avr35
>  avr4
>  avr5 avr51
>  avr6
>  xmega2 xmega4 xmega5 xmega6 xmega7
> 3. a definition of sample machine with SRAM, FLASH and CPU which allows to
> execute simple code
> 4. encoding for all AVR instructions
> 5. interrupt handling
> 6. helpers for IN, OUT, SLEEP, WBR & unsupported instructions
> 7. a decoder which given an opcode decides what istruction it is
> 8. translation of AVR instruction into TCG
> 9. all features together
>
> changes since v3
> 1. rampD/X/Y/Z registers are encoded as 0x00ff (instead of 0x00ff)
> for faster address manipulaton
> 2. ffs changed to ctz32
> 3. duplicate code removed at avr_cpu_do_interrupt
> 4. using andc instead of not + and
> 5. fixing V flag calculation in varios instructions
> 6. freeing local variables in PUSH
> 7. tcg_const_local_i32 -> tcg_const_i32
> 8. using sextract32 instead of my implementation
> 9. fixing BLD instruction
> 10.xor(r) instead of 0xff - r at COM
> 11.fixing MULS/MULSU not to modify inputs' content
> 12.using SUB for NEG
> 13.fixing tcg_gen_qemu_ld/st call in XCH
>
> changes since v4
> 1. target is now defined as big endian in order to optimize
> push_ret/pop_ret
> 2. all style warnings are fixed
> 3. adding cpu_set/get_sreg functions
> 4. simplifying gen_goto_tb as there is no real paging
> 5. env->pc -> env->pc_w
> 6. making flag dump more compact
> 7. more spacing
> 8. renaming CODE/DATA_INDEX -> MMU_CODE/DATA_IDX
> 9. removing avr_set_feature
> 10. SPL/SPH set bug fix
> 11. switching stb_phys to cpu_stb_data
> 12. cleaning up avr_decode
> 13. saving sreg, rampD/X/Y/Z, eind in HW format (savevm)
> 14. saving CPU features (savevm)
>
> changes since v5
> 1. BLD bug fix
> 2. decoder generator is added
>
> chages since v6
> 1. using cpu_get_sreg/cpu_set_sreg in avr_cpu_gdb_read_register/avr_
> cpu_gdb_write_register
> 2. configure the target as little endian because otherwise GDB does not
> work
> 3. fixing and testing gen_push_ret/gen_pop_ret
>
> changes since v7
> 1. folding back v6
> 2. logging at helper_outb and helper_inb are done for non supported yet
> registers only
> 3. MAINTAINERS updated
>
> changes since v8
> 1. removing hw/avr from hw/Makefile.obj as it should not be built for all
> 2. making linux compilable
> 3. testing on
> a. Mac, Apple LLVM version 7.0.0
> b. Ubuntu 12.04, gcc 4.9.2
> c. Fedora 23, gcc 5.3.1
> 4. folding back some patches
> 5. translation bug fixes for ORI, CPI, XOR instructions
> 6. propper handling of cpu register writes though memory
>
> changes since v9
> 1. removing forward declarations of static functions
> 2. disabling debug prints
> 3. switching to case range instead of if else if ...
> 4. LD/ST IN/OUT accessing CPU maintainder registers are not routed to any
> device
> 5. commenst about sample board and sample IO device added
> 6. sample board description is more descriptive now
> 7. memory_region_allocate_system_memory is used to create RAM
> 8. now there are helper_fullrd & helper_fullwr when LD/ST try to access
> registers
>
> changes since v10
> 1. movig back fullwr & fullrd into the commit where outb and inb were
> introduced
> 2. changing tlb_fill function signature
> 3. adding empty line between functions
> 4. adding newline on the last line of the file
> 5. using tb->flags to generae full access ST/LD instructions
> 6. fixing SBRC bug
> 7. folding back 10th commit
> 8. whenever a new file is introduced it's added to Makefile.objs
>
> changes since v11
> 1. updating to v2.7.0-rc
> 2. removing assignment to env->fullacc from gen_intermediate_code
>
> changes since v12
> 1. fixing spacing
> 2. fixing get/put_segment functions
> 3. removing target-avr/machine.h file
> 4. VMSTATE_SINGLE_TEST -> VMSTATE_SINGLE
> 5. comment spelling
> 6. removing hw/avr/sample_io.c
> 7. char const* -> const char*
> 8. proper ram allocation
> 9. fixing breakpoint functionality.
> 10.env1 -> env
> 11.fixing avr_cpu_gdb_write_register & avr_cpu_gdb_read_register functions
> 12.any cpu is removed
> 12.feature bits are not saved into vm state
>
> changes since v13
> 1. rebasing to v2.7.0-rc1
>
> changes since v14
> 

[PATCH v35 10/13] target/avr: Add limited support for USART and 16 bit timer peripherals

2019-10-29 Thread Michael Rolnik
From: Sarah Harris 

These were designed to facilitate testing but should provide enough function to 
be useful in other contexts.
Only a subset of the functions of each peripheral is implemented, mainly due to 
the lack of a standard way to handle electrical connections (like GPIO pins).

Signed-off-by: Sarah Harris 
---
 hw/char/Kconfig|   3 +
 hw/char/Makefile.objs  |   1 +
 hw/char/avr_usart.c| 324 ++
 hw/misc/Kconfig|   3 +
 hw/misc/Makefile.objs  |   2 +
 hw/misc/avr_mask.c | 112 ++
 hw/timer/Kconfig   |   3 +
 hw/timer/Makefile.objs |   2 +
 hw/timer/avr_timer16.c | 605 +
 include/hw/char/avr_usart.h|  97 ++
 include/hw/misc/avr_mask.h |  47 +++
 include/hw/timer/avr_timer16.h |  97 ++
 12 files changed, 1296 insertions(+)
 create mode 100644 hw/char/avr_usart.c
 create mode 100644 hw/misc/avr_mask.c
 create mode 100644 hw/timer/avr_timer16.c
 create mode 100644 include/hw/char/avr_usart.h
 create mode 100644 include/hw/misc/avr_mask.h
 create mode 100644 include/hw/timer/avr_timer16.h

diff --git a/hw/char/Kconfig b/hw/char/Kconfig
index 40e7a8b8bb..331b20983f 100644
--- a/hw/char/Kconfig
+++ b/hw/char/Kconfig
@@ -46,3 +46,6 @@ config SCLPCONSOLE
 
 config TERMINAL3270
 bool
+
+config AVR_USART
+bool
diff --git a/hw/char/Makefile.objs b/hw/char/Makefile.objs
index 02d8a66925..f05c1f5667 100644
--- a/hw/char/Makefile.objs
+++ b/hw/char/Makefile.objs
@@ -21,6 +21,7 @@ obj-$(CONFIG_PSERIES) += spapr_vty.o
 obj-$(CONFIG_DIGIC) += digic-uart.o
 obj-$(CONFIG_STM32F2XX_USART) += stm32f2xx_usart.o
 obj-$(CONFIG_RASPI) += bcm2835_aux.o
+common-obj-$(CONFIG_AVR_USART) += avr_usart.o
 
 common-obj-$(CONFIG_CMSDK_APB_UART) += cmsdk-apb-uart.o
 common-obj-$(CONFIG_ETRAXFS) += etraxfs_ser.o
diff --git a/hw/char/avr_usart.c b/hw/char/avr_usart.c
new file mode 100644
index 00..9ca3c2a1cd
--- /dev/null
+++ b/hw/char/avr_usart.c
@@ -0,0 +1,324 @@
+/*
+ * AVR USART
+ *
+ * Copyright (c) 2018 University of Kent
+ * Author: Sarah Harris
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "qemu/osdep.h"
+#include "hw/char/avr_usart.h"
+#include "qemu/log.h"
+#include "hw/irq.h"
+#include "hw/qdev-properties.h"
+
+static int avr_usart_can_receive(void *opaque)
+{
+AVRUsartState *usart = opaque;
+
+if (usart->data_valid || !(usart->csrb & USART_CSRB_RXEN)) {
+return 0;
+}
+return 1;
+}
+
+static void avr_usart_receive(void *opaque, const uint8_t *buffer, int size)
+{
+AVRUsartState *usart = opaque;
+assert(size == 1);
+assert(!usart->data_valid);
+usart->data = buffer[0];
+usart->data_valid = true;
+usart->csra |= USART_CSRA_RXC;
+if (usart->csrb & USART_CSRB_RXCIE) {
+qemu_set_irq(usart->rxc_irq, 1);
+}
+}
+
+static void update_char_mask(AVRUsartState *usart)
+{
+uint8_t mode = ((usart->csrc & USART_CSRC_CSZ0) ? 1 : 0) |
+((usart->csrc & USART_CSRC_CSZ1) ? 2 : 0) |
+((usart->csrb & USART_CSRB_CSZ2) ? 4 : 0);
+switch (mode) {
+case 0:
+usart->char_mask = 0b1;
+break;
+case 1:
+usart->char_mask = 0b11;
+break;
+case 2:
+usart->char_mask = 0b111;
+break;
+case 3:
+usart->char_mask = 0b;
+break;
+case 4:
+/* Fallthrough. */
+case 5:
+/* Fallthrough. */
+case 6:
+qemu_log_mask(
+LOG_GUEST_ERROR,
+"%s: Reserved character size 0x%x\n",
+__func__,
+mode);
+break;
+case 7:
+qemu_log_mask(
+LOG_GUEST_ERROR,
+"%s: Nine bit character size not supported (forcing eight)\n",
+__func__);
+usart->char_mask = 0b;
+break;
+default:
+assert(0);
+}
+}
+

[PATCH v35 11/13] target/avr: Add example board configuration

2019-10-29 Thread Michael Rolnik
A simple board setup that configures an AVR CPU to run a given firmware image.
This is all that's useful to implement without peripheral emulation as AVR CPUs 
include a lot of on-board peripherals.

NOTE: this is not a real board 
NOTE: it's used for CPU testing

Signed-off-by: Michael Rolnik 
---
 hw/Kconfig   |   1 +
 hw/avr/Kconfig   |   6 +
 hw/avr/Makefile.objs |   1 +
 hw/avr/sample.c  | 282 +++
 4 files changed, 290 insertions(+)
 create mode 100644 hw/avr/Kconfig
 create mode 100644 hw/avr/Makefile.objs
 create mode 100644 hw/avr/sample.c

diff --git a/hw/Kconfig b/hw/Kconfig
index b9685b3944..07b8abb342 100644
--- a/hw/Kconfig
+++ b/hw/Kconfig
@@ -44,6 +44,7 @@ source watchdog/Kconfig
 # arch Kconfig
 source arm/Kconfig
 source alpha/Kconfig
+source avr/Kconfig
 source cris/Kconfig
 source hppa/Kconfig
 source i386/Kconfig
diff --git a/hw/avr/Kconfig b/hw/avr/Kconfig
new file mode 100644
index 00..92aa1e6afb
--- /dev/null
+++ b/hw/avr/Kconfig
@@ -0,0 +1,6 @@
+config AVR_SAMPLE
+bool
+select AVR_TIMER16
+select AVR_USART
+select AVR_MASK
+select UNIMP
diff --git a/hw/avr/Makefile.objs b/hw/avr/Makefile.objs
new file mode 100644
index 00..626b7064b3
--- /dev/null
+++ b/hw/avr/Makefile.objs
@@ -0,0 +1 @@
+obj-y += sample.o
diff --git a/hw/avr/sample.c b/hw/avr/sample.c
new file mode 100644
index 00..2295ec1b79
--- /dev/null
+++ b/hw/avr/sample.c
@@ -0,0 +1,282 @@
+/*
+ * QEMU AVR CPU
+ *
+ * Copyright (c) 2019 Michael Rolnik
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * 
+ */
+
+/*
+ *  NOTE:
+ *  This is not a real AVR board, this is an example!
+ *  The CPU is an approximation of an ATmega2560, but is missing various
+ *  built-in peripherals.
+ *
+ *  This example board loads provided binary file into flash memory and
+ *  executes it from 0x address in the code memory space.
+ *
+ *  Currently used for AVR CPU validation
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "qemu-common.h"
+#include "cpu.h"
+#include "hw/hw.h"
+#include "sysemu/sysemu.h"
+#include "sysemu/qtest.h"
+#include "ui/console.h"
+#include "hw/boards.h"
+#include "hw/loader.h"
+#include "qemu/error-report.h"
+#include "exec/address-spaces.h"
+#include "include/hw/sysbus.h"
+#include "include/hw/char/avr_usart.h"
+#include "include/hw/timer/avr_timer16.h"
+#include "include/hw/misc/avr_mask.h"
+#include "elf.h"
+#include "hw/misc/unimp.h"
+
+#define SIZE_FLASH 0x0004
+#define SIZE_SRAM 0x2000
+/*
+ * Size of additional "external" memory, as if the AVR were configured to use
+ * an external RAM chip.
+ * Note that the configuration registers that normally enable this feature are
+ * unimplemented.
+ */
+#define SIZE_EXMEM 0x
+
+/* Offsets of peripherals in emulated memory space (i.e. not host addresses)  
*/
+#define PRR0_BASE 0x64
+#define PRR1_BASE 0x65
+#define USART_BASE 0xc0
+#define TIMER1_BASE 0x80
+#define TIMER1_IMSK_BASE 0x6f
+#define TIMER1_IFR_BASE 0x36
+
+/* Interrupt numbers used by peripherals */
+#define USART_RXC_IRQ 24
+#define USART_DRE_IRQ 25
+#define USART_TXC_IRQ 26
+
+#define TIMER1_CAPT_IRQ 15
+#define TIMER1_COMPA_IRQ 16
+#define TIMER1_COMPB_IRQ 17
+#define TIMER1_COMPC_IRQ 18
+#define TIMER1_OVF_IRQ 19
+
+/*  Power reduction */
+#define PRR1_BIT_PRTIM5 0x05/*  Timer/Counter5  */
+#define PRR1_BIT_PRTIM4 0x04/*  Timer/Counter4  */
+#define PRR1_BIT_PRTIM3 0x03/*  Timer/Counter3  */
+#define PRR1_BIT_PRUSART3   0x02/*  USART3  */
+#define PRR1_BIT_PRUSART2   0x01/*  USART2  */
+#define PRR1_BIT_PRUSART1   0x00/*  USART1  */
+
+#define PRR0_BIT_PRTWI  0x06/*  TWI */
+#define PRR0_BIT_PRTIM2 0x05/*  Timer/Counter2  */
+#define PRR0_BIT_PRTIM0 0x04/*  Timer/Counter0  */
+#define PRR0_BIT_PRTIM1 0x03/*  Timer/Counter1  */
+#define PRR0_BIT_PRSPI  0x02/*  Serial Peripheral Interface */
+#define PRR0_BIT_PRUSART0   0x01/*  USART0  */
+#define PRR0_BIT_PRADC  0x00/*  ADC */
+
+typedef struct {
+MachineClass parent;
+} SampleMachineClass;
+
+typedef struct {
+MachineState parent;
+MemoryRegion *ram;
+MemoryRegion *flash;
+AVRUsartState *usart0;
+AVRTimer16State *timer1;
+

[PATCH v35 12/13] target/avr: Register AVR support with the rest of QEMU, the build system, and the WMAINTAINERS file

2019-10-29 Thread Michael Rolnik
Signed-off-by: Michael Rolnik 
---
 MAINTAINERS |  9 +
 arch_init.c |  2 ++
 configure   |  7 +++
 default-configs/avr-softmmu.mak |  5 +
 include/disas/dis-asm.h |  6 ++
 include/sysemu/arch_init.h  |  1 +
 qapi/machine.json   |  3 ++-
 target/avr/Makefile.objs| 33 +
 tests/machine-none-test.c   |  1 +
 9 files changed, 66 insertions(+), 1 deletion(-)
 create mode 100644 default-configs/avr-softmmu.mak
 create mode 100644 target/avr/Makefile.objs

diff --git a/MAINTAINERS b/MAINTAINERS
index 5b27888533..01f951356f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -163,6 +163,15 @@ S: Maintained
 F: hw/arm/smmu*
 F: include/hw/arm/smmu*
 
+AVR TCG CPUs
+M: Michael Rolnik 
+S: Maintained
+F: target/avr/
+F: hw/misc/avr_mask.c
+F: hw/char/avr_usart.c
+F: hw/timer/avr_timer16.c
+F: hw/avr/
+
 CRIS TCG CPUs
 M: Edgar E. Iglesias 
 S: Maintained
diff --git a/arch_init.c b/arch_init.c
index 705d0b94ad..6a741165b2 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -89,6 +89,8 @@ int graphic_depth = 32;
 #define QEMU_ARCH QEMU_ARCH_UNICORE32
 #elif defined(TARGET_XTENSA)
 #define QEMU_ARCH QEMU_ARCH_XTENSA
+#elif defined(TARGET_AVR)
+#define QEMU_ARCH QEMU_ARCH_AVR
 #endif
 
 const uint32_t arch_type = QEMU_ARCH;
diff --git a/configure b/configure
index 3be9e92a24..e5dec62fde 100755
--- a/configure
+++ b/configure
@@ -7516,6 +7516,10 @@ case "$target_name" in
 mttcg="yes"
 gdb_xml_files="aarch64-core.xml aarch64-fpu.xml arm-core.xml arm-vfp.xml 
arm-vfp3.xml arm-neon.xml"
   ;;
+  avr)
+gdb_xml_files="avr-cpu.xml"
+target_compiler=$cross_cc_avr
+  ;;
   cris)
   ;;
   hppa)
@@ -7735,6 +7739,9 @@ for i in $ARCH $TARGET_BASE_ARCH ; do
   disas_config "ARM_A64"
 fi
   ;;
+  avr)
+disas_config "AVR"
+  ;;
   cris)
 disas_config "CRIS"
   ;;
diff --git a/default-configs/avr-softmmu.mak b/default-configs/avr-softmmu.mak
new file mode 100644
index 00..d1e1c28118
--- /dev/null
+++ b/default-configs/avr-softmmu.mak
@@ -0,0 +1,5 @@
+# Default configuration for avr-softmmu
+
+# Boards:
+#
+CONFIG_AVR_SAMPLE=y
diff --git a/include/disas/dis-asm.h b/include/disas/dis-asm.h
index e9c7dd8eb4..8bedce17ac 100644
--- a/include/disas/dis-asm.h
+++ b/include/disas/dis-asm.h
@@ -211,6 +211,12 @@ enum bfd_architecture
 #define bfd_mach_m32r  0  /* backwards compatibility */
   bfd_arch_mn10200,/* Matsushita MN10200 */
   bfd_arch_mn10300,/* Matsushita MN10300 */
+  bfd_arch_avr,   /* Atmel AVR microcontrollers.  */
+#define bfd_mach_avr1  1
+#define bfd_mach_avr2  2
+#define bfd_mach_avr3  3
+#define bfd_mach_avr4  4
+#define bfd_mach_avr5  5
   bfd_arch_cris,   /* Axis CRIS */
 #define bfd_mach_cris_v0_v10   255
 #define bfd_mach_cris_v32  32
diff --git a/include/sysemu/arch_init.h b/include/sysemu/arch_init.h
index 62c6fe4cf1..893df26ce2 100644
--- a/include/sysemu/arch_init.h
+++ b/include/sysemu/arch_init.h
@@ -24,6 +24,7 @@ enum {
 QEMU_ARCH_NIOS2 = (1 << 17),
 QEMU_ARCH_HPPA = (1 << 18),
 QEMU_ARCH_RISCV = (1 << 19),
+QEMU_ARCH_AVR = (1 << 20),
 };
 
 extern const uint32_t arch_type;
diff --git a/qapi/machine.json b/qapi/machine.json
index ca26779f1a..1fa2917ba9 100644
--- a/qapi/machine.json
+++ b/qapi/machine.json
@@ -21,11 +21,12 @@
 #is true even for "qemu-system-x86_64".
 #
 # ppcemb: dropped in 3.1
+# avr: since 4.2
 #
 # Since: 3.0
 ##
 { 'enum' : 'SysEmuTarget',
-  'data' : [ 'aarch64', 'alpha', 'arm', 'cris', 'hppa', 'i386', 'lm32',
+  'data' : [ 'aarch64', 'alpha', 'arm', 'avr', 'cris', 'hppa', 'i386', 'lm32',
  'm68k', 'microblaze', 'microblazeel', 'mips', 'mips64',
  'mips64el', 'mipsel', 'moxie', 'nios2', 'or1k', 'ppc',
  'ppc64', 'riscv32', 'riscv64', 's390x', 'sh4',
diff --git a/target/avr/Makefile.objs b/target/avr/Makefile.objs
new file mode 100644
index 00..2976affd95
--- /dev/null
+++ b/target/avr/Makefile.objs
@@ -0,0 +1,33 @@
+#
+#  QEMU AVR CPU
+#
+#  Copyright (c) 2019 Michael Rolnik
+#
+#  This library is free software; you can redistribute it and/or
+#  modify it under the terms of the GNU Lesser General Public
+#  License as published by the Free Software Foundation; either
+#  version 2.1 of the License, or (at your option) any later version.
+#
+#  This library 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
+#  Lesser General Public License for more details.
+#
+#  You should have received a copy of the GNU Lesser General Public
+#  License along with this library; if not, see
+#  
+#
+
+DECODETREE = $(SRC_PATH)/scripts/decodetree.py
+decode-y = $(SRC_PATH)/target/avr/insn.decode
+
+target/avr/decode_insn.inc.c: 

[PATCH v35 13/13] target/avr: Add tests

2019-10-29 Thread Michael Rolnik
1. Avocado test
The test is based on
https://github.com/seharris/qemu-avr-tests/tree/master/free-rtos/Demo
demo which. If working correctly, prints 'ABCDEFGHIJKLMNOPQRSTUVWX' out.
it also demostrates that timer and IRQ are working

2. Boot serial test
Print out 'T' through serial port

Signed-off-by: Michael Rolnik 
Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 
Acked-by: Thomas Huth 
---
 tests/Makefile.include   |  2 ++
 tests/acceptance/machine_avr6.py | 36 
 tests/boot-serial-test.c | 10 +
 3 files changed, 48 insertions(+)
 create mode 100644 tests/acceptance/machine_avr6.py

diff --git a/tests/Makefile.include b/tests/Makefile.include
index 7f487f65e7..3c077f6ca4 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -206,6 +206,8 @@ check-qtest-i386-y += tests/test-x86-cpuid-compat$(EXESUF)
 check-qtest-i386-y += tests/numa-test$(EXESUF)
 check-qtest-x86_64-y += $(check-qtest-i386-y)
 
+check-qtest-avr-y += tests/boot-serial-test$(EXESUF)
+
 check-qtest-alpha-y += tests/boot-serial-test$(EXESUF)
 check-qtest-alpha-$(CONFIG_VGA) += tests/display-vga-test$(EXESUF)
 
diff --git a/tests/acceptance/machine_avr6.py b/tests/acceptance/machine_avr6.py
new file mode 100644
index 00..0601080b01
--- /dev/null
+++ b/tests/acceptance/machine_avr6.py
@@ -0,0 +1,36 @@
+import logging
+import time
+import distutils.spawn
+
+from avocado import skipUnless
+from avocado_qemu import Test
+from avocado.utils import process
+
+class AVR6Machine(Test):
+timeout = 5
+
+def test_freertos(self):
+"""
+:avocado: tags=arch:avr
+:avocado: tags=machine:sample
+"""
+"""
+
https://github.com/seharris/qemu-avr-tests/raw/master/free-rtos/Demo/AVR_ATMega2560_GCC/demo.elf
+constantly prints out 
'ABCDEFGHIJKLMNOPQRSTUVWXABCDEFGHIJKLMNOPQRSTUVWX'
+"""
+rom_url = 'https://github.com/seharris/qemu-avr-tests'
+rom_url += '/raw/master/free-rtos/Demo/AVR_ATMega2560_GCC/demo.elf'
+rom_hash = '7eb521f511ca8f2622e0a3c5e8dd686efbb911d4'
+rom_path = self.fetch_asset(rom_url, asset_hash=rom_hash)
+
+self.vm.set_machine('sample')
+self.vm.add_args('-bios', rom_path)
+self.vm.add_args('-nographic')
+self.vm.launch()
+
+time.sleep(2)
+self.vm.shutdown()
+
+match = 'ABCDEFGHIJKLMNOPQRSTUVWXABCDEFGHIJKLMNOPQRSTUVWX'
+
+self.assertIn(match, self.vm.get_log())
diff --git a/tests/boot-serial-test.c b/tests/boot-serial-test.c
index d3a54a0ba5..1121ed0db2 100644
--- a/tests/boot-serial-test.c
+++ b/tests/boot-serial-test.c
@@ -16,6 +16,15 @@
 #include "qemu/osdep.h"
 #include "libqtest.h"
 
+static const uint8_t bios_avr[] = {
+0x88, 0xe0, /* ldi r24, 0x08   */
+0x80, 0x93, 0xc1, 0x00, /* sts 0x00C1, r24 ; Enable tx */
+0x86, 0xe0, /* ldi r24, 0x06   */
+0x80, 0x93, 0xc2, 0x00, /* sts 0x00C2, r24 ; Set the data bits to 8 */
+0x84, 0xe5, /* ldi r24, 0x54   */
+0x80, 0x93, 0xc6, 0x00, /* sts 0x00C6, r24 ; Output 'T' */
+};
+
 static const uint8_t kernel_mcf5208[] = {
 0x41, 0xf9, 0xfc, 0x06, 0x00, 0x00, /* lea 0xfc06,%a0 */
 0x10, 0x3c, 0x00, 0x54, /* move.b #'T',%d0 */
@@ -103,6 +112,7 @@ typedef struct testdef {
 
 static testdef_t tests[] = {
 { "alpha", "clipper", "", "PCI:" },
+{ "avr", "sample", "", "T", sizeof(bios_avr), NULL, bios_avr },
 { "ppc", "ppce500", "", "U-Boot" },
 { "ppc", "40p", "-vga none -boot d", "Trying cd:," },
 { "ppc", "g3beige", "", "PowerPC,750" },
-- 
2.17.2 (Apple Git-113)




[PATCH v35 07/13] target/avr: Add instruction translation - Bit and Bit-test Instructions

2019-10-29 Thread Michael Rolnik
This includes:
- LSR, ROR
- ASR
- SWAP
- SBI, CBI
- BST, BLD
- BSET, BCLR

Signed-off-by: Michael Rolnik 
---
 target/avr/translate.c | 1123 
 1 file changed, 1123 insertions(+)

diff --git a/target/avr/translate.c b/target/avr/translate.c
index 4ef3294a40..f2ec2e2d2f 100644
--- a/target/avr/translate.c
+++ b/target/avr/translate.c
@@ -304,6 +304,15 @@ static void gen_goto_tb(DisasContext *ctx, int n, 
target_ulong dest)
 }
 
 
+static void gen_rshift_ZNVSf(TCGv R)
+{
+tcg_gen_setcondi_tl(TCG_COND_EQ, cpu_Zf, R, 0); /* Zf = R == 0 */
+tcg_gen_shri_tl(cpu_Nf, R, 7); /* Nf = R(7) */
+tcg_gen_xor_tl(cpu_Vf, cpu_Nf, cpu_Cf);
+tcg_gen_xor_tl(cpu_Sf, cpu_Nf, cpu_Vf); /* Sf = Nf ^ Vf */
+}
+
+
 /*
  *  Adds two registers without the C Flag and places the result in the
  *  destination register Rd.
@@ -1495,3 +1504,1117 @@ static bool trans_BRBS(DisasContext *ctx, arg_BRBS *a)
 return true;
 }
 
+
+/*
+ *  This instruction makes a copy of one register into another. The source
+ *  register Rr is left unchanged, while the destination register Rd is loaded
+ *  with a copy of Rr.
+ */
+static bool trans_MOV(DisasContext *ctx, arg_MOV *a)
+{
+TCGv Rd = cpu_r[a->rd];
+TCGv Rr = cpu_r[a->rr];
+
+tcg_gen_mov_tl(Rd, Rr);
+
+return true;
+}
+
+
+/*
+ *  This instruction makes a copy of one register pair into another register
+ *  pair. The source register pair Rr+1:Rr is left unchanged, while the
+ *  destination register pair Rd+1:Rd is loaded with a copy of Rr + 1:Rr.  This
+ *  instruction is not available in all devices. Refer to the device specific
+ *  instruction set summary.
+ */
+static bool trans_MOVW(DisasContext *ctx, arg_MOVW *a)
+{
+if (!avr_have_feature(ctx, AVR_FEATURE_MOVW)) {
+return true;
+}
+
+TCGv RdL = cpu_r[a->rd];
+TCGv RdH = cpu_r[a->rd + 1];
+TCGv RrL = cpu_r[a->rr];
+TCGv RrH = cpu_r[a->rr + 1];
+
+tcg_gen_mov_tl(RdH, RrH);
+tcg_gen_mov_tl(RdL, RrL);
+
+return true;
+}
+
+
+/*
+ * Loads an 8 bit constant directly to register 16 to 31.
+ */
+static bool trans_LDI(DisasContext *ctx, arg_LDI *a)
+{
+TCGv Rd = cpu_r[a->rd];
+int imm = a->imm;
+
+tcg_gen_movi_tl(Rd, imm);
+
+return true;
+}
+
+
+/*
+ *  Loads one byte from the data space to a register. For parts with SRAM,
+ *  the data space consists of the Register File, I/O memory and internal SRAM
+ *  (and external SRAM if applicable). For parts without SRAM, the data space
+ *  consists of the register file only. The EEPROM has a separate address 
space.
+ *  A 16-bit address must be supplied. Memory access is limited to the current
+ *  data segment of 64KB. The LDS instruction uses the RAMPD Register to access
+ *  memory above 64KB. To access another data segment in devices with more than
+ *  64KB data space, the RAMPD in register in the I/O area has to be changed.
+ *  This instruction is not available in all devices. Refer to the device
+ *  specific instruction set summary.
+ */
+static bool trans_LDS(DisasContext *ctx, arg_LDS *a)
+{
+TCGv Rd = cpu_r[a->rd];
+TCGv addr = tcg_temp_new_i32();
+TCGv H = cpu_rampD;
+a->imm = next_word(ctx);
+
+tcg_gen_mov_tl(addr, H); /* addr = H:M:L */
+tcg_gen_shli_tl(addr, addr, 16);
+tcg_gen_ori_tl(addr, addr, a->imm);
+
+gen_data_load(ctx, Rd, addr);
+
+tcg_temp_free_i32(addr);
+
+return true;
+}
+
+
+/*
+ *  Loads one byte indirect from the data space to a register. For parts
+ *  with SRAM, the data space consists of the Register File, I/O memory and
+ *  internal SRAM (and external SRAM if applicable). For parts without SRAM, 
the
+ *  data space consists of the Register File only. In some parts the Flash
+ *  Memory has been mapped to the data space and can be read using this 
command.
+ *  The EEPROM has a separate address space.  The data location is pointed to 
by
+ *  the X (16 bits) Pointer Register in the Register File. Memory access is
+ *  limited to the current data segment of 64KB. To access another data segment
+ *  in devices with more than 64KB data space, the RAMPX in register in the I/O
+ *  area has to be changed.  The X-pointer Register can either be left 
unchanged
+ *  by the operation, or it can be post-incremented or predecremented.  These
+ *  features are especially suited for accessing arrays, tables, and Stack
+ *  Pointer usage of the X-pointer Register. Note that only the low byte of the
+ *  X-pointer is updated in devices with no more than 256 bytes data space. For
+ *  such devices, the high byte of the pointer is not used by this instruction
+ *  and can be used for other purposes. The RAMPX Register in the I/O area is
+ *  updated in parts with more than 64KB data space or more than 64KB Program
+ *  memory, and the increment/decrement is added to the entire 24-bit address 
on
+ *  such devices.  Not all variants of this instruction is available in all
+ *  devices. 

[PATCH v35 01/13] target/avr: Add outward facing interfaces and core CPU logic

2019-10-29 Thread Michael Rolnik
This includes:
- CPU data structures
- object model classes and functions
- migration functions
- GDB hooks

Co-developed-by: Michael Rolnik 
Co-developed-by: Sarah Harris 
Signed-off-by: Michael Rolnik 
Signed-off-by: Sarah Harris 
Signed-off-by: Michael Rolnik 
Acked-by: Igor Mammedov 
---
 gdb-xml/avr-cpu.xml|  49 
 target/avr/cpu-param.h |  37 +++
 target/avr/cpu-qom.h   |  54 
 target/avr/cpu.c   | 576 +
 target/avr/cpu.h   | 253 ++
 target/avr/gdbstub.c   |  85 ++
 target/avr/machine.c   | 121 +
 7 files changed, 1175 insertions(+)
 create mode 100644 gdb-xml/avr-cpu.xml
 create mode 100644 target/avr/cpu-param.h
 create mode 100644 target/avr/cpu-qom.h
 create mode 100644 target/avr/cpu.c
 create mode 100644 target/avr/cpu.h
 create mode 100644 target/avr/gdbstub.c
 create mode 100644 target/avr/machine.c

diff --git a/gdb-xml/avr-cpu.xml b/gdb-xml/avr-cpu.xml
new file mode 100644
index 00..c4747f5b40
--- /dev/null
+++ b/gdb-xml/avr-cpu.xml
@@ -0,0 +1,49 @@
+
+
+
+
+
+
+
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+
diff --git a/target/avr/cpu-param.h b/target/avr/cpu-param.h
new file mode 100644
index 00..ccd1ea3429
--- /dev/null
+++ b/target/avr/cpu-param.h
@@ -0,0 +1,37 @@
+/*
+ * QEMU AVR CPU
+ *
+ * Copyright (c) 2019 Michael Rolnik
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * 
+ */
+
+#ifndef AVR_CPU_PARAM_H
+#define AVR_CPU_PARAM_H 1
+
+#define TARGET_LONG_BITS 32
+/*
+ * TARGET_PAGE_BITS cannot be more than 8 bits because
+ * 1.  all IO registers occupy [0x .. 0x00ff] address range, and they
+ * should be implemented as a device and not memory
+ * 2.  SRAM starts at the address 0x0100
+ */
+#define TARGET_PAGE_BITS 8
+#define TARGET_PHYS_ADDR_SPACE_BITS 24
+#define TARGET_VIRT_ADDR_SPACE_BITS 24
+#define NB_MMU_MODES 2
+
+
+#endif
diff --git a/target/avr/cpu-qom.h b/target/avr/cpu-qom.h
new file mode 100644
index 00..e28b58c897
--- /dev/null
+++ b/target/avr/cpu-qom.h
@@ -0,0 +1,54 @@
+/*
+ * QEMU AVR CPU
+ *
+ * Copyright (c) 2019 Michael Rolnik
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * 
+ */
+
+#ifndef QEMU_AVR_QOM_H
+#define QEMU_AVR_QOM_H
+
+#include "hw/core/cpu.h"
+
+#define TYPE_AVR_CPU "avr-cpu"
+
+#define AVR_CPU_CLASS(klass) \
+OBJECT_CLASS_CHECK(AVRCPUClass, (klass), TYPE_AVR_CPU)
+#define AVR_CPU(obj) \
+OBJECT_CHECK(AVRCPU, (obj), TYPE_AVR_CPU)
+#define AVR_CPU_GET_CLASS(obj) \
+OBJECT_GET_CLASS(AVRCPUClass, (obj), TYPE_AVR_CPU)
+
+/**
+ *  AVRCPUClass:
+ *  @parent_realize: The parent class' realize handler.
+ *  @parent_reset: The parent class' reset handler.
+ *  @vr: Version Register value.
+ *
+ *  A AVR CPU model.
+ */
+typedef struct AVRCPUClass {
+/*< private >*/
+CPUClass parent_class;
+/*< public >*/
+DeviceRealize parent_realize;
+void (*parent_reset)(CPUState *cpu);
+} AVRCPUClass;
+
+typedef struct AVRCPU AVRCPU;
+
+
+#endif /* !defined (QEMU_AVR_CPU_QOM_H) */
diff --git a/target/avr/cpu.c b/target/avr/cpu.c
new file mode 100644
index 00..dae56d7845
--- /dev/null
+++ b/target/avr/cpu.c
@@ -0,0 +1,576 @@
+/*
+ * QEMU AVR CPU
+ *
+ * Copyright (c) 2019 Michael Rolnik
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; 

[PATCH v35 09/13] target/avr: Add instruction translation - CPU main translation function

2019-10-29 Thread Michael Rolnik
Co-developed-by: Richard Henderson 
Co-developed-by: Michael Rolnik 

Signed-off-by: Michael Rolnik 
---
 target/avr/translate.c | 234 +
 1 file changed, 234 insertions(+)

diff --git a/target/avr/translate.c b/target/avr/translate.c
index 30ba13bdd7..fdf4e11f58 100644
--- a/target/avr/translate.c
+++ b/target/avr/translate.c
@@ -2792,3 +2792,237 @@ static bool trans_WDR(DisasContext *ctx, arg_WDR *a)
 
 return true;
 }
+
+
+void avr_cpu_tcg_init(void)
+{
+int i;
+
+#define AVR_REG_OFFS(x) offsetof(CPUAVRState, x)
+cpu_pc = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(pc_w), "pc");
+cpu_Cf = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(sregC), "Cf");
+cpu_Zf = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(sregZ), "Zf");
+cpu_Nf = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(sregN), "Nf");
+cpu_Vf = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(sregV), "Vf");
+cpu_Sf = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(sregS), "Sf");
+cpu_Hf = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(sregH), "Hf");
+cpu_Tf = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(sregT), "Tf");
+cpu_If = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(sregI), "If");
+cpu_rampD = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(rampD), "rampD");
+cpu_rampX = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(rampX), "rampX");
+cpu_rampY = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(rampY), "rampY");
+cpu_rampZ = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(rampZ), "rampZ");
+cpu_eind = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(eind), "eind");
+cpu_sp = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(sp), "sp");
+cpu_skip = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(skip), "skip");
+
+for (i = 0; i < NO_CPU_REGISTERS; i++) {
+cpu_r[i] = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(r[i]),
+  reg_names[i]);
+}
+#undef AVR_REG_OFFS
+}
+
+static void translate(DisasContext *ctx)
+{
+uint32_t opcode = next_word(ctx);
+
+if (!decode_insn(ctx, opcode)) {
+gen_helper_unsupported(cpu_env);
+ctx->bstate = DISAS_NORETURN;
+}
+}
+
+/* Standardize the cpu_skip condition to NE.  */
+static bool canonicalize_skip(DisasContext *ctx)
+{
+switch (ctx->skip_cond) {
+case TCG_COND_NEVER:
+/* Normal case: cpu_skip is known to be false.  */
+return false;
+
+case TCG_COND_ALWAYS:
+/*
+ * Breakpoint case: cpu_skip is known to be true, via TB_FLAGS_SKIP.
+ * The breakpoint is on the instruction being skipped, at the start
+ * of the TranslationBlock.  No need to update.
+ */
+return false;
+
+case TCG_COND_NE:
+if (ctx->skip_var1 == NULL) {
+tcg_gen_mov_tl(cpu_skip, ctx->skip_var0);
+} else {
+tcg_gen_xor_tl(cpu_skip, ctx->skip_var0, ctx->skip_var1);
+ctx->skip_var1 = NULL;
+}
+break;
+
+default:
+/* Convert to a NE condition vs 0. */
+if (ctx->skip_var1 == NULL) {
+tcg_gen_setcondi_tl(ctx->skip_cond, cpu_skip, ctx->skip_var0, 0);
+} else {
+tcg_gen_setcond_tl(ctx->skip_cond, cpu_skip,
+   ctx->skip_var0, ctx->skip_var1);
+ctx->skip_var1 = NULL;
+}
+ctx->skip_cond = TCG_COND_NE;
+break;
+}
+if (ctx->free_skip_var0) {
+tcg_temp_free(ctx->skip_var0);
+ctx->free_skip_var0 = false;
+}
+ctx->skip_var0 = cpu_skip;
+return true;
+}
+
+void gen_intermediate_code(CPUState *cs, TranslationBlock *tb, int max_insns)
+{
+CPUAVRState *env = cs->env_ptr;
+DisasContext ctx = {
+.tb = tb,
+.cs = cs,
+.env = env,
+.memidx = 0,
+.bstate = DISAS_NEXT,
+.skip_cond = TCG_COND_NEVER,
+.singlestep = cs->singlestep_enabled,
+};
+target_ulong pc_start = tb->pc / 2;
+int num_insns = 0;
+
+if (tb->flags & TB_FLAGS_FULL_ACCESS) {
+/*
+ * This flag is set by ST/LD instruction we will regenerate it ONLY
+ * with mem/cpu memory access instead of mem access
+ */
+max_insns = 1;
+}
+if (ctx.singlestep) {
+max_insns = 1;
+}
+
+gen_tb_start(tb);
+
+ctx.npc = pc_start;
+if (tb->flags & TB_FLAGS_SKIP) {
+ctx.skip_cond = TCG_COND_ALWAYS;
+ctx.skip_var0 = cpu_skip;
+}
+
+do {
+TCGLabel *skip_label = NULL;
+
+/* translate current instruction */
+tcg_gen_insn_start(ctx.npc);
+num_insns++;
+
+/*
+ * this is due to some strange GDB behavior
+ * let's assume main has address 0x100
+ * b main   - sets breakpoint at address 0x0100 (code)
+ * b *0x100 - sets breakpoint at address 0x00800100 (data)
+ */
+if (unlikely(!ctx.singlestep &&
+

[PATCH v35 06/13] target/avr: Add instruction translation - Branch Instructions

2019-10-29 Thread Michael Rolnik
This includes:
- RJMP, IJMP, EIJMP, JMP
- RCALL, ICALL, EICALL, CALL
- RET, RETI
- CPSE, CP, CPC, CPI
- SBRC, SBRS, SBIC, SBIS
- BRBC, BRBS

Signed-off-by: Michael Rolnik 
---
 target/avr/translate.c | 549 -
 1 file changed, 546 insertions(+), 3 deletions(-)

diff --git a/target/avr/translate.c b/target/avr/translate.c
index 573c9988b5..4ef3294a40 100644
--- a/target/avr/translate.c
+++ b/target/avr/translate.c
@@ -224,6 +224,86 @@ static void gen_ZNSf(TCGv R)
 }
 
 
+static void gen_push_ret(DisasContext *ctx, int ret)
+{
+if (avr_feature(ctx->env, AVR_FEATURE_1_BYTE_PC)) {
+
+TCGv t0 = tcg_const_i32((ret & 0xff));
+
+tcg_gen_qemu_st_tl(t0, cpu_sp, MMU_DATA_IDX, MO_UB);
+tcg_gen_subi_tl(cpu_sp, cpu_sp, 1);
+
+tcg_temp_free_i32(t0);
+} else if (avr_feature(ctx->env, AVR_FEATURE_2_BYTE_PC)) {
+
+TCGv t0 = tcg_const_i32((ret & 0x00));
+
+tcg_gen_subi_tl(cpu_sp, cpu_sp, 1);
+tcg_gen_qemu_st_tl(t0, cpu_sp, MMU_DATA_IDX, MO_BEUW);
+tcg_gen_subi_tl(cpu_sp, cpu_sp, 1);
+
+tcg_temp_free_i32(t0);
+
+} else if (avr_feature(ctx->env, AVR_FEATURE_3_BYTE_PC)) {
+
+TCGv lo = tcg_const_i32((ret & 0xff));
+TCGv hi = tcg_const_i32((ret & 0x00) >> 8);
+
+tcg_gen_qemu_st_tl(lo, cpu_sp, MMU_DATA_IDX, MO_UB);
+tcg_gen_subi_tl(cpu_sp, cpu_sp, 2);
+tcg_gen_qemu_st_tl(hi, cpu_sp, MMU_DATA_IDX, MO_BEUW);
+tcg_gen_subi_tl(cpu_sp, cpu_sp, 1);
+
+tcg_temp_free_i32(lo);
+tcg_temp_free_i32(hi);
+}
+}
+
+
+static void gen_pop_ret(DisasContext *ctx, TCGv ret)
+{
+if (avr_feature(ctx->env, AVR_FEATURE_1_BYTE_PC)) {
+tcg_gen_addi_tl(cpu_sp, cpu_sp, 1);
+tcg_gen_qemu_ld_tl(ret, cpu_sp, MMU_DATA_IDX, MO_UB);
+} else if (avr_feature(ctx->env, AVR_FEATURE_2_BYTE_PC)) {
+tcg_gen_addi_tl(cpu_sp, cpu_sp, 1);
+tcg_gen_qemu_ld_tl(ret, cpu_sp, MMU_DATA_IDX, MO_BEUW);
+tcg_gen_addi_tl(cpu_sp, cpu_sp, 1);
+} else if (avr_feature(ctx->env, AVR_FEATURE_3_BYTE_PC)) {
+TCGv lo = tcg_temp_new_i32();
+TCGv hi = tcg_temp_new_i32();
+
+tcg_gen_addi_tl(cpu_sp, cpu_sp, 1);
+tcg_gen_qemu_ld_tl(hi, cpu_sp, MMU_DATA_IDX, MO_BEUW);
+
+tcg_gen_addi_tl(cpu_sp, cpu_sp, 2);
+tcg_gen_qemu_ld_tl(lo, cpu_sp, MMU_DATA_IDX, MO_UB);
+
+tcg_gen_deposit_tl(ret, lo, hi, 8, 16);
+
+tcg_temp_free_i32(lo);
+tcg_temp_free_i32(hi);
+}
+}
+
+
+static void gen_goto_tb(DisasContext *ctx, int n, target_ulong dest)
+{
+TranslationBlock *tb = ctx->tb;
+
+if (ctx->singlestep == 0) {
+tcg_gen_goto_tb(n);
+tcg_gen_movi_i32(cpu_pc, dest);
+tcg_gen_exit_tb(tb, n);
+} else {
+tcg_gen_movi_i32(cpu_pc, dest);
+gen_helper_debug(cpu_env);
+tcg_gen_exit_tb(NULL, 0);
+}
+ctx->bstate = DISAS_NORETURN;
+}
+
+
 /*
  *  Adds two registers without the C Flag and places the result in the
  *  destination register Rd.
@@ -797,13 +877,14 @@ static bool trans_MULSU(DisasContext *ctx, arg_MULSU *a)
 TCGv t0 = tcg_temp_new_i32();
 
 tcg_gen_ext8s_tl(t0, Rd); /* make Rd full 32 bit signed */
-tcg_gen_mul_tl(R, t0, Rr); /* R = Rd *Rr */
+tcg_gen_mul_tl(R, t0, Rr); /* R = Rd * Rr */
+tcg_gen_andi_tl(R, R, 0x); /* make R 16 bits */
 
 tcg_gen_andi_tl(R0, R, 0xff);
 tcg_gen_shri_tl(R1, R, 8);
 
-tcg_gen_shri_tl(cpu_Cf, R, 16); /* Cf = R(16) */
-tcg_gen_mov_tl(cpu_Zf, R);
+tcg_gen_shri_tl(cpu_Cf, R, 15); /* Cf = R(15) */
+tcg_gen_setcondi_tl(TCG_COND_EQ, cpu_Zf, R, 0); /* Zf = R == 0 */
 
 tcg_temp_free_i32(t0);
 tcg_temp_free_i32(R);
@@ -952,3 +1033,465 @@ static bool trans_DES(DisasContext *ctx, arg_DES *a)
 
 return true;
 }
+
+
+/*
+ *  Relative jump to an address within PC - 2K +1 and PC + 2K (words). For
+ *  AVR microcontrollers with Program memory not exceeding 4K words (8KB) this
+ *  instruction can address the entire memory from every address location. See
+ *  also JMP.
+ */
+static bool trans_RJMP(DisasContext *ctx, arg_RJMP *a)
+{
+int dst = ctx->npc + a->imm;
+
+gen_goto_tb(ctx, 0, dst);
+
+return true;
+}
+
+
+/*
+ *  Indirect jump to the address pointed to by the Z (16 bits) Pointer
+ *  Register in the Register File. The Z-pointer Register is 16 bits wide and
+ *  allows jump within the lowest 64K words (128KB) section of Program memory.
+ *  This instruction is not available in all devices. Refer to the device
+ *  specific instruction set summary.
+ */
+static bool trans_IJMP(DisasContext *ctx, arg_IJMP *a)
+{
+if (!avr_have_feature(ctx, AVR_FEATURE_IJMP_ICALL)) {
+return true;
+}
+
+gen_jmp_z(ctx);
+
+return true;
+}
+
+
+/*
+ *  Indirect jump to the address pointed to by the Z (16 bits) Pointer
+ *  Register in the Register File and the EIND Register in the I/O space. This
+ *  

[PATCH v35 08/13] target/avr: Add instruction translation - MCU Control Instructions

2019-10-29 Thread Michael Rolnik
This includes:
- BREAK
- NOP
- SLEEP
- WDR

Signed-off-by: Michael Rolnik 
---
 target/avr/translate.c | 174 +
 1 file changed, 174 insertions(+)

diff --git a/target/avr/translate.c b/target/avr/translate.c
index f2ec2e2d2f..30ba13bdd7 100644
--- a/target/avr/translate.c
+++ b/target/avr/translate.c
@@ -368,6 +368,115 @@ static bool trans_ADC(DisasContext *ctx, arg_ADC *a)
 }
 
 
+static void gen_jmp_ez(DisasContext *ctx)
+{
+tcg_gen_deposit_tl(cpu_pc, cpu_r[30], cpu_r[31], 8, 8);
+tcg_gen_or_tl(cpu_pc, cpu_pc, cpu_eind);
+ctx->bstate = DISAS_LOOKUP;
+}
+
+
+static void gen_jmp_z(DisasContext *ctx)
+{
+tcg_gen_deposit_tl(cpu_pc, cpu_r[30], cpu_r[31], 8, 8);
+ctx->bstate = DISAS_LOOKUP;
+}
+
+
+/*
+ *  in the gen_set_addr & gen_get_addr functions
+ *  H assumed to be in 0x00ff format
+ *  M assumed to be in 0x00ff format
+ *  L assumed to be in 0x00ff format
+ */
+static void gen_set_addr(TCGv addr, TCGv H, TCGv M, TCGv L)
+{
+
+tcg_gen_andi_tl(L, addr, 0x00ff);
+
+tcg_gen_andi_tl(M, addr, 0xff00);
+tcg_gen_shri_tl(M, M, 8);
+
+tcg_gen_andi_tl(H, addr, 0x00ff);
+}
+
+
+static void gen_set_xaddr(TCGv addr)
+{
+gen_set_addr(addr, cpu_rampX, cpu_r[27], cpu_r[26]);
+}
+
+
+static void gen_set_yaddr(TCGv addr)
+{
+gen_set_addr(addr, cpu_rampY, cpu_r[29], cpu_r[28]);
+}
+
+
+static void gen_set_zaddr(TCGv addr)
+{
+gen_set_addr(addr, cpu_rampZ, cpu_r[31], cpu_r[30]);
+}
+
+
+static TCGv gen_get_addr(TCGv H, TCGv M, TCGv L)
+{
+TCGv addr = tcg_temp_new_i32();
+
+tcg_gen_deposit_tl(addr, M, H, 8, 8);
+tcg_gen_deposit_tl(addr, L, addr, 8, 16);
+
+return addr;
+}
+
+
+static TCGv gen_get_xaddr(void)
+{
+return gen_get_addr(cpu_rampX, cpu_r[27], cpu_r[26]);
+}
+
+
+static TCGv gen_get_yaddr(void)
+{
+return gen_get_addr(cpu_rampY, cpu_r[29], cpu_r[28]);
+}
+
+
+static TCGv gen_get_zaddr(void)
+{
+return gen_get_addr(cpu_rampZ, cpu_r[31], cpu_r[30]);
+}
+
+
+/*
+ *  Load one byte indirect from data space to register and stores an clear
+ *  the bits in data space specified by the register. The instruction can only
+ *  be used towards internal SRAM.  The data location is pointed to by the Z 
(16
+ *  bits) Pointer Register in the Register File. Memory access is limited to 
the
+ *  current data segment of 64KB. To access another data segment in devices 
with
+ *  more than 64KB data space, the RAMPZ in register in the I/O area has to be
+ *  changed.  The Z-pointer Register is left unchanged by the operation. This
+ *  instruction is especially suited for clearing status bits stored in SRAM.
+ */
+static void gen_data_store(DisasContext *ctx, TCGv data, TCGv addr)
+{
+if (ctx->tb->flags & TB_FLAGS_FULL_ACCESS) {
+gen_helper_fullwr(cpu_env, data, addr);
+} else {
+tcg_gen_qemu_st8(data, addr, MMU_DATA_IDX); /* mem[addr] = data */
+}
+}
+
+static void gen_data_load(DisasContext *ctx, TCGv data, TCGv addr)
+{
+if (ctx->tb->flags & TB_FLAGS_FULL_ACCESS) {
+gen_helper_fullrd(data, cpu_env, addr);
+} else {
+tcg_gen_qemu_ld8u(data, addr, MMU_DATA_IDX); /* data = mem[addr] */
+}
+}
+
+
 /*
  *  Subtracts an immediate value (0-63) from a register pair and places the
  *  result in the register pair. This instruction operates on the upper four
@@ -2618,3 +2727,68 @@ static bool trans_BCLR(DisasContext *ctx, arg_BCLR *a)
 
 return true;
 }
+
+
+/*
+ *  The BREAK instruction is used by the On-chip Debug system, and is
+ *  normally not used in the application software. When the BREAK instruction 
is
+ *  executed, the AVR CPU is set in the Stopped Mode. This gives the On-chip
+ *  Debugger access to internal resources.  If any Lock bits are set, or either
+ *  the JTAGEN or OCDEN Fuses are unprogrammed, the CPU will treat the BREAK
+ *  instruction as a NOP and will not enter the Stopped mode.  This instruction
+ *  is not available in all devices. Refer to the device specific instruction
+ *  set summary.
+ */
+static bool trans_BREAK(DisasContext *ctx, arg_BREAK *a)
+{
+if (!avr_have_feature(ctx, AVR_FEATURE_BREAK)) {
+return true;
+}
+
+#ifdef BREAKPOINT_ON_BREAK
+tcg_gen_movi_tl(cpu_pc, ctx->npc - 1);
+gen_helper_debug(cpu_env);
+ctx->bstate = DISAS_EXIT;
+#else
+/* NOP */
+#endif
+
+return true;
+}
+
+
+/*
+ *  This instruction performs a single cycle No Operation.
+ */
+static bool trans_NOP(DisasContext *ctx, arg_NOP *a)
+{
+
+/* NOP */
+
+return true;
+}
+
+
+/*
+ *  This instruction sets the circuit in sleep mode defined by the MCU
+ *  Control Register.
+ */
+static bool trans_SLEEP(DisasContext *ctx, arg_SLEEP *a)
+{
+gen_helper_sleep(cpu_env);
+ctx->bstate = DISAS_NORETURN;
+return true;
+}
+
+
+/*
+ *  This instruction resets the Watchdog Timer. This instruction must be
+ *  executed within a limited time given by the WD prescaler. See the Watchdog

[PATCH v35 00/13] QEMU AVR 8 bit cores

2019-10-29 Thread Michael Rolnik
This series of patches adds 8bit AVR cores to QEMU.
All instruction, except BREAK/DES/SPM/SPMX, are implemented. Not fully tested 
yet.
However I was able to execute simple code with functions. e.g fibonacci 
calculation.
This series of patches include a non real, sample board.
No fuses support yet. PC is set to 0 at reset.

the patches include the following
1. just a basic 8bit AVR CPU, without instruction decoding or translation
2. CPU features which allow define the following 8bit AVR cores
 avr1
 avr2 avr25
 avr3 avr31 avr35
 avr4
 avr5 avr51
 avr6
 xmega2 xmega4 xmega5 xmega6 xmega7
3. a definition of sample machine with SRAM, FLASH and CPU which allows to 
execute simple code
4. encoding for all AVR instructions
5. interrupt handling
6. helpers for IN, OUT, SLEEP, WBR & unsupported instructions
7. a decoder which given an opcode decides what istruction it is
8. translation of AVR instruction into TCG
9. all features together

changes since v3
1. rampD/X/Y/Z registers are encoded as 0x00ff (instead of 0x00ff) for 
faster address manipulaton
2. ffs changed to ctz32
3. duplicate code removed at avr_cpu_do_interrupt
4. using andc instead of not + and
5. fixing V flag calculation in varios instructions
6. freeing local variables in PUSH
7. tcg_const_local_i32 -> tcg_const_i32
8. using sextract32 instead of my implementation
9. fixing BLD instruction
10.xor(r) instead of 0xff - r at COM
11.fixing MULS/MULSU not to modify inputs' content
12.using SUB for NEG
13.fixing tcg_gen_qemu_ld/st call in XCH

changes since v4
1. target is now defined as big endian in order to optimize push_ret/pop_ret
2. all style warnings are fixed
3. adding cpu_set/get_sreg functions
4. simplifying gen_goto_tb as there is no real paging
5. env->pc -> env->pc_w
6. making flag dump more compact
7. more spacing
8. renaming CODE/DATA_INDEX -> MMU_CODE/DATA_IDX
9. removing avr_set_feature
10. SPL/SPH set bug fix
11. switching stb_phys to cpu_stb_data
12. cleaning up avr_decode
13. saving sreg, rampD/X/Y/Z, eind in HW format (savevm)
14. saving CPU features (savevm)

changes since v5
1. BLD bug fix
2. decoder generator is added

chages since v6
1. using cpu_get_sreg/cpu_set_sreg in 
avr_cpu_gdb_read_register/avr_cpu_gdb_write_register
2. configure the target as little endian because otherwise GDB does not work
3. fixing and testing gen_push_ret/gen_pop_ret

changes since v7
1. folding back v6
2. logging at helper_outb and helper_inb are done for non supported yet 
registers only
3. MAINTAINERS updated

changes since v8
1. removing hw/avr from hw/Makefile.obj as it should not be built for all
2. making linux compilable
3. testing on
a. Mac, Apple LLVM version 7.0.0
b. Ubuntu 12.04, gcc 4.9.2
c. Fedora 23, gcc 5.3.1
4. folding back some patches
5. translation bug fixes for ORI, CPI, XOR instructions
6. propper handling of cpu register writes though memory

changes since v9
1. removing forward declarations of static functions
2. disabling debug prints
3. switching to case range instead of if else if ...
4. LD/ST IN/OUT accessing CPU maintainder registers are not routed to any device
5. commenst about sample board and sample IO device added
6. sample board description is more descriptive now
7. memory_region_allocate_system_memory is used to create RAM
8. now there are helper_fullrd & helper_fullwr when LD/ST try to access 
registers

changes since v10
1. movig back fullwr & fullrd into the commit where outb and inb were introduced
2. changing tlb_fill function signature
3. adding empty line between functions
4. adding newline on the last line of the file
5. using tb->flags to generae full access ST/LD instructions
6. fixing SBRC bug
7. folding back 10th commit
8. whenever a new file is introduced it's added to Makefile.objs

changes since v11
1. updating to v2.7.0-rc
2. removing assignment to env->fullacc from gen_intermediate_code

changes since v12
1. fixing spacing
2. fixing get/put_segment functions
3. removing target-avr/machine.h file
4. VMSTATE_SINGLE_TEST -> VMSTATE_SINGLE
5. comment spelling
6. removing hw/avr/sample_io.c
7. char const* -> const char*
8. proper ram allocation
9. fixing breakpoint functionality.
10.env1 -> env
11.fixing avr_cpu_gdb_write_register & avr_cpu_gdb_read_register functions
12.any cpu is removed
12.feature bits are not saved into vm state

changes since v13
1. rebasing to v2.7.0-rc1

changes since v14
1. I made self review with git gui tool. (I did not know such a thing exists)
2. removing all double/tripple spaces
3. removing comment reference to SampleIO
4. folding back some changes, so there is not deleted lines in my code
5. moving avr configuration, within configure file, before chris

changes since v15
1. removing IO registers cache from CPU
2. implementing CBI/SBI as read(helper_inb), modify, write(helper_outb)
3. implementing CBIC/SBIC as read(helper_inb), check, branch
4. adding missing tcg_temp_free_i32 for tcg_const_i32

changes since v16
1. 

[PATCH v35 02/13] target/avr: Add instruction helpers

2019-10-29 Thread Michael Rolnik
Stubs for unimplemented instructions and helpers for instructions that need to 
interact with QEMU.
SPM and WDR are unimplemented because they require emulation of complex 
peripherals.
The implementation of SLEEP is very limited due to the lack of peripherals to 
generate wake interrupts.
Memory access instructions are implemented here because some address ranges 
actually refer to CPU registers.

Signed-off-by: Michael Rolnik 
---
 target/avr/helper.c | 354 
 target/avr/helper.h |  29 
 2 files changed, 383 insertions(+)
 create mode 100644 target/avr/helper.c
 create mode 100644 target/avr/helper.h

diff --git a/target/avr/helper.c b/target/avr/helper.c
new file mode 100644
index 00..f0f0d4f15a
--- /dev/null
+++ b/target/avr/helper.c
@@ -0,0 +1,354 @@
+/*
+ * QEMU AVR CPU
+ *
+ * Copyright (c) 2019 Michael Rolnik
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * 
+ */
+
+#include "qemu/osdep.h"
+
+#include "cpu.h"
+#include "hw/irq.h"
+#include "hw/sysbus.h"
+#include "sysemu/sysemu.h"
+#include "exec/exec-all.h"
+#include "exec/cpu_ldst.h"
+#include "exec/helper-proto.h"
+#include "exec/ioport.h"
+#include "qemu/host-utils.h"
+#include "qemu/error-report.h"
+
+bool avr_cpu_exec_interrupt(CPUState *cs, int interrupt_request)
+{
+bool ret = false;
+CPUClass *cc = CPU_GET_CLASS(cs);
+AVRCPU *cpu = AVR_CPU(cs);
+CPUAVRState *env = >env;
+
+if (interrupt_request & CPU_INTERRUPT_RESET) {
+if (cpu_interrupts_enabled(env)) {
+cs->exception_index = EXCP_RESET;
+cc->do_interrupt(cs);
+
+cs->interrupt_request &= ~CPU_INTERRUPT_RESET;
+
+ret = true;
+}
+}
+if (interrupt_request & CPU_INTERRUPT_HARD) {
+if (cpu_interrupts_enabled(env) && env->intsrc != 0) {
+int index = ctz32(env->intsrc);
+cs->exception_index = EXCP_INT(index);
+cc->do_interrupt(cs);
+
+env->intsrc &= env->intsrc - 1; /* clear the interrupt */
+cs->interrupt_request &= ~CPU_INTERRUPT_HARD;
+
+ret = true;
+}
+}
+return ret;
+}
+
+void avr_cpu_do_interrupt(CPUState *cs)
+{
+AVRCPU *cpu = AVR_CPU(cs);
+CPUAVRState *env = >env;
+
+uint32_t ret = env->pc_w;
+int vector = 0;
+int size = avr_feature(env, AVR_FEATURE_JMP_CALL) ? 2 : 1;
+int base = 0;
+
+if (cs->exception_index == EXCP_RESET) {
+vector = 0;
+} else if (env->intsrc != 0) {
+vector = ctz32(env->intsrc) + 1;
+}
+
+if (avr_feature(env, AVR_FEATURE_3_BYTE_PC)) {
+cpu_stb_data(env, env->sp--, (ret & 0xff));
+cpu_stb_data(env, env->sp--, (ret & 0x00ff00) >> 8);
+cpu_stb_data(env, env->sp--, (ret & 0xff) >> 16);
+} else if (avr_feature(env, AVR_FEATURE_2_BYTE_PC)) {
+cpu_stb_data(env, env->sp--, (ret & 0xff));
+cpu_stb_data(env, env->sp--, (ret & 0x00ff00) >> 8);
+} else {
+cpu_stb_data(env, env->sp--, (ret & 0xff));
+}
+
+env->pc_w = base + vector * size;
+env->sregI = 0; /* clear Global Interrupt Flag */
+
+cs->exception_index = -1;
+}
+
+int avr_cpu_memory_rw_debug(CPUState *cs, vaddr addr, uint8_t *buf,
+int len, bool is_write)
+{
+return cpu_memory_rw_debug(cs, addr, buf, len, is_write);
+}
+
+hwaddr avr_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
+{
+return addr; /* I assume 1:1 address correspondance */
+}
+
+int avr_cpu_handle_mmu_fault(
+CPUState *cs, vaddr address, int size, int rw, int mmu_idx)
+{
+/* currently it's assumed that this will never happen */
+cs->exception_index = EXCP_DEBUG;
+cpu_dump_state(cs, stderr, 0);
+return 1;
+}
+
+bool avr_cpu_tlb_fill(CPUState *cs, vaddr address, int size,
+MMUAccessType access_type, int mmu_idx,
+bool probe, uintptr_t retaddr)
+{
+int prot = 0;
+MemTxAttrs attrs = {};
+uint32_t paddr;
+
+address &= TARGET_PAGE_MASK;
+
+if (mmu_idx == MMU_CODE_IDX) {
+/* access to code in flash */
+paddr = OFFSET_CODE + address;
+prot = PAGE_READ | PAGE_EXEC;
+if (paddr + TARGET_PAGE_SIZE > OFFSET_DATA) {
+error_report("execution left flash memory");
+

[PATCH v35 04/13] target/avr: Add instruction translation - Registers definition

2019-10-29 Thread Michael Rolnik
Signed-off-by: Michael Rolnik 
---
 target/avr/translate.c | 132 +
 1 file changed, 132 insertions(+)
 create mode 100644 target/avr/translate.c

diff --git a/target/avr/translate.c b/target/avr/translate.c
new file mode 100644
index 00..53c9892a60
--- /dev/null
+++ b/target/avr/translate.c
@@ -0,0 +1,132 @@
+/*
+ * QEMU AVR CPU
+ *
+ * Copyright (c) 2019 Michael Rolnik
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * 
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/qemu-print.h"
+#include "tcg/tcg.h"
+#include "cpu.h"
+#include "exec/exec-all.h"
+#include "disas/disas.h"
+#include "tcg-op.h"
+#include "exec/cpu_ldst.h"
+#include "exec/helper-proto.h"
+#include "exec/helper-gen.h"
+#include "exec/log.h"
+#include "exec/gdbstub.h"
+#include "exec/translator.h"
+#include "exec/gen-icount.h"
+
+/*
+ *  Define if you want a BREAK instruction translated to a breakpoint
+ *  Active debugging connection is assumed
+ *  This is for
+ *  https://github.com/seharris/qemu-avr-tests/tree/master/instruction-tests
+ *  tests
+ */
+#undef BREAKPOINT_ON_BREAK
+
+static TCGv cpu_pc;
+
+static TCGv cpu_Cf;
+static TCGv cpu_Zf;
+static TCGv cpu_Nf;
+static TCGv cpu_Vf;
+static TCGv cpu_Sf;
+static TCGv cpu_Hf;
+static TCGv cpu_Tf;
+static TCGv cpu_If;
+
+static TCGv cpu_rampD;
+static TCGv cpu_rampX;
+static TCGv cpu_rampY;
+static TCGv cpu_rampZ;
+
+static TCGv cpu_r[NO_CPU_REGISTERS];
+static TCGv cpu_eind;
+static TCGv cpu_sp;
+
+static TCGv cpu_skip;
+
+static const char reg_names[NO_CPU_REGISTERS][8] = {
+"r0",  "r1",  "r2",  "r3",  "r4",  "r5",  "r6",  "r7",
+"r8",  "r9",  "r10", "r11", "r12", "r13", "r14", "r15",
+"r16", "r17", "r18", "r19", "r20", "r21", "r22", "r23",
+"r24", "r25", "r26", "r27", "r28", "r29", "r30", "r31",
+};
+#define REG(x) (cpu_r[x])
+
+enum {
+DISAS_EXIT   = DISAS_TARGET_0,  /* We want return to the cpu main loop.  */
+DISAS_LOOKUP = DISAS_TARGET_1,  /* We have a variable condition exit.  */
+DISAS_CHAIN  = DISAS_TARGET_2,  /* We have a single condition exit.  */
+};
+
+typedef struct DisasContext DisasContext;
+
+/* This is the state at translation time. */
+struct DisasContext {
+TranslationBlock *tb;
+
+CPUAVRState *env;
+CPUState *cs;
+
+target_long npc;
+uint32_t opcode;
+
+/* Routine used to access memory */
+int memidx;
+int bstate;
+int singlestep;
+
+TCGv skip_var0;
+TCGv skip_var1;
+TCGCond skip_cond;
+bool free_skip_var0;
+};
+
+static int to_A(DisasContext *ctx, int indx) { return 16 + (indx % 16); }
+static int to_B(DisasContext *ctx, int indx) { return 16 + (indx % 8); }
+static int to_C(DisasContext *ctx, int indx) { return 24 + (indx % 4) * 2; }
+static int to_D(DisasContext *ctx, int indx) { return (indx % 16) * 2; }
+
+static uint16_t next_word(DisasContext *ctx)
+{
+return cpu_lduw_code(ctx->env, ctx->npc++ * 2);
+}
+
+static int append_16(DisasContext *ctx, int x)
+{
+return x << 16 | next_word(ctx);
+}
+
+
+static bool avr_have_feature(DisasContext *ctx, int feature)
+{
+if (!avr_feature(ctx->env, feature)) {
+gen_helper_unsupported(cpu_env);
+ctx->bstate = DISAS_NORETURN;
+return false;
+}
+return true;
+}
+
+static bool decode_insn(DisasContext *ctx, uint16_t insn);
+#include "decode_insn.inc.c"
+
-- 
2.17.2 (Apple Git-113)




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

2019-10-29 Thread Michael Rolnik
This includes:
- ADD, ADC, ADIW
- SBIW, SUB, SUBI, SBC, SBCI
- AND, ANDI
- OR, ORI, EOR
- COM, NEG
- INC, DEC
- MUL, MULS, MULSU
- FMUL, FMULS, FMULSU
- DES

Signed-off-by: Michael Rolnik 
---
 target/avr/translate.c | 822 +
 1 file changed, 822 insertions(+)

diff --git a/target/avr/translate.c b/target/avr/translate.c
index 53c9892a60..573c9988b5 100644
--- a/target/avr/translate.c
+++ b/target/avr/translate.c
@@ -130,3 +130,825 @@ static bool avr_have_feature(DisasContext *ctx, int 
feature)
 static bool decode_insn(DisasContext *ctx, uint16_t insn);
 #include "decode_insn.inc.c"
 
+
+static void gen_add_CHf(TCGv R, TCGv Rd, TCGv Rr)
+{
+TCGv t1 = tcg_temp_new_i32();
+TCGv t2 = tcg_temp_new_i32();
+TCGv t3 = tcg_temp_new_i32();
+
+tcg_gen_and_tl(t1, Rd, Rr); /* t1 = Rd & Rr */
+tcg_gen_andc_tl(t2, Rd, R); /* t2 = Rd & ~R */
+tcg_gen_andc_tl(t3, Rr, R); /* t3 = Rr & ~R */
+tcg_gen_or_tl(t1, t1, t2); /* t1 = t1 | t2 | t3 */
+tcg_gen_or_tl(t1, t1, t3);
+
+tcg_gen_shri_tl(cpu_Cf, t1, 7); /* Cf = t1(7) */
+tcg_gen_shri_tl(cpu_Hf, t1, 3); /* Hf = t1(3) */
+tcg_gen_andi_tl(cpu_Hf, cpu_Hf, 1);
+
+tcg_temp_free_i32(t3);
+tcg_temp_free_i32(t2);
+tcg_temp_free_i32(t1);
+}
+
+
+static void gen_add_Vf(TCGv R, TCGv Rd, TCGv Rr)
+{
+TCGv t1 = tcg_temp_new_i32();
+TCGv t2 = tcg_temp_new_i32();
+
+/* t1 = Rd & Rr & ~R | ~Rd & ~Rr & R = (Rd ^ R) & ~(Rd ^ Rr) */
+tcg_gen_xor_tl(t1, Rd, R);
+tcg_gen_xor_tl(t2, Rd, Rr);
+tcg_gen_andc_tl(t1, t1, t2);
+
+tcg_gen_shri_tl(cpu_Vf, t1, 7); /* Vf = t1(7) */
+
+tcg_temp_free_i32(t2);
+tcg_temp_free_i32(t1);
+}
+
+
+static void gen_sub_CHf(TCGv R, TCGv Rd, TCGv Rr)
+{
+TCGv t1 = tcg_temp_new_i32();
+TCGv t2 = tcg_temp_new_i32();
+TCGv t3 = tcg_temp_new_i32();
+
+/* Cf & Hf */
+tcg_gen_not_tl(t1, Rd); /* t1 = ~Rd */
+tcg_gen_and_tl(t2, t1, Rr); /* t2 = ~Rd & Rr */
+tcg_gen_or_tl(t3, t1, Rr); /* t3 = (~Rd | Rr) & R */
+tcg_gen_and_tl(t3, t3, R);
+tcg_gen_or_tl(t2, t2, t3); /* t2 = ~Rd & Rr | ~Rd & R | R & Rr */
+tcg_gen_shri_tl(cpu_Cf, t2, 7); /* Cf = t2(7) */
+tcg_gen_shri_tl(cpu_Hf, t2, 3); /* Hf = t2(3) */
+tcg_gen_andi_tl(cpu_Hf, cpu_Hf, 1);
+
+tcg_temp_free_i32(t3);
+tcg_temp_free_i32(t2);
+tcg_temp_free_i32(t1);
+}
+
+
+static void gen_sub_Vf(TCGv R, TCGv Rd, TCGv Rr)
+{
+TCGv t1 = tcg_temp_new_i32();
+TCGv t2 = tcg_temp_new_i32();
+
+/* Vf */
+/* t1 = Rd & ~Rr & ~R | ~Rd & Rr & R = (Rd ^ R) & (Rd ^ R) */
+tcg_gen_xor_tl(t1, Rd, R);
+tcg_gen_xor_tl(t2, Rd, Rr);
+tcg_gen_and_tl(t1, t1, t2);
+tcg_gen_shri_tl(cpu_Vf, t1, 7); /* Vf = t1(7) */
+
+tcg_temp_free_i32(t2);
+tcg_temp_free_i32(t1);
+}
+
+
+static void gen_NSf(TCGv R)
+{
+tcg_gen_shri_tl(cpu_Nf, R, 7); /* Nf = R(7) */
+tcg_gen_xor_tl(cpu_Sf, cpu_Nf, cpu_Vf); /* Sf = Nf ^ Vf */
+}
+
+
+static void gen_ZNSf(TCGv R)
+{
+tcg_gen_setcondi_tl(TCG_COND_EQ, cpu_Zf, R, 0); /* Zf = R == 0 */
+tcg_gen_shri_tl(cpu_Nf, R, 7); /* Nf = R(7) */
+tcg_gen_xor_tl(cpu_Sf, cpu_Nf, cpu_Vf); /* Sf = Nf ^ Vf */
+}
+
+
+/*
+ *  Adds two registers without the C Flag and places the result in the
+ *  destination register Rd.
+ */
+static bool trans_ADD(DisasContext *ctx, arg_ADD *a)
+{
+TCGv Rd = cpu_r[a->rd];
+TCGv Rr = cpu_r[a->rr];
+TCGv R = tcg_temp_new_i32();
+
+/* op */
+tcg_gen_add_tl(R, Rd, Rr); /* Rd = Rd + Rr */
+tcg_gen_andi_tl(R, R, 0xff); /* make it 8 bits */
+
+gen_add_CHf(R, Rd, Rr);
+gen_add_Vf(R, Rd, Rr);
+gen_ZNSf(R);
+
+/* R */
+tcg_gen_mov_tl(Rd, R);
+
+tcg_temp_free_i32(R);
+
+return true;
+}
+
+
+/*
+ *  Adds two registers and the contents of the C Flag and places the result in
+ *  the destination register Rd.
+ */
+static bool trans_ADC(DisasContext *ctx, arg_ADC *a)
+{
+TCGv Rd = cpu_r[a->rd];
+TCGv Rr = cpu_r[a->rr];
+TCGv R = tcg_temp_new_i32();
+
+/* op */
+tcg_gen_add_tl(R, Rd, Rr); /* R = Rd + Rr + Cf */
+tcg_gen_add_tl(R, R, cpu_Cf);
+tcg_gen_andi_tl(R, R, 0xff); /* make it 8 bits */
+
+gen_add_CHf(R, Rd, Rr);
+gen_add_Vf(R, Rd, Rr);
+gen_ZNSf(R);
+
+/* R */
+tcg_gen_mov_tl(Rd, R);
+
+tcg_temp_free_i32(R);
+
+return true;
+}
+
+
+/*
+ *  Subtracts an immediate value (0-63) from a register pair and places the
+ *  result in the register pair. This instruction operates on the upper four
+ *  register pairs, and is well suited for operations on the Pointer Registers.
+ *  This instruction is not available in all devices. Refer to the device
+ *  specific instruction set summary.
+ */
+static bool trans_SBIW(DisasContext *ctx, arg_SBIW *a)
+{
+if (!avr_have_feature(ctx, AVR_FEATURE_ADIW_SBIW)) {
+return true;
+}
+
+TCGv RdL = cpu_r[a->rd];
+TCGv RdH = cpu_r[a->rd + 1];
+int Imm = (a->imm);
+TCGv R = tcg_temp_new_i32();
+TCGv Rd = 

[PATCH v35 03/13] target/avr: Add instruction decoding

2019-10-29 Thread Michael Rolnik
This includes:
- encoding of all 16 bit instructions
- encoding of all 32 bit instructions

Signed-off-by: Michael Rolnik 
---
 target/avr/insn.decode | 175 +
 1 file changed, 175 insertions(+)
 create mode 100644 target/avr/insn.decode

diff --git a/target/avr/insn.decode b/target/avr/insn.decode
new file mode 100644
index 00..6b387762c6
--- /dev/null
+++ b/target/avr/insn.decode
@@ -0,0 +1,175 @@
+#
+#   A = [16 .. 31]
+#   B = [16 .. 23]
+#   C = [24, 26, 28, 30]
+#   D = [0, 2, 4, 6, 8, .. 30]
+
+%rd 4:5
+%rr 9:1 0:4
+
+_rr  rd rr
+_imm rd imm
+
+@op_rd_rr    .. . . _rr  rd=%rd rr=%rr
+ADD  11 . . @op_rd_rr
+ADC 0001 11 . . @op_rd_rr
+AND 0010 00 . . @op_rd_rr
+CP  0001 01 . . @op_rd_rr
+CPC  01 . . @op_rd_rr
+CPSE0001 00 . . @op_rd_rr
+EOR 0010 01 . . @op_rd_rr
+MOV 0010 11 . . @op_rd_rr
+MUL 1001 11 . . @op_rd_rr
+OR  0010 10 . . @op_rd_rr
+SBC  10 . . @op_rd_rr
+SUB 0001 10 . . @op_rd_rr
+
+
+%rd_c   4:2 !function=to_C
+%imm6   6:2 0:4
+
+@op_rd_imm6   .. .. _imm rd=%rd_c imm=%imm6
+ADIW1001 0110 .. .. @op_rd_imm6
+SBIW1001 0111 .. .. @op_rd_imm6
+
+
+%rd_a   4:4 !function=to_A
+%rr_a   0:4 !function=to_A
+%rd_d   4:4 !function=to_D
+%rr_d   0:4 !function=to_D
+%imm8   8:4 0:4
+
+@op_rd_imm8     _imm rd=%rd_a imm=%imm8
+ANDI0111    @op_rd_imm8
+CPI 0011    @op_rd_imm8
+LDI 1110    @op_rd_imm8
+ORI 0110    @op_rd_imm8
+SBCI0100    @op_rd_imm8
+SUBI0101    @op_rd_imm8
+
+
+@op_rd   ... rd:5 
+ASR 1001 010 . 0101 @op_rd
+COM 1001 010 .  @op_rd
+DEC 1001 010 . 1010 @op_rd
+ELPM2   1001 000 . 0110 @op_rd
+ELPMX   1001 000 . 0111 @op_rd
+INC 1001 010 . 0011 @op_rd
+LDX11001 000 . 1100 @op_rd
+LDX21001 000 . 1101 @op_rd
+LDX31001 000 . 1110 @op_rd
+LDY21001 000 . 1001 @op_rd
+LDY31001 000 . 1010 @op_rd
+LDZ21001 000 . 0001 @op_rd
+LDZ31001 000 . 0010 @op_rd
+LPM21001 000 . 0100 @op_rd
+LPMX1001 000 . 0101 @op_rd
+LSR 1001 010 . 0110 @op_rd
+NEG 1001 010 . 0001 @op_rd
+POP 1001 000 .  @op_rd
+PUSH1001 001 .  @op_rd
+ROR 1001 010 . 0111 @op_rd
+STY21001 001 . 1001 @op_rd
+STY31001 001 . 1010 @op_rd
+STZ21001 001 . 0001 @op_rd
+STZ31001 001 . 0010 @op_rd
+SWAP1001 010 . 0010 @op_rd
+
+
+@op_bit   . bit:3 
+BCLR1001 0100 1 ... 1000@op_bit
+BSET1001 0100 0 ... 1000@op_bit
+
+
+@op_rd_bit   ... rd:5 . bit:3
+BLD  100 . 0 ...@op_rd_bit
+BST  101 . 0 ...@op_rd_bit
+
+
+@op_bit_imm  .. imm:s7 bit:3
+BRBC 01 ... ... @op_bit_imm
+BRBS 00 ... ... @op_bit_imm
+
+
+BREAK   1001 0101 1001 1000
+EICALL  1001 0101 0001 1001
+EIJMP   1001 0100 0001 1001
+ELPM1   1001 0101 1101 1000
+ICALL   1001 0101  1001
+IJMP1001 0100  1001
+LPM11001 0101 1100 1000
+NOP    
+RET 1001 0101  1000
+RETI1001 0101 0001 1000
+SLEEP   1001 0101 1000 1000
+SPM 1001 0101 1110 1000
+SPMX1001 0101  1000
+WDR 1001 0101 1010 1000
+
+
+@op_reg_bit   reg:5 bit:3
+CBI 1001 1000 . ... @op_reg_bit
+SBI 1001 1010 . ... @op_reg_bit
+SBIC1001 1001 . ... @op_reg_bit
+SBIS1001 1011 . ... @op_reg_bit
+
+
+DES 1001 0100 imm:4 1011
+
+
+%rd_b   4:3   

Re: [PULL 0/16] Python (acceptance tests) queue, 2019-10-28

2019-10-29 Thread Peter Maydell
On Mon, 28 Oct 2019 at 23:50, Cleber Rosa  wrote:
>
> The following changes since commit aaffb853359829a37daaf883c773e8320b55c723:
>
>   Merge remote-tracking branch 'remotes/maxreitz/tags/pull-block-2019-10-28' 
> into staging (2019-10-28 14:40:01 +)
>
> are available in the Git repository at:
>
>   git://github.com/clebergnu/qemu.git tags/python-next-pull-request
>
> for you to fetch changes up to efdb45bfd72745038909dfd1e970a827cb8d5d7e:
>
>   tests/boot_linux_console: Run BusyBox on 5KEc 64-bit cpu (2019-10-28 
> 19:04:04 -0400)
>
> 

Hi; unless my scripts are driving gpg wrong, this seems to
have been signed with an expired gpg key:

gpg: Signature made Mon 28 Oct 2019 23:43:11 GMT
gpg:using RSA key 7ABB96EB8B46B94D5E0FE9BB657E8D33A5F209F3
gpg: Good signature from "Cleber Rosa " [expired]
gpg: Note: This key has expired!
Primary key fingerprint: 7ABB 96EB 8B46 B94D 5E0F  E9BB 657E 8D33 A5F2 09F3


thanks
-- PMM



Re: [PULL 00/19] QAPI patches for 2019-10-29

2019-10-29 Thread Peter Maydell
On Tue, 29 Oct 2019 at 10:24, Markus Armbruster  wrote:
>
> The following changes since commit aaffb853359829a37daaf883c773e8320b55c723:
>
>   Merge remote-tracking branch 'remotes/maxreitz/tags/pull-block-2019-10-28' 
> into staging (2019-10-28 14:40:01 +)
>
> are available in the Git repository at:
>
>   git://repo.or.cz/qemu/armbru.git tags/pull-qapi-2019-10-29
>
> for you to fetch changes up to e151941d1b691402f7914750e025209b7839a1c0:
>
>   qapi: Check feature documentation against the schema (2019-10-29 07:35:16 
> +0100)
>
> 
> QAPI patches for 2019-10-29
>

Applied, thanks.

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

-- PMM



Re: [PULL V2 0/4] Net patches

2019-10-29 Thread Peter Maydell
On Tue, 29 Oct 2019 at 02:37, Jason Wang  wrote:
>
> The following changes since commit 187f35512106501fe9a11057f4d8705431e0026d:
>
>   Merge remote-tracking branch 
> 'remotes/stsquad/tags/pull-testing-next-251019-3' into staging (2019-10-26 
> 10:13:48 +0100)
>
> are available in the git repository at:
>
>   https://github.com/jasowang/qemu.git tags/net-pull-request
>
> for you to fetch changes up to 1e907a32b77e5d418538453df5945242e43224fa:
>
>   COLO-compare: Fix incorrect `if` logic (2019-10-29 10:28:07 +0800)
>
> 
>
> Changes from V1:
>
> - Fix compling issue
>
> 

Applied, thanks.

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

-- PMM



Re: [PATCH] fdc: support READ command with VERIFY DMA mode

2019-10-29 Thread Hervé Poussineau

Le 29/10/2019 à 12:00, John Snow a écrit :
>
>
> On 10/20/19 2:38 AM, Sven Schnelle wrote:
>> While working on the Tulip driver i tried to write some Teledisk images to
>> a floppy image which didn't work. Turned out that Teledisk checks the written
>> data by issuing a READ command to the FDC but running the DMA controller
>> in VERIFY mode. As we ignored the DMA request in that case, the DMA transfer
>> never finished, and Teledisk reported an error.
>>
>
> CC hpous...@reactos.org, who sometimes submits patches here too.
>
>> Signed-off-by: Sven Schnelle 
>> ---
>>   hw/block/fdc.c | 10 +++---
>>   1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/hw/block/fdc.c b/hw/block/fdc.c
>> index ac5d31e8c1..8a1228df78 100644
>> --- a/hw/block/fdc.c
>> +++ b/hw/block/fdc.c
>> @@ -1733,7 +1733,8 @@ static void fdctrl_start_transfer(FDCtrl *fdctrl, int 
direction)
>>   dma_mode_ok = (dma_mode == ISADMA_TRANSFER_WRITE);
>>   break;
>>   case FD_DIR_READ:
>> -dma_mode_ok = (dma_mode == ISADMA_TRANSFER_READ);
>> +dma_mode_ok = (dma_mode == ISADMA_TRANSFER_READ) ||
>> +  (dma_mode == ISADMA_TRANSFER_VERIFY);
>
> So we're enabling DMA when the command is an FD_DIR_READ command and the
> dma_mode is VERIFY. Those read commands are:
>
> READ
> READ TRACK
> READ DELETED DATA

OK for this part. However, in an ideal emulation world, the floppy drive 
controller shouldn't know
what is the current DMA mode.
I would remove this whole dma_mode_ok thing, and always assume that operating 
system does a sane thing.
Then, get_transfer_mode() callback and the ISADMA_TRANSFER_* defines can also 
be removed.

>
>>   break;
>>   case FD_DIR_VERIFY:
>>   dma_mode_ok = true;
>> @@ -1835,8 +1836,11 @@ static int fdctrl_transfer_handler (void *opaque, int 
nchan,
>>   switch (fdctrl->data_dir) {
>>   case FD_DIR_READ:
>>   /* READ commands */
>> -k->write_memory(fdctrl->dma, nchan, fdctrl->fifo + rel_pos,
>> -fdctrl->data_pos, len);
>> +if (k->get_transfer_mode(fdctrl->dma, fdctrl->dma_chann) !=
>> +ISADMA_TRANSFER_VERIFY) {
>> +k->write_memory(fdctrl->dma, nchan, fdctrl->fifo + rel_pos,
>> +fdctrl->data_pos, len);
>> +}
>
> Would it horrify you to know I don't know how the VERIFY mode should
> work? It's always nice when you google i8257 to look for information and
> the top page of results are all QEMU patches.
>
> The i8257 spec says this:
>
> (3) DMA verify, which does not actually involve the
> transfer of data. When an 8257 channel is in the DMA verify
> mode, it will respond the same as described for transfer
> operations, except that no memory or I/O read/write
> control signals will be generated,
>
> Alright, looks good to me -- my question is if there aren't other
> commands where we want to give this same treatment, but then again...
> we've made it to 2019 without them, so...

It doesn't seem good to me, as it fixes VERIFY mode only for fdc.
Can you try to remove this part, and replace it by the following one (not 
tested) ?

--- a/hw/dma/i8257.c
+++ b/hw/dma/i8257.c
@@ -428,6 +428,11 @@ static int i8257_dma_write_memory(IsaDma *obj, int nchan, 
void *buf, int pos,
 I8257Regs *r = >regs[nchan & 3];
 hwaddr addr = ((r->pageh & 0x7f) << 24) | (r->page << 16) | r->now[ADDR];

+if (r->mode & 0xc0 == 0x00) {
+   /* VERIFY mode, do nothing */
+return len;
+}
+
 if (r->mode & 0x20) {
 int i;
 uint8_t *p = buf;

We may also fix i8257_dma_{read,write}_memory to correctly check for mode and 
refuse to
do anything if mode is wrong.

>
>>   break;
>>   case FD_DIR_WRITE:
>>   /* WRITE commands */
>>
>
> Reviewed-by: John Snow 
>
>

Hervé



Re: [PULL 0/1] qemu-openbios queue 20191028

2019-10-29 Thread Peter Maydell
On Mon, 28 Oct 2019 at 19:42, Mark Cave-Ayland
 wrote:
>
> [This contains a last-minute bugfix for qemu-system-sparc which fixes the 
> keyboard
> in OpenBIOS when booting in graphics mode.]
>
> The following changes since commit 9bb73502321d46f4d320fa17aa38201445783fc4:
>
>   Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging 
> (2019-10-28 13:32:40 +)
>
> are available in the Git repository at:
>
>   git://github.com/mcayland/qemu.git tags/qemu-openbios-20191028
>
> for you to fetch changes up to 9505edece7b7a331ae4bf009d7cf9dc206ddb2d3:
>
>   Update OpenBIOS images to 7e5b89e4 built from submodule. (2019-10-28 
> 17:11:50 +)
>
> 
> qemu-openbios queue


Applied, thanks.

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

-- PMM



Re: [RFC PATCH 0/6] docs: integrate doc comments with Sphinx build

2019-10-29 Thread Peter Maydell
On Tue, 29 Oct 2019 at 16:22, Paolo Bonzini  wrote:
>
> Hello,
>
> this is an attempt at including kernel-doc, with small tweaks (see patch
> 2) to support QEMU's doc comment format, in the Sphinx documentation pipeline.
>
> The ugly part is patch 3, which disables Sphinx's "nitpicking" (warn on
> invalid cross-reference) mode.  It would probably be possible to use
> the nitpick_ignore configuration entry instead.
>
> Paolo
>
> Paolo Bonzini (6):
>   docs: import Linux kernel-doc script and extension
>   docs: tweak kernel-doc for QEMU coding standards
>   docs: disable sphinx warning about missing cross references
>   memory: adjust API documentation to (modified) kerneldoc format
>   docs: add memory API reference
>   memory: include MemoryListener documentation and some missing function
> parameters

Could you briefly describe the differences between this patchset
and the RFC I sent a while back:
https://patchew.org/QEMU/20190521122519.12573-1-peter.mayd...@linaro.org/
please?

thanks
-- PMM



Re: [RFC PATCH 0/6] docs: integrate doc comments with Sphinx build

2019-10-29 Thread no-reply
Patchew URL: 
https://patchew.org/QEMU/20191029162248.13383-1-pbonz...@redhat.com/



Hi,

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

=== TEST SCRIPT BEGIN ===
#! /bin/bash
export ARCH=x86_64
make docker-image-fedora V=1 NETWORK=1
time make docker-test-mingw@fedora J=14 NETWORK=1
=== TEST SCRIPT END ===

Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu 
--prefix=/tmp/qemu-test/install --python=/usr/bin/python3 
--cross-prefix=x86_64-w64-mingw32- --enable-trace-backends=simple 
--enable-gnutls --enable-nettle --enable-curl --enable-vnc --enable-bzip2 
--enable-guest-agent --enable-docs

ERROR: User requested feature docs
   configure was not able to find it.
   Install texinfo, Perl/perl-podlators and python-sphinx

---
funcs: do_compiler do_cc compile_object check_define main
lines: 92 122 616 633 0
x86_64-w64-mingw32-gcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings 
-Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -std=gnu99 -c -o 
config-temp/qemu-conf.o config-temp/qemu-conf.c
config-temp/qemu-conf.c:2:2: error: #error __linux__ not defined
 #error __linux__ not defined
  ^

---
funcs: do_compiler do_cc compile_object check_define main
lines: 92 122 616 685 0
x86_64-w64-mingw32-gcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings 
-Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -std=gnu99 -c -o 
config-temp/qemu-conf.o config-temp/qemu-conf.c
config-temp/qemu-conf.c:2:2: error: #error __i386__ not defined
 #error __i386__ not defined
  ^

---
funcs: do_compiler do_cc compile_object check_define main
lines: 92 122 616 688 0
x86_64-w64-mingw32-gcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings 
-Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -std=gnu99 -c -o 
config-temp/qemu-conf.o config-temp/qemu-conf.c
config-temp/qemu-conf.c:2:2: error: #error __ILP32__ not defined
 #error __ILP32__ not defined
  ^

---
lines: 92 128 928 0
x86_64-w64-mingw32-gcc -mthreads -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef 
-Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv 
-std=gnu99 -o config-temp/qemu-conf.exe config-temp/qemu-conf.c -g -liberty
/usr/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld: 
cannot find -liberty
collect2: error: ld returned 1 exit status

funcs: do_compiler do_cc compile_object main
lines: 92 122 1851 0
---
funcs: do_compiler do_cc compile_prog cc_has_warning_flag main
lines: 92 128 1932 1936 0
x86_64-w64-mingw32-gcc -m64 -mcx16 -mthreads -D_GNU_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common -fwrapv -std=gnu99 -Werror -Wstring-plus-int 
-o config-temp/qemu-conf.exe config-temp/qemu-conf.c -m64 -g
x86_64-w64-mingw32-gcc: error: unrecognized command line option 
'-Wstring-plus-int'; did you mean '-Wstrict-aliasing'?

funcs: do_compiler do_cc compile_prog cc_has_warning_flag main
lines: 92 128 1932 1936 0
x86_64-w64-mingw32-gcc -m64 -mcx16 -mthreads -D_GNU_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common -fwrapv -std=gnu99 -Werror 
-Wtypedef-redefinition -o config-temp/qemu-conf.exe config-temp/qemu-conf.c 
-m64 -g
x86_64-w64-mingw32-gcc: error: unrecognized command line option 
'-Wtypedef-redefinition'; did you mean '-Wold-style-definition'?

funcs: do_compiler do_cc compile_prog cc_has_warning_flag main
lines: 92 128 1932 1936 0
x86_64-w64-mingw32-gcc -m64 -mcx16 -mthreads -D_GNU_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common -fwrapv -std=gnu99 -Werror 
-Winitializer-overrides -o config-temp/qemu-conf.exe config-temp/qemu-conf.c 
-m64 -g
x86_64-w64-mingw32-gcc: error: unrecognized command line option 
'-Winitializer-overrides'; did you mean '-Wno-suggest-override'?

funcs: do_compiler do_cc compile_prog cc_has_warning_flag main
lines: 92 128 1932 1936 0
---
lines: 92 122 2197 0
x86_64-w64-mingw32-gcc -m64 -mcx16 -mthreads -D_GNU_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common -fwrapv -std=gnu99 -Wexpansion-to-defined 
-Wendif-labels -Wno-shift-negative-value -Wno-missing-include-dirs -Wempty-body 
-Wnested-externs 

Re: [PULL 00/11] Q800 branch patches

2019-10-29 Thread Peter Maydell
On Mon, 28 Oct 2019 at 18:48, Laurent Vivier  wrote:
>
> The following changes since commit 7bc8f9734213b76e76631a483be13d6737c2adbc:
>
>   Merge remote-tracking branch 
> 'remotes/pmaydell/tags/pull-target-arm-20191025' into staging (2019-10-25 
> 13:12:16 +0100)
>
> are available in the Git repository at:
>
>   git://github.com/vivier/qemu-m68k.git tags/q800-branch-pull-request
>
> for you to fetch changes up to f7d85525f14b99aaa7bf561c9f3cf11c85a080c9:
>
>   BootLinuxConsoleTest: Test the Quadra 800 (2019-10-28 19:07:22 +0100)
>
> 
> Add Macintosh Quadra 800 machine in hw/m68k
>
> 

Applied, thanks.

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

-- PMM



[Bug 1850378] Re: RISC-V unreliable IPIs

2019-10-29 Thread tm
I created a minimal example from my setup. I'm running a kernel 4.19.57 with a 
custom firmware based on bbl (https://github.com/riscv/riscv-pk). 
An ioctl device from a kernel module is used to execute the code above in 
kernel space.
In the example, the userspace application proceeds after a couple of seconds 
without receiving the custom IPI.

** Attachment added: "example.tar.gz"
   
https://bugs.launchpad.net/qemu/+bug/1850378/+attachment/5301219/+files/example.tar.gz

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

Title:
  RISC-V unreliable IPIs

Status in QEMU:
  New

Bug description:
  I am working on a project with custom inter processor interrupts (IPIs) on 
the RISC-V virt machine.
  After upgrading from version 3.1.0 to 4.1.0 which fixes a related issue 
(https://github.com/riscv/riscv-qemu/issues/132) I am able to use the CPU 
hotplug feature.

  However, if I try to use IPIs for communication between two cores, the
  wfi instruction behaves strangely. Either it does not return, or it
  returns on timer interrupts, even though they are disabled. The code,
  I use on one core to wait for an interrupt is the following.

csr_clear(sie, SIE_SEIE | SIE_STIE);
do {
wait_for_interrupt();
sipval = csr_read(sip);
sieval = csr_read(sie);
scauseval = csr_read(scause) & 0xFF;
/* only break if wfi returns for an software interrupt */
} while ((sipval & sieval) == 0 && scauseval != 1);
csr_set(sie, SIE_SEIE | SIE_STIE);

  Since the resulting sequence does not seem to be deterministic, my
  guess is, that it has something to do with the communication of qemu's
  threads for the different cores.

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



Re: [PULL 00/20] hw/i386/pc: Split PIIX3 southbridge from i440FX northbridge

2019-10-29 Thread Philippe Mathieu-Daudé

Hi Aleksandar,

On 10/29/19 6:18 AM, Aleksandar Markovic wrote:



On Monday, October 28, 2019, Philippe Mathieu-Daudé > wrote:


Hi Peter,

This is a X86/MIPS pull, Paolo and Aleksandar are OK I send it:

https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg04959.html


Regards,

Phil.


Does this pull request apply on the current code base directly, or is 
dependant on prior application of other pull requests?


I'm not sure I understand the question, this is a pull request, so it 
has been tested on the commit on the last master commit (yesterday),

the cover says commit '9bb7350232'. Is there a problem?


The following changes since commit
9bb73502321d46f4d320fa17aa38201445783fc4:

   Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into
staging (2019-10-28 13:32:40 +)

are available in the Git repository at:

https://gitlab.com/philmd/qemu.git

tags/pc_split_i440fx_piix-pull-request

for you to fetch changes up to d1389352cde824ce8dab7c1a2ded150df6add124:

   hw/pci-host/i440fx: Remove the last PIIX3 traces (2019-10-28
16:12:29 +0100)


The i440FX northbridge is only used by the PC machine, while the
PIIX southbridge is also used by the Malta MIPS machine.

Split the PIIX3 southbridge from i440FX northbridge.



Hervé Poussineau (5):
   piix4: Add the Reset Control Register
   piix4: Add an i8259 Interrupt Controller as specified in datasheet
   piix4: Rename PIIX4 object to piix4-isa
   piix4: Add an i8257 DMA Controller as specified in datasheet
   piix4: Add an i8254 PIT Controller as specified in datasheet

Philippe Mathieu-Daudé (15):
   MAINTAINERS: Keep PIIX4 South Bridge separate from PC Chipsets
   Revert "irq: introduce qemu_irq_proxy()"
   piix4: Add a MC146818 RTC Controller as specified in datasheet
   hw/mips/mips_malta: Create IDE hard drive array dynamically
   hw/mips/mips_malta: Extract the PIIX4 creation code as piix4_create()
   hw/isa/piix4: Move piix4_create() to hw/isa/piix4.c
   hw/i386: Remove obsolete LoadStateHandler::load_state_old handlers
   hw/pci-host/piix: Extract piix3_create()
   hw/pci-host/piix: Move RCR_IOPORT register definition
   hw/pci-host/piix: Define and use the PIIX IRQ Route Control Registers
   hw/pci-host/piix: Move i440FX declarations to hw/pci-host/i440fx.h
   hw/pci-host/piix: Fix code style issues
   hw/pci-host/piix: Extract PIIX3 functions to hw/isa/piix3.c
   hw/pci-host: Rename incorrectly named 'piix' as 'i440fx'
   hw/pci-host/i440fx: Remove the last PIIX3 traces

  MAINTAINERS                      |  14 +-
  hw/acpi/pcihp.c                  |   2 +-
  hw/acpi/piix4.c                  |  42 +--
  hw/core/irq.c                    |  14 -
  hw/i386/Kconfig                  |   3 +-
  hw/i386/acpi-build.c             |   5 +-
  hw/i386/pc_piix.c                |  10 +-
  hw/i386/xen/xen-hvm.c            |   5 +-
  hw/intc/apic_common.c            |  49 
  hw/isa/Kconfig                   |   4 +
  hw/isa/Makefile.objs             |   1 +
  hw/isa/piix3.c                   | 399 +
  hw/isa/piix4.c                   | 151 ++-
  hw/mips/gt64xxx_pci.c            |   5 +-
  hw/mips/mips_malta.c             |  46 +---
  hw/pci-host/Kconfig              |   3 +-
  hw/pci-host/Makefile.objs        |   2 +-
  hw/pci-host/{piix.c => i440fx.c} | 424 +--
  hw/timer/i8254_common.c          |  40 ---
  include/hw/acpi/piix4.h          |   6 -
  include/hw/i386/pc.h             |  37 ---
  include/hw/irq.h                 |   5 -
  include/hw/isa/isa.h             |   2 +
  include/hw/pci-host/i440fx.h     |  36 +++
  include/hw/southbridge/piix.h    |  74 ++
  stubs/pci-host-piix.c            |   3 +-
  26 files changed, 699 insertions(+), 683 deletions(-)
  create mode 100644 hw/isa/piix3.c
  rename hw/pci-host/{piix.c => i440fx.c} (58%)
  delete mode 100644 include/hw/acpi/piix4.h
  create mode 100644 include/hw/pci-host/i440fx.h
  create mode 100644 include/hw/southbridge/piix.h

-- 
2.21.0







[PATCH 2/2] tests/fw_cfg: Test 'reboot-timeout=-1' special value

2019-10-29 Thread Philippe Mathieu-Daudé
The special value -1 means "don't reboot" for QEMU/libvirt.
Add a trivial test.

Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/fw_cfg-test.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/tests/fw_cfg-test.c b/tests/fw_cfg-test.c
index 1d3147f821..5dc807ba23 100644
--- a/tests/fw_cfg-test.c
+++ b/tests/fw_cfg-test.c
@@ -194,6 +194,26 @@ static void test_fw_cfg_reboot_timeout(void)
 qtest_quit(s);
 }
 
+static void test_fw_cfg_no_reboot_timeout(void)
+{
+QFWCFG *fw_cfg;
+QTestState *s;
+uint32_t reboot_timeout = 0;
+size_t filesize;
+
+/* Special value -1 means "don't reboot" */
+s = qtest_init("-boot reboot-timeout=-1");
+fw_cfg = pc_fw_cfg_init(s);
+
+filesize = qfw_cfg_get_file(fw_cfg, "etc/boot-fail-wait",
+_timeout, sizeof(reboot_timeout));
+g_assert_cmpint(filesize, ==, sizeof(reboot_timeout));
+reboot_timeout = le32_to_cpu(reboot_timeout);
+g_assert_cmpint(reboot_timeout, ==, UINT32_MAX);
+pc_fw_cfg_uninit(fw_cfg);
+qtest_quit(s);
+}
+
 static void test_fw_cfg_splash_time(void)
 {
 QFWCFG *fw_cfg;
@@ -233,6 +253,7 @@ int main(int argc, char **argv)
 qtest_add_func("fw_cfg/numa", test_fw_cfg_numa);
 qtest_add_func("fw_cfg/boot_menu", test_fw_cfg_boot_menu);
 qtest_add_func("fw_cfg/reboot_timeout", test_fw_cfg_reboot_timeout);
+qtest_add_func("fw_cfg/no_reboot_timeout", test_fw_cfg_no_reboot_timeout);
 qtest_add_func("fw_cfg/splash_time", test_fw_cfg_splash_time);
 
 return g_test_run();
-- 
2.21.0




[PATCH 0/2] fw_cfg: Allow reboot-timeout=-1 again

2019-10-29 Thread Philippe Mathieu-Daudé
Fix the '-1' special value, and add a test.

Dr. David Alan Gilbert (1):
  fw_cfg: Allow reboot-timeout=-1 again

Philippe Mathieu-Daudé (1):
  tests/fw_cfg: Test 'reboot-timeout=-1' special value

 hw/nvram/fw_cfg.c   |  7 ---
 tests/fw_cfg-test.c | 21 +
 2 files changed, 25 insertions(+), 3 deletions(-)

-- 
2.21.0




[PATCH 1/2] fw_cfg: Allow reboot-timeout=-1 again

2019-10-29 Thread Philippe Mathieu-Daudé
From: "Dr. David Alan Gilbert" 

Commit ee5d0f89de3e53cdb0dc added range checking on reboot-timeout
to only allow the range 0..65535; however both qemu and libvirt document
the special value -1  to mean don't reboot.
Allow it again.

Fixes: ee5d0f89de3e53cdb0dc ("fw_cfg: Fix -boot reboot-timeout error checking")
RH bz: https://bugzilla.redhat.com/show_bug.cgi?id=1765443
Signed-off-by: Dr. David Alan Gilbert 
Message-Id: <20191025165706.177653-1-dgilb...@redhat.com>
Suggested-by: Laszlo Ersek 
Message-Id: <37ac197c-f20e-dd05-ff6a-13a2171c7...@redhat.com>
[PMD: Applied Laszlo's suggestions]
Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/nvram/fw_cfg.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index aef1727250..14f8437983 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -237,7 +237,7 @@ static void fw_cfg_bootsplash(FWCfgState *s)
 static void fw_cfg_reboot(FWCfgState *s)
 {
 const char *reboot_timeout = NULL;
-int64_t rt_val = -1;
+uint64_t rt_val = -1;
 uint32_t rt_le32;
 
 /* get user configuration */
@@ -247,10 +247,11 @@ static void fw_cfg_reboot(FWCfgState *s)
 
 if (reboot_timeout) {
 rt_val = qemu_opt_get_number(opts, "reboot-timeout", -1);
+
 /* validate the input */
-if (rt_val < 0 || rt_val > 0x) {
+if (rt_val > 0x && rt_val != (uint64_t)-1) {
 error_report("reboot timeout is invalid,"
- "it should be a value between 0 and 65535");
+ "it should be a value between -1 and 65535");
 exit(1);
 }
 }
-- 
2.21.0




Re: [PULL 0/4] Crypto luks patches

2019-10-29 Thread Peter Maydell
On Mon, 28 Oct 2019 at 15:58, Daniel P. Berrangé  wrote:
>
> The following changes since commit 187f35512106501fe9a11057f4d8705431e0026d:
>
>   Merge remote-tracking branch 
> 'remotes/stsquad/tags/pull-testing-next-251019-3' into staging (2019-10-26 
> 10:13:48 +0100)
>
> are available in the Git repository at:
>
>   https://github.com/berrange/qemu tags/crypto-luks-pull-request
>
> for you to fetch changes up to dc2207af2de162005f7e9e534850d07232290cee:
>
>   crypto: add support for nettle's native XTS impl (2019-10-28 16:45:07 +0100)
>
> 
> crypto: improve performance of ciphers in XTS mode
>
> Currently QEMU uses its own XTS cipher mode, however, this has
> relatively poor performance.
>
> Gcrypt now includes its own XTS cipher which is at least x2 faster than
> what we get with QEMU's on Fedora/RHEL hosts. With gcrypt git master, a
> further x5-6 speed up is seen.
>
> This is essential for QEMU's LUKS performance to be viable.
>
> 

Applied, thanks.

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

-- PMM



[PATCH 5/6] docs: add memory API reference

2019-10-29 Thread Paolo Bonzini
Add kernel-doc directive to parse and include doc comments from
include/exec/memory.h.

Signed-off-by: Paolo Bonzini 
---
 docs/devel/memory.rst | 5 +
 1 file changed, 5 insertions(+)

diff --git a/docs/devel/memory.rst b/docs/devel/memory.rst
index b6a4c37ea5..5dc8a12682 100644
--- a/docs/devel/memory.rst
+++ b/docs/devel/memory.rst
@@ -361,3 +361,8 @@ callbacks are called:
 - .impl.unaligned specifies that the *implementation* supports unaligned
   accesses; if false, unaligned accesses will be emulated by two aligned
   accesses.
+
+API Reference
+-
+
+.. kernel-doc:: include/exec/memory.h
-- 
2.21.0





[PATCH 6/6] memory: include MemoryListener documentation and some missing function parameters

2019-10-29 Thread Paolo Bonzini
These cover the remaining warnings from kernel-doc.

Signed-off-by: Paolo Bonzini 
---
 include/exec/memory.h | 211 +-
 1 file changed, 209 insertions(+), 2 deletions(-)

diff --git a/include/exec/memory.h b/include/exec/memory.h
index 1e875996ec..c84fde75fa 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -423,30 +423,232 @@ struct IOMMUMemoryRegion {
  * Use with memory_listener_register() and memory_listener_unregister().
  */
 struct MemoryListener {
+/**
+ * @begin:
+ *
+ * Called at the beginning of an address space update transaction.
+ * Followed by calls to #MemoryListener.region_add(),
+ * #MemoryListener.region_del(), #MemoryListener.region_nop(),
+ * #MemoryListener.log_start() and #MemoryListener.log_stop() in
+ * increasing address order.
+ *
+ * @listener: The #MemoryListener.
+ */
 void (*begin)(MemoryListener *listener);
+
+/**
+ * @commit:
+ *
+ * Called at the end of an address space update transaction,
+ * after the last call to #MemoryListener.region_add(),
+ * #MemoryListener.region_del() or #MemoryListener.region_nop(),
+ * #MemoryListener.log_start() and #MemoryListener.log_stop().
+ *
+ * @listener: The #MemoryListener.
+ */
 void (*commit)(MemoryListener *listener);
+
+/**
+ * @region_add:
+ *
+ * Called during an address space update transaction,
+ * for a section of the address space that is new in this address space
+ * space since the last transaction.
+ *
+ * @listener: The #MemoryListener.
+ * @section: The new #MemoryRegionSection.
+ */
 void (*region_add)(MemoryListener *listener, MemoryRegionSection *section);
+
+/**
+ * @region_del:
+ *
+ * Called during an address space update transaction,
+ * for a section of the address space that has disappeared in the address
+ * space since the last transaction.
+ *
+ * @listener: The #MemoryListener.
+ * @section: The old #MemoryRegionSection.
+ */
 void (*region_del)(MemoryListener *listener, MemoryRegionSection *section);
+
+/**
+ * @region_nop:
+ *
+ * Called during an address space update transaction,
+ * for a section of the address space that is in the same place in the 
address
+ * space as in the last transaction.
+ *
+ * @listener: The #MemoryListener.
+ * @section: The #MemoryRegionSection.
+ */
 void (*region_nop)(MemoryListener *listener, MemoryRegionSection *section);
+
+/**
+ * @log_start:
+ *
+ * Called during an address space update transaction, after
+ * one of #MemoryListener.region_add(),#MemoryListener.region_del() or
+ * #MemoryListener.region_nop(), if dirty memory logging clients have
+ * become active since the last transaction.
+ *
+ * @listener: The #MemoryListener.
+ * @section: The #MemoryRegionSection.
+ * @old: A bitmap of dirty memory logging clients that were active in
+ * the previous transaction.
+ * @new: A bitmap of dirty memory logging clients that are active in
+ * the current transaction.
+ */
 void (*log_start)(MemoryListener *listener, MemoryRegionSection *section,
   int old, int new);
+
+/**
+ * @log_stop:
+ *
+ * Called during an address space update transaction, after
+ * one of #MemoryListener.region_add(), #MemoryListener.region_del() or
+ * #MemoryListener.region_nop() and possibly after
+ * #MemoryListener.log_start(), if dirty memory logging clients have
+ * become inactive since the last transaction.
+ *
+ * @listener: The #MemoryListener.
+ * @section: The #MemoryRegionSection.
+ * @old: A bitmap of dirty memory logging clients that were active in
+ * the previous transaction.
+ * @new: A bitmap of dirty memory logging clients that are active in
+ * the current transaction.
+ */
 void (*log_stop)(MemoryListener *listener, MemoryRegionSection *section,
  int old, int new);
+
+/**
+ * @log_sync:
+ *
+ * Called by memory_region_snapshot_and_clear_dirty() and
+ * memory_global_dirty_log_sync(), before accessing QEMU's "official"
+ * copy of the dirty memory bitmap for a #MemoryRegionSection.
+ *
+ * @listener: The #MemoryListener.
+ * @section: The #MemoryRegionSection.
+ */
 void (*log_sync)(MemoryListener *listener, MemoryRegionSection *section);
+
+/**
+ * @log_clear:
+ *
+ * Called before reading the dirty memory bitmap for a
+ * #MemoryRegionSection.
+ *
+ * @listener: The #MemoryListener.
+ * @section: The #MemoryRegionSection.
+ */
 void (*log_clear)(MemoryListener *listener, MemoryRegionSection *section);
+
+/**
+ * @log_global_start:
+ *
+ * Called by memory_global_dirty_log_start(), which
+ * enables the %DIRTY_LOG_MIGRATION 

[PATCH 4/6] memory: adjust API documentation to (modified) kerneldoc format

2019-10-29 Thread Paolo Bonzini
Fix a few instances where kernel-doc complains about doc comments
in memory.h.

Signed-off-by: Paolo Bonzini 
---
 include/exec/memory.h | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/include/exec/memory.h b/include/exec/memory.h
index e499dc215b..1e875996ec 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -360,10 +360,14 @@ typedef struct IOMMUMemoryRegionClass {
 typedef struct CoalescedMemoryRange CoalescedMemoryRange;
 typedef struct MemoryRegionIoeventfd MemoryRegionIoeventfd;
 
+/** MemoryRegion:
+ *
+ * A struct representing a memory region.
+ */
 struct MemoryRegion {
 Object parent_obj;
 
-/* All fields are private - violators will be prosecuted */
+/* private: */
 
 /* The following fields should fit in a cache line */
 bool romd_mode;
@@ -452,7 +456,7 @@ struct MemoryListener {
  * AddressSpace: describes a mapping of addresses to #MemoryRegion objects
  */
 struct AddressSpace {
-/* All fields are private. */
+/* private: */
 struct rcu_head rcu;
 char *name;
 MemoryRegion *root;
@@ -1673,8 +1677,8 @@ bool memory_region_is_mapped(MemoryRegion *mr);
  *
  * Returns a #MemoryRegionSection that describes a contiguous overlap.
  * It will have the following characteristics:
- *.@size = 0 iff no overlap was found
- *.@mr is non-%NULL iff an overlap was found
+ * - @size = 0 iff no overlap was found
+ * - @mr is non-%NULL iff an overlap was found
  *
  * Remember that in the return value the @offset_within_region is
  * relative to the returned region (in the .@mr field), not to the
@@ -1685,8 +1689,8 @@ bool memory_region_is_mapped(MemoryRegion *mr);
  * returned one.  However, in the special case where the @mr argument
  * has no container (and thus is the root of the address space), the
  * following will hold:
- *.@offset_within_address_space >= @addr
- *.@offset_within_address_space + .@size <= @addr + @size
+ * - @offset_within_address_space >= @addr
+ * - @offset_within_address_space + .@size <= @addr + @size
  *
  * @mr: a MemoryRegion within which @addr is a relative address
  * @addr: start of the area within @as to be searched
-- 
2.21.0





[PATCH 1/6] docs: import Linux kernel-doc script and extension

2019-10-29 Thread Paolo Bonzini
Import Linux's kernel-doc script, as well as the Linux extension to
call kernel-doc according to the arguments and parameters given to
a reStructuredText directive.

The kernel-doc extension accepts a filename, which is relative to
the QEMU source tree root.  The extension also notifies Sphinx about the
document dependency on the file, causing the document to be rebuilt when
the file has been changed.

Signed-off-by: Paolo Bonzini 
---
 docs/conf.py |7 +-
 docs/sphinx/kernellog.py |   28 +
 scripts/kernel-doc   | 2226 ++
 3 files changed, 2260 insertions(+), 1 deletion(-)
 create mode 100644 docs/sphinx/kernellog.py
 create mode 100755 scripts/kernel-doc

diff --git a/docs/conf.py b/docs/conf.py
index 83131ac187..7bf2d0d58b 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -54,7 +54,7 @@ needs_sphinx = '1.3'
 # Add any Sphinx extension module names here, as strings. They can be
 # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
 # ones.
-extensions = ['qmp_lexer']
+extensions = ['kerneldoc', 'qmp_lexer']
 
 # Add any paths that contain templates here, relative to this directory.
 templates_path = ['_templates']
@@ -215,4 +215,9 @@ texinfo_documents = [
 ]
 
 
+# kernel-doc extension configuration for running Sphinx directly (e.g. by Read
+# the Docs). In a normal build, these are supplied from the Makefile via 
command
+# line arguments.
+kerneldoc_bin = '../scripts/kernel-doc'
+kerneldoc_srctree = '..'
 
diff --git a/docs/sphinx/kernellog.py b/docs/sphinx/kernellog.py
new file mode 100644
index 00..af924f51a7
--- /dev/null
+++ b/docs/sphinx/kernellog.py
@@ -0,0 +1,28 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Sphinx has deprecated its older logging interface, but the replacement
+# only goes back to 1.6.  So here's a wrapper layer to keep around for
+# as long as we support 1.4.
+#
+import sphinx
+
+if sphinx.__version__[:3] >= '1.6':
+UseLogging = True
+from sphinx.util import logging
+logger = logging.getLogger('kerneldoc')
+else:
+UseLogging = False
+
+def warn(app, message):
+if UseLogging:
+logger.warning(message)
+else:
+app.warn(message)
+
+def verbose(app, message):
+if UseLogging:
+logger.verbose(message)
+else:
+app.verbose(message)
+
+
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
new file mode 100755
index 00..81dc91760b
--- /dev/null
+++ b/scripts/kernel-doc
@@ -0,0 +1,2226 @@
+#!/usr/bin/env perl
+# SPDX-License-Identifier: GPL-2.0
+
+use warnings;
+use strict;
+
+## Copyright (c) 1998 Michael Zucchi, All Rights Reserved##
+## Copyright (C) 2000, 1  Tim Waugh   ##
+## Copyright (C) 2001  Simon Huggins ##
+## Copyright (C) 2005-2012  Randy Dunlap ##
+## Copyright (C) 2012  Dan Luedtke   ##
+##  ##
+## #define enhancements by Armin Kuster ##
+## Copyright (c) 2000 MontaVista Software, Inc. ##
+##  ##
+## This software falls under the GNU General Public License. ##
+## Please read the COPYING file for more information ##
+
+# 18/01/2001 - Cleanups
+#  Functions prototyped as foo(void) same as foo()
+#  Stop eval'ing where we don't need to.
+# -- hug...@earth.li
+
+# 27/06/2001 -  Allowed whitespace after initial "/**" and
+#   allowed comments before function declarations.
+# -- Christian Kreibich 
+
+# Still to do:
+#  - add perldoc documentation
+#  - Look more closely at some of the scarier bits :)
+
+# 26/05/2001 - Support for separate source and object trees.
+#  Return error code.
+#  Keith Owens 
+
+# 23/09/2001 - Added support for typedefs, structs, enums and unions
+#  Support for Context section; can be terminated using empty line
+#  Small fixes (like spaces vs. \s in regex)
+# -- Tim Jansen 
+
+# 25/07/2012 - Added support for HTML5
+# -- Dan Luedtke 
+
+sub usage {
+my $message = <<"EOF";
+Usage: $0 [OPTION ...] FILE ...
+
+Read C language source or header FILEs, extract embedded documentation 
comments,
+and print formatted documentation to standard output.
+
+The documentation comments are identified by "/**" opening comment mark. See
+Documentation/doc-guide/kernel-doc.rst for the documentation comment syntax.
+
+Output format selection (mutually exclusive):
+  -man Output troff manual page format. This is the default.
+  -rst Output reStructuredText format.
+  -noneDo not output documentation, only warnings.
+
+Output selection (mutually exclusive):
+  -export  Only output documentation for symbols that have been
+   exported using EXPORT_SYMBOL() or 

[PATCH 2/6] docs: tweak kernel-doc for QEMU coding standards

2019-10-29 Thread Paolo Bonzini
Surprisingly, QEMU does have a pretty consistent doc comment style and
it is not very different from the Linux kernel's.  Of the documentation
"sigils", only "#" separates the QEMU doc comment style from Linux's,
and it has 200+ instances vs. 6 for the kernel's ' foo' (all in
accel/tcg/translate-all.c), so it's clear that the two standards are
different in this respect.  In addition, our structs are typedefed and
recognized by CamelCase names.

Adjust kernel-doc's parser for these two aspects of the QEMU coding
standards.  The patch has been valid, with hardly any change, for over
two years, so it should not be an issue to keep kernel-doc in sync with
the Linux copy.

Signed-off-by: Paolo Bonzini 
---
 scripts/kernel-doc | 28 +++-
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 81dc91760b..af470eb321 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -215,12 +215,12 @@ my $type_func = '(\w+)\(\)';
 my $type_param = '\@(\w*((\.\w+)|(->\w+))*(\.\.\.)?)';
 my $type_fp_param = '\@(\w+)\(\)';  # Special RST handling for func ptr params
 my $type_env = '(\$\w+)';
-my $type_enum = '\&(enum\s*([_\w]+))';
-my $type_struct = '\&(struct\s*([_\w]+))';
-my $type_typedef = '\&(typedef\s*([_\w]+))';
-my $type_union = '\&(union\s*([_\w]+))';
-my $type_member = '\&([_\w]+)(\.|->)([_\w]+)';
-my $type_fallback = '\&([_\w]+)';
+my $type_enum = '#(enum\s*([_\w]+))';
+my $type_struct = '#(struct\s*([_\w]+))';
+my $type_typedef = '#(([A-Z][_\w]*))';
+my $type_union = '#(union\s*([_\w]+))';
+my $type_member = '#([_\w]+)(\.|->)([_\w]+)';
+my $type_fallback = '(?!)';# this never matches
 my $type_member_func = $type_member . '\(\)';
 
 # Output conversion substitutions.
@@ -1050,6 +1050,14 @@ sub output_blockhead {
 sub dump_declaration($$) {
 no strict 'refs';
 my ($prototype, $file) = @_;
+if ($decl_type eq 'type name') {
+   if ($prototype =~ /^(enum|struct|union)\s+/) {
+  $decl_type = $1;
+   } else {
+  return;
+   }
+}
+
 my $func = "dump_" . $decl_type;
 &$func(@_);
 }
@@ -1878,7 +1886,7 @@ sub process_name($$) {
 }
 elsif (/$doc_decl/o) {
$identifier = $1;
-   if (/\s*([\w\s]+?)(\(\))?\s*-/) {
+   if (/\s*([\w\s]+?)(\s*-|:)/) {
$identifier = $1;
}
 
@@ -1888,7 +1896,7 @@ sub process_name($$) {
$contents = "";
$section = $section_default;
$new_start_line = $. + 1;
-   if (/-(.*)/) {
+   if (/[-:](.*)/) {
# strip leading/trailing/multiple spaces
$descr= $1;
$descr =~ s/^\s*//;
@@ -1906,7 +1914,9 @@ sub process_name($$) {
++$warnings;
}
 
-   if ($identifier =~ m/^struct\b/) {
+   if ($identifier =~ m/^[A-Z]/) {
+   $decl_type = 'type name';
+   } elsif ($identifier =~ m/^struct\b/) {
$decl_type = 'struct';
} elsif ($identifier =~ m/^union\b/) {
$decl_type = 'union';
-- 
2.21.0





[RFC PATCH 0/6] docs: integrate doc comments with Sphinx build

2019-10-29 Thread Paolo Bonzini
Hello,

this is an attempt at including kernel-doc, with small tweaks (see patch
2) to support QEMU's doc comment format, in the Sphinx documentation pipeline.

The ugly part is patch 3, which disables Sphinx's "nitpicking" (warn on
invalid cross-reference) mode.  It would probably be possible to use
the nitpick_ignore configuration entry instead.

Paolo

Paolo Bonzini (6):
  docs: import Linux kernel-doc script and extension
  docs: tweak kernel-doc for QEMU coding standards
  docs: disable sphinx warning about missing cross references
  memory: adjust API documentation to (modified) kerneldoc format
  docs: add memory API reference
  memory: include MemoryListener documentation and some missing function
parameters

 Makefile |2 +-
 docs/conf.py |7 +-
 docs/devel/memory.rst|5 +
 docs/sphinx/kernellog.py |   28 +
 include/exec/memory.h|  227 +++-
 scripts/kernel-doc   | 2236 ++
 6 files changed, 2495 insertions(+), 10 deletions(-)
 create mode 100644 docs/sphinx/kernellog.py
 create mode 100755 scripts/kernel-doc

-- 
2.21.0




[PATCH 3/6] docs: disable sphinx warning about missing cross references

2019-10-29 Thread Paolo Bonzini
Sphinx is a bit *too* strict about missing cross references to
C types, where it complains about missing references to uint8_t.
Even if that were fixed in kernel-doc, we would still have lots
of missing references to types that are not yet documented.  So
unfortunately let's disable for now the nitpicking mode.

Signed-off-by: Paolo Bonzini  # still not a good idea, 
probably
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index d20e7ffce3..8aa915ff26 100644
--- a/Makefile
+++ b/Makefile
@@ -986,7 +986,7 @@ sphinxdocs: $(MANUAL_BUILDDIR)/devel/index.html 
$(MANUAL_BUILDDIR)/interop/index
 # Note the use of different doctree for each (manual, builder) tuple;
 # this works around Sphinx not handling parallel invocation on
 # a single doctree: https://github.com/sphinx-doc/sphinx/issues/2946
-build-manual = $(call quiet-command,CONFDIR="$(qemu_confdir)" sphinx-build 
$(if $(V),,-q) -W -n -b $2 -D version=$(VERSION) -D release="$(FULL_VERSION)" 
-d .doctrees/$1-$2 $(SRC_PATH)/docs/$1 $(MANUAL_BUILDDIR)/$1 
,"SPHINX","$(MANUAL_BUILDDIR)/$1")
+build-manual = $(call quiet-command,CONFDIR="$(qemu_confdir)" sphinx-build 
$(if $(V),,-q) -W -b $2 -D version=$(VERSION) -D release="$(FULL_VERSION)" -d 
.doctrees/$1-$2 $(SRC_PATH)/docs/$1 $(MANUAL_BUILDDIR)/$1 
,"SPHINX","$(MANUAL_BUILDDIR)/$1")
 # We assume all RST files in the manual's directory are used in it
 manual-deps = $(wildcard $(SRC_PATH)/docs/$1/*.rst) 
$(SRC_PATH)/docs/$1/conf.py $(SRC_PATH)/docs/conf.py
 
-- 
2.21.0





Re: [PATCH v5 00/13] Multi-phase reset mechanism

2019-10-29 Thread Damien Hedde
Hi,

Does anyone has comment about the interface / patch 3 ?
Should I try to split it ?

Thanks,
Damien

On 10/18/19 5:06 PM, Damien Hedde wrote:
> Hi all,
> 
> The purpose of this series is to split the current reset procedure
> into multiple phases. This will help to solve some ordering
> difficulties we have during reset. Previous version can be found here:
> https://lists.gnu.org/archive/html/qemu-devel/2019-08/msg04359.html
> 
> This series adds resettable interface and transitions base Device and
> Bus classes (sysbus subclasses are ok too). It provides new reset
> functions but does not switch anymore the old functions
> (device_reset() and qdev/qbus_reset_all()) to resettable interface.
> These functions keep the exact same behavior as before.
> 
> The series also transition the main reset handlers registration which
> has no impact until devices and buses are transitioned.
> 
> I think this version is way better regarding the transition from the
> legacy to the resettable interface than the previous one.
> After this series, the plan is then to transition devices, buses and
> legacy reset call sites. Devices and buses have to be transitioned
> from mother class to daughter classes order but until the final
> (daughter) class is transitioned, old monolitic reset behavior will
> be kept for this class.
> 
> Changes v4 -> v5:
>   + various improvement in the resettable interface (regarding
> transition, robustness and several reset types)
>   + better handling of transition from legacy reset to resettable
>   + device hotplug and parent bus 'hot' change support
>   + improved doc with examples and converted to rst format
> 
> Regarding the Resettable interface changes and how to handle more
> reset types, please read patch 3 message.
> 
> The series is organized as follows:
> Patch 1 is unmodified. Patch 2 adds some utility trace events.
> Patches 3 to 8 adds resettable api in devices and buses. Patch 9 adds
> some documentation. Patches 10 and 11 transition the call sites of
> qemu_register_reset(qdev/qbus_reset_all_fn, ...).
> 
> Apart from patch 7 about hotplug which is really a rfc. I think other
> patches are in pretty good shape.
> Patch 3 and 4 are quite big but I don't think it make much sense to
> split them. I could give it a try if you think it will ease reviews.
> Note that depending on what name we choose for device/bus reset
> functions (see patch 8), we may finally don't need patch 1.
> 
> I've also added patches 12 and 13 which handle the raspi sd card
> reparenting. I'm not sure they fit well in this series but at some
> point in this development I thought they had to be before patch 9
> (finally it is not the case). Since I had to develop some specific
> resettable support just for this case , I kept them as an example
> of what transition a device is. Note that patch 13 handle the only
> reset parent change (tricky) case I found (apart from hotplug).
> 
> Thanks for your feedback,
> Damien
> 
> Damien Hedde (13):
>   add device_legacy_reset function to prepare for reset api change
>   hw/core/qdev: add trace events to help with resettable transition
>   hw/core: create Resettable QOM interface
>   hw/core: add Resettable support to BusClass and DeviceClass
>   hw/core/resettable: add support for changing parent
>   hw/core/qdev: handle parent bus change regarding resettable
>   hw/core/qdev: update hotplug reset regarding resettable
>   hw/core: deprecate old reset functions and introduce new ones
>   docs/devel/reset.txt: add doc about Resettable interface
>   vl: replace deprecated qbus_reset_all registration
>   hw/s390x/ipl: replace deprecated qdev_reset_all registration
>   hw/gpio/bcm2835_gpio: Isolate sdbus reparenting
>   hw/gpio/bcm2835_gpio: Update to resettable
> 
>  Makefile.objs|   1 +
>  docs/devel/reset.rst | 282 ++
>  hw/audio/intel-hda.c |   2 +-
>  hw/core/Makefile.objs|   1 +
>  hw/core/bus.c| 102 ++
>  hw/core/qdev.c   | 156 +++--
>  hw/core/resettable.c | 289 +++
>  hw/core/trace-events |  27 
>  hw/gpio/bcm2835_gpio.c   |  31 +++--
>  hw/hyperv/hyperv.c   |   2 +-
>  hw/i386/pc.c |   2 +-
>  hw/ide/microdrive.c  |   8 +-
>  hw/intc/spapr_xive.c |   2 +-
>  hw/ppc/pnv_psi.c |   2 +-
>  hw/ppc/spapr_pci.c   |   2 +-
>  hw/ppc/spapr_vio.c   |   2 +-
>  hw/s390x/ipl.c   |  10 +-
>  hw/s390x/s390-pci-inst.c |   2 +-
>  hw/scsi/vmw_pvscsi.c |   2 +-
>  hw/sd/omap_mmc.c |   2 +-
>  hw/sd/pl181.c|   2 +-
>  include/hw/qdev-core.h   |  58 +++-
>  include/hw/resettable.h  | 224 ++
>  tests/Makefile.include   |   1 +
>  vl.c |  10 +-
>  25 files changed, 1185 insertions(+), 37 deletions(-)
>  create mode 100644 docs/devel/reset.rst
>  create mode 100644 hw/core/resettable.c
>  create mode 

Re: [PULL v2 00/12] tcg patch queue

2019-10-29 Thread Peter Maydell
On Mon, 28 Oct 2019 at 14:59, Richard Henderson
 wrote:
>
> V2 fixes a build problem that affected win32.
>
>
> r~
>
>
> The following changes since commit 187f35512106501fe9a11057f4d8705431e0026d:
>
>   Merge remote-tracking branch 
> 'remotes/stsquad/tags/pull-testing-next-251019-3' into staging (2019-10-26 
> 10:13:48 +0100)
>
> are available in the Git repository at:
>
>   https://github.com/rth7680/qemu.git tags/pull-tcg-20191028
>
> for you to fetch changes up to fe9b676fb3160496b4b2bf0c57d33be724bf04c3:
>
>   translate-all: Remove tb_alloc (2019-10-28 10:35:23 +0100)
>
> 
> Improvements for TARGET_PAGE_BITS_VARY
> Fix for TCI ld16u_i64.
> Fix for segv on icount execute from i/o memory.
> Two misc cleanups.
>
> 

Applied, thanks.

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

-- PMM



[Bug 1850378] Re: RISC-V unreliable IPIs

2019-10-29 Thread Palmer Dabbelt
Can you post a whole program that reproduces this?  freedom-e-sdk
 will run bare-metal code on
QEMU if you don't want to post the rest of the surrounding
infrastructure.

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

Title:
  RISC-V unreliable IPIs

Status in QEMU:
  New

Bug description:
  I am working on a project with custom inter processor interrupts (IPIs) on 
the RISC-V virt machine.
  After upgrading from version 3.1.0 to 4.1.0 which fixes a related issue 
(https://github.com/riscv/riscv-qemu/issues/132) I am able to use the CPU 
hotplug feature.

  However, if I try to use IPIs for communication between two cores, the
  wfi instruction behaves strangely. Either it does not return, or it
  returns on timer interrupts, even though they are disabled. The code,
  I use on one core to wait for an interrupt is the following.

csr_clear(sie, SIE_SEIE | SIE_STIE);
do {
wait_for_interrupt();
sipval = csr_read(sip);
sieval = csr_read(sie);
scauseval = csr_read(scause) & 0xFF;
/* only break if wfi returns for an software interrupt */
} while ((sipval & sieval) == 0 && scauseval != 1);
csr_set(sie, SIE_SEIE | SIE_STIE);

  Since the resulting sequence does not seem to be deterministic, my
  guess is, that it has something to do with the communication of qemu's
  threads for the different cores.

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



Re: [PATCH v1 1/1] target/riscv: Remove atomic accesses to MIP CSR

2019-10-29 Thread Palmer Dabbelt

On Tue, 29 Oct 2019 03:49:23 PDT (-0700), alistai...@gmail.com wrote:

On Fri, Oct 18, 2019 at 7:44 PM Alistair Francis  wrote:


On Fri, Oct 18, 2019 at 9:51 AM Palmer Dabbelt  wrote:
>
> On Tue, 08 Oct 2019 15:04:18 PDT (-0700), Alistair Francis wrote:
> > Instead of relying on atomics to access the MIP register let's update
> > our helper function to instead just lock the IO mutex thread before
> > writing. This follows the same concept as used in PPC for handling
> > interrupts
> >
> > Signed-off-by: Alistair Francis 
> > ---
> >  target/riscv/cpu.c|  5 ++--
> >  target/riscv/cpu.h|  9 
> >  target/riscv/cpu_helper.c | 48 +++
> >  target/riscv/csr.c|  2 +-
> >  4 files changed, 21 insertions(+), 43 deletions(-)
> >
> > diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> > index f13e298a36..e09dd7aa23 100644
> > --- a/target/riscv/cpu.c
> > +++ b/target/riscv/cpu.c
> > @@ -224,8 +224,7 @@ static void riscv_cpu_dump_state(CPUState *cs, FILE *f, 
int flags)
> >  #ifndef CONFIG_USER_ONLY
> >  qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "mhartid ", env->mhartid);
> >  qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "mstatus ", env->mstatus);
> > -qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "mip ",
> > - (target_ulong)atomic_read(>mip));
> > +qemu_fprintf(f, " %s 0x%x\n", "mip ", env->mip);
> >  qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "mie ", env->mie);
> >  qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "mideleg ", env->mideleg);
> >  qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "medeleg ", env->medeleg);
> > @@ -275,7 +274,7 @@ static bool riscv_cpu_has_work(CPUState *cs)
> >   * Definition of the WFI instruction requires it to ignore the 
privilege
> >   * mode and delegation registers, but respect individual enables
> >   */
> > -return (atomic_read(>mip) & env->mie) != 0;
> > +return (env->mip & env->mie) != 0;
> >  #else
> >  return true;
> >  #endif
> > diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> > index 124ed33ee4..a71473b243 100644
> > --- a/target/riscv/cpu.h
> > +++ b/target/riscv/cpu.h
> > @@ -121,15 +121,6 @@ struct CPURISCVState {
> >  target_ulong mhartid;
> >  target_ulong mstatus;
> >
> > -/*
> > - * CAUTION! Unlike the rest of this struct, mip is accessed 
asynchonously
> > - * by I/O threads. It should be read with atomic_read. It should be 
updated
> > - * using riscv_cpu_update_mip with the iothread mutex held. The 
iothread
> > - * mutex must be held because mip must be consistent with the CPU 
inturrept
> > - * state. riscv_cpu_update_mip calls cpu_interrupt or 
cpu_reset_interrupt
> > - * wuth the invariant that CPU_INTERRUPT_HARD is set iff mip is 
non-zero.
> > - * mip is 32-bits to allow atomic_read on 32-bit hosts.
> > - */
> >  uint32_t mip;
> >  uint32_t miclaim;
> >
> > diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
> > index 87dd6a6ece..4334978c2e 100644
> > --- a/target/riscv/cpu_helper.c
> > +++ b/target/riscv/cpu_helper.c
> > @@ -19,6 +19,7 @@
> >
> >  #include "qemu/osdep.h"
> >  #include "qemu/log.h"
> > +#include "qemu/main-loop.h"
> >  #include "cpu.h"
> >  #include "exec/exec-all.h"
> >  #include "tcg-op.h"
> > @@ -38,7 +39,7 @@ static int riscv_cpu_local_irq_pending(CPURISCVState *env)
> >  {
> >  target_ulong mstatus_mie = get_field(env->mstatus, MSTATUS_MIE);
> >  target_ulong mstatus_sie = get_field(env->mstatus, MSTATUS_SIE);
> > -target_ulong pending = atomic_read(>mip) & env->mie;
> > +target_ulong pending = env->mip & env->mie;
> >  target_ulong mie = env->priv < PRV_M || (env->priv == PRV_M && 
mstatus_mie);
> >  target_ulong sie = env->priv < PRV_S || (env->priv == PRV_S && 
mstatus_sie);
> >  target_ulong irqs = (pending & ~env->mideleg & -mie) |
> > @@ -92,42 +93,29 @@ int riscv_cpu_claim_interrupts(RISCVCPU *cpu, uint32_t 
interrupts)
> >  }
> >  }
> >
> > -struct CpuAsyncInfo {
> > -uint32_t new_mip;
> > -};
> > -
> > -static void riscv_cpu_update_mip_irqs_async(CPUState *target_cpu_state,
> > -run_on_cpu_data data)
> > -{
> > -struct CpuAsyncInfo *info = (struct CpuAsyncInfo *) data.host_ptr;
> > -
> > -if (info->new_mip) {
> > -cpu_interrupt(target_cpu_state, CPU_INTERRUPT_HARD);
> > -} else {
> > -cpu_reset_interrupt(target_cpu_state, CPU_INTERRUPT_HARD);
> > -}
> > -
> > -g_free(info);
> > -}
> > -
> >  uint32_t riscv_cpu_update_mip(RISCVCPU *cpu, uint32_t mask, uint32_t value)
> >  {
> >  CPURISCVState *env = >env;
> >  CPUState *cs = CPU(cpu);
> > -struct CpuAsyncInfo *info;
> > -uint32_t old, new, cmp = atomic_read(>mip);
> > +uint32_t old = env->mip;
> > +bool locked = false;
> > +
> > +if (!qemu_mutex_iothread_locked()) {
> > +locked = true;
> > +

[PATCH] block/block-copy: fix s->copy_size for compressed cluster

2019-10-29 Thread Vladimir Sementsov-Ogievskiy
0e2402452f1f20429 allowed writes larger than cluster, but that's
unsupported for compressed write. Fix it.

Fixes: 0e2402452f1f20429
Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 block/block-copy.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/block/block-copy.c b/block/block-copy.c
index c39cc9cffe..79798a1567 100644
--- a/block/block-copy.c
+++ b/block/block-copy.c
@@ -109,9 +109,9 @@ BlockCopyState *block_copy_state_new(BdrvChild *source, 
BdrvChild *target,
 s->use_copy_range = false;
 s->copy_size = cluster_size;
 } else if (write_flags & BDRV_REQ_WRITE_COMPRESSED) {
-/* Compression is not supported for copy_range */
+/* Compression supports only cluster-size writes and no copy-range. */
 s->use_copy_range = false;
-s->copy_size = MAX(cluster_size, BLOCK_COPY_MAX_BUFFER);
+s->copy_size = cluster_size;
 } else {
 /*
  * copy_range does not respect max_transfer (it's a TODO), so we factor
-- 
2.21.0




RFC: New device for zero-copy VM memory access

2019-10-29 Thread geoff

Hi All,

Over the past week, I have been working to come up with a solution to 
the
memory transfer performance issues that hinder the Looking Glass 
Project.


Currently Looking Glass works by using the IVSHMEM shared memory device 
which
is fed by an application that captures the guest's video output. While 
this
works it is sub-optimal because we first have to perform a CPU copy of 
the
captured frame into shared RAM, and then back out again for display. 
Because
the destination buffers are allocated by closed proprietary code 
(DirectX, or

NVidia NvFBC) there is no way to have the frame placed directly into the
IVSHMEM shared ram.

This new device, currently named `introspection` (which needs a more 
suitable

name, porthole perhaps?), provides a means of translating guest physical
addresses to host virtual addresses, and finally to the host offsets in 
RAM for
file-backed memory guests. It does this by means of a simple protocol 
over a
unix socket (chardev) which is supplied the appropriate fd for the VM's 
system
RAM. The guest (in this case, Windows), when presented with the address 
of a
userspace buffer and size, will mlock the appropriate pages into RAM and 
pass

guest physical addresses to the virtual device.

This device and the windows driver have been designed in such a way that 
it's a
utility device for any project and/or application that could make use of 
it.
The PCI subsystem vendor and device ID are used to provide a means of 
device
identification in cases where multiple devices may be in use for 
differing
applications. This also allows one common driver to be used for any 
other

projects wishing to build on this device.

My ultimate goal is to get this to a state where it could be accepted 
upstream
into Qemu at which point Looking Glass would be modified to use it 
instead of

the IVSHMEM device.

My git repository with the new device can be found at:
https://github.com/gnif/qemu

The new device is:
https://github.com/gnif/qemu/blob/master/hw/misc/introspection.c

Looking Glass:
https://looking-glass.hostfission.com/

The windows driver, while working, needs some cleanup before the source 
is

published. I intend to maintain both this device and the windows driver
including producing a signed Windows 10 driver if Redhat are unwilling 
or

unable.

Kind Regards,
Geoffrey McRae

HostFission
https://hostfission.com



Re: [RFC v2 07/22] hw/pci: introduce pci_device_iommu_context()

2019-10-29 Thread David Gibson
On Thu, Oct 24, 2019 at 08:34:28AM -0400, Liu Yi L wrote:
> This patch adds pci_device_iommu_context() to get an iommu_context
> for a given device. A new callback is added in PCIIOMMUOps. Users
> who wants to listen to events issued by vIOMMU could use this new
> interface to get an iommu_context and register their own notifiers,
> then wait for notifications from vIOMMU. e.g. VFIO is the first user
> of it to listen to the PASID_ALLOC/PASID_BIND/CACHE_INV events and
> propagate the events to host.
> 
> Cc: Kevin Tian 
> Cc: Jacob Pan 
> Cc: Peter Xu 
> Cc: Eric Auger 
> Cc: Yi Sun 
> Cc: David Gibson 
> Signed-off-by: Liu Yi L 

Reviewed-by: David Gibson 

> ---
>  hw/pci/pci.c | 16 
>  include/hw/pci/pci.h |  5 +
>  2 files changed, 21 insertions(+)
> 
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index b5ce9ca..4e6af06 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -2625,6 +2625,22 @@ AddressSpace *pci_device_iommu_address_space(PCIDevice 
> *dev)
>  return _space_memory;
>  }
>  
> +IOMMUContext *pci_device_iommu_context(PCIDevice *dev)
> +{
> +PCIBus *bus = pci_get_bus(dev);
> +PCIBus *iommu_bus = bus;
> +
> +while (iommu_bus && !iommu_bus->iommu_ops && iommu_bus->parent_dev) {
> +iommu_bus = pci_get_bus(iommu_bus->parent_dev);
> +}
> +if (iommu_bus && iommu_bus->iommu_ops &&
> +iommu_bus->iommu_ops->get_iommu_context) {
> +return iommu_bus->iommu_ops->get_iommu_context(bus,
> +   iommu_bus->iommu_opaque, dev->devfn);
> +}
> +return NULL;
> +}
> +
>  void pci_setup_iommu(PCIBus *bus, const PCIIOMMUOps *ops, void *opaque)
>  {
>  bus->iommu_ops = ops;
> diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
> index d9fed8d..ccada47 100644
> --- a/include/hw/pci/pci.h
> +++ b/include/hw/pci/pci.h
> @@ -9,6 +9,8 @@
>  
>  #include "hw/pci/pcie.h"
>  
> +#include "hw/iommu/iommu.h"
> +
>  extern bool pci_available;
>  
>  /* PCI bus */
> @@ -484,9 +486,12 @@ typedef struct PCIIOMMUOps PCIIOMMUOps;
>  struct PCIIOMMUOps {
>  AddressSpace * (*get_address_space)(PCIBus *bus,
>  void *opaque, int32_t devfn);
> +IOMMUContext * (*get_iommu_context)(PCIBus *bus,
> +void *opaque, int32_t devfn);
>  };
>  
>  AddressSpace *pci_device_iommu_address_space(PCIDevice *dev);
> +IOMMUContext *pci_device_iommu_context(PCIDevice *dev);
>  void pci_setup_iommu(PCIBus *bus, const PCIIOMMUOps *iommu_ops, void 
> *opaque);
>  
>  static inline void

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


signature.asc
Description: PGP signature


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

2019-10-29 Thread David Gibson
On Thu, Oct 24, 2019 at 08:34:30AM -0400, Liu Yi L wrote:
> This patch adds pasid alloc/free notifiers for vfio-pci. It is
> supposed to be fired by vIOMMU. VFIO then sends PASID allocation
> or free request to host.
> 
> Cc: Kevin Tian 
> Cc: Jacob Pan 
> Cc: Peter Xu 
> Cc: Eric Auger 
> Cc: Yi Sun 
> Cc: David Gibson 
> Signed-off-by: Liu Yi L 
> ---
>  hw/vfio/common.c |  9 ++
>  hw/vfio/pci.c| 81 
> 
>  include/hw/iommu/iommu.h | 15 +
>  3 files changed, 105 insertions(+)
> 
> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> index d418527..e6ad21c 100644
> --- a/hw/vfio/common.c
> +++ b/hw/vfio/common.c
> @@ -1436,6 +1436,7 @@ static void vfio_disconnect_container(VFIOGroup *group)
>  if (QLIST_EMPTY(>group_list)) {
>  VFIOAddressSpace *space = container->space;
>  VFIOGuestIOMMU *giommu, *tmp;
> +VFIOIOMMUContext *giommu_ctx, *ctx;
>  
>  QLIST_REMOVE(container, next);
>  
> @@ -1446,6 +1447,14 @@ static void vfio_disconnect_container(VFIOGroup *group)
>  g_free(giommu);
>  }
>  
> +QLIST_FOREACH_SAFE(giommu_ctx, >iommu_ctx_list,
> +   iommu_ctx_next, ctx) {
> +iommu_ctx_notifier_unregister(giommu_ctx->iommu_ctx,
> +  _ctx->n);
> +QLIST_REMOVE(giommu_ctx, iommu_ctx_next);
> +g_free(giommu_ctx);
> +}
> +
>  trace_vfio_disconnect_container(container->fd);
>  close(container->fd);
>  g_free(container);
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index 12fac39..8721ff6 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -2699,11 +2699,80 @@ static void 
> vfio_unregister_req_notifier(VFIOPCIDevice *vdev)
>  vdev->req_enabled = false;
>  }
>  
> +static void vfio_register_iommu_ctx_notifier(VFIOPCIDevice *vdev,
> + IOMMUContext *iommu_ctx,
> + IOMMUCTXNotifyFn fn,
> + IOMMUCTXEvent event)
> +{
> +VFIOContainer *container = vdev->vbasedev.group->container;
> +VFIOIOMMUContext *giommu_ctx;
> +
> +giommu_ctx = g_malloc0(sizeof(*giommu_ctx));
> +giommu_ctx->container = container;
> +giommu_ctx->iommu_ctx = iommu_ctx;
> +QLIST_INSERT_HEAD(>iommu_ctx_list,
> +  giommu_ctx,
> +  iommu_ctx_next);
> +iommu_ctx_notifier_register(iommu_ctx,
> +_ctx->n,
> +fn,
> +event);
> +}
> +
> +static void vfio_iommu_pasid_alloc_notify(IOMMUCTXNotifier *n,
> +  IOMMUCTXEventData *event_data)
> +{
> +VFIOIOMMUContext *giommu_ctx = container_of(n, VFIOIOMMUContext, n);
> +VFIOContainer *container = giommu_ctx->container;
> +IOMMUCTXPASIDReqDesc *pasid_req =
> +  (IOMMUCTXPASIDReqDesc *) event_data->data;
> +struct vfio_iommu_type1_pasid_request req;
> +unsigned long argsz;
> +int pasid;
> +
> +argsz = sizeof(req);
> +req.argsz = argsz;
> +req.flag = VFIO_IOMMU_PASID_ALLOC;
> +req.min_pasid = pasid_req->min_pasid;
> +req.max_pasid = pasid_req->max_pasid;
> +
> +pasid = ioctl(container->fd, VFIO_IOMMU_PASID_REQUEST, );
> +if (pasid < 0) {
> +error_report("%s: %d, alloc failed", __func__, -errno);
> +}
> +pasid_req->alloc_result = pasid;

Altering the event data from the notifier doesn't make sense.  By
definition there can be multiple notifiers on the chain, so in that
case which one is responsible for updating the writable field?

> +}
> +
> +static void vfio_iommu_pasid_free_notify(IOMMUCTXNotifier *n,
> +  IOMMUCTXEventData *event_data)
> +{
> +VFIOIOMMUContext *giommu_ctx = container_of(n, VFIOIOMMUContext, n);
> +VFIOContainer *container = giommu_ctx->container;
> +IOMMUCTXPASIDReqDesc *pasid_req =
> +  (IOMMUCTXPASIDReqDesc *) event_data->data;
> +struct vfio_iommu_type1_pasid_request req;
> +unsigned long argsz;
> +int ret = 0;
> +
> +argsz = sizeof(req);
> +req.argsz = argsz;
> +req.flag = VFIO_IOMMU_PASID_FREE;
> +req.pasid = pasid_req->pasid;
> +
> +ret = ioctl(container->fd, VFIO_IOMMU_PASID_REQUEST, );
> +if (ret != 0) {
> +error_report("%s: %d, pasid %u free failed",
> +   __func__, -errno, (unsigned) pasid_req->pasid);
> +}
> +pasid_req->free_result = ret;

Same problem here.

> +}
> +
>  static void vfio_realize(PCIDevice *pdev, Error **errp)
>  {
>  VFIOPCIDevice *vdev = PCI_VFIO(pdev);
>  VFIODevice *vbasedev_iter;
>  VFIOGroup *group;
> +IOMMUContext *iommu_context;
>  char *tmp, *subsys, 

Re: [PATCH] nvme: fix NSSRS offset in CAP register

2019-10-29 Thread Max Reitz
On 23.10.19 09:33, Klaus Jensen wrote:
> Fix the offset of the NSSRS field the CAP register.
> 
> Signed-off-by: Klaus Jensen 
> Reported-by: Javier Gonzalez 
> ---
>  include/block/nvme.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Thanks; added John’s note and applied to my block branch:

https://github.com/XanClic/qemu/commits/block

Max



signature.asc
Description: OpenPGP digital signature


Re: [PATCH] iotests: Remove 130 from the "auto" group

2019-10-29 Thread Max Reitz
On 18.10.19 18:10, Thomas Huth wrote:
> Peter hit a "Could not open 'TEST_DIR/t.IMGFMT': Failed to get shared
> 'write' lock - Is another process using the image [TEST_DIR/t.IMGFMT]?"
> error with 130 already twice. Looks like this test is a little bit
> shaky, and currently nobody has a real clue what could be causing this
> issue, so for the time being, let's disable it from the "auto" group so
> that it does not gate the pull requests.
> 
> Signed-off-by: Thomas Huth 
> ---
>  tests/qemu-iotests/group | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Thanks, applied to my block branch:

https://github.com/XanClic/qemu/commits/block

Max



signature.asc
Description: OpenPGP digital signature


Re: [PATCH 0/1] dirty-bitmaps: remove deprecated autoload parameter

2019-10-29 Thread Max Reitz
On 25.09.19 01:01, John Snow wrote:
> I'm going to be honest, here. There's actually no real reason to remove
> this now, but we could, so I'm going to.
> 
> Also, in terms of the API serving as documentation, it's nicer to not
> pretend this is an option that does anything, so out it goes.
> 
> This will serve as a little smoke test to see what happens if we
> actually stop dropping features we claimed were deprecated.
> 
> John Snow (1):
>   dirty-bitmaps: remove deprecated autoload parameter
> 
>  qemu-deprecated.texi | 20 +++-
>  qapi/block-core.json |  6 +-
>  blockdev.c   |  6 --
>  3 files changed, 16 insertions(+), 16 deletions(-)

Cleaning up my inbox...  Was it your intention for someone other than
yourself to take this patch? :S

Max



signature.asc
Description: OpenPGP digital signature


Re: [PATCH] fw_cfg: Allow reboot-timeout=-1 again

2019-10-29 Thread Philippe Mathieu-Daudé

On 10/29/19 3:26 AM, Dr. David Alan Gilbert wrote:

* Laszlo Ersek (ler...@redhat.com) wrote:

On 10/25/19 18:57, Dr. David Alan Gilbert (git) wrote:

From: "Dr. David Alan Gilbert" 

Commit ee5d0f89de3e53cdb0dc added range checking on reboot-timeout
to only allow the range 0..65535; however both qemu and libvirt document
the special value -1  to mean don't reboot.
Allow it again.

Fixes: ee5d0f89de3e53cdb0dc ("fw_cfg: Fix -boot reboot-timeout error checking")
RH bz: https://bugzilla.redhat.com/show_bug.cgi?id=1765443
Signed-off-by: Dr. David Alan Gilbert 
---
  hw/nvram/fw_cfg.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index 7dc3ac378e..1a9ec44232 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -247,10 +247,11 @@ static void fw_cfg_reboot(FWCfgState *s)

  if (reboot_timeout) {
  rt_val = qemu_opt_get_number(opts, "reboot-timeout", -1);
+
  /* validate the input */
-if (rt_val < 0 || rt_val > 0x) {
+if (rt_val < -1 || rt_val > 0x) {
  error_report("reboot timeout is invalid,"
- "it should be a value between 0 and 65535");
+ "it should be a value between -1 and 65535");
  exit(1);
  }
  }



Ouch.

Here's the prototype of qemu_opt_get_number():


uint64_t qemu_opt_get_number(QemuOpts *opts, const char *name, uint64_t defval);


So, when we call it, here's what we actually do:

 rt_val = (int64_t)qemu_opt_get_number(opts, "reboot-timeout", 
(uint64_t)-1);
  ^
^^

The conversion to uint64_t is fine.

The conversion to int64_t is not great:


Otherwise, the new type is signed and the value cannot be represented
in it; either the result is implementation-defined or an
implementation-defined signal is raised.


I guess we're exploiting two's complement, as the implementation-defined
result. Not great. :)

Here's what I'd prefer:


diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index 7dc3ac378ee0..16413550a1da 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -237,7 +237,7 @@ static void fw_cfg_bootsplash(FWCfgState *s)
  static void fw_cfg_reboot(FWCfgState *s)
  {
  const char *reboot_timeout = NULL;
-int64_t rt_val = -1;
+uint64_t rt_val = -1;
  uint32_t rt_le32;

  /* get user configuration */
@@ -248,9 +248,9 @@ static void fw_cfg_reboot(FWCfgState *s)
  if (reboot_timeout) {
  rt_val = qemu_opt_get_number(opts, "reboot-timeout", -1);
  /* validate the input */
-if (rt_val < 0 || rt_val > 0x) {
+if (rt_val > 0x && rt_val != (uint64_t)-1) {
  error_report("reboot timeout is invalid,"
- "it should be a value between 0 and 65535");
+ "it should be a value between -1 and 65535");
  exit(1);
  }
  }


I think I'm fine with that as well; want to add a signed off and post?


(

The trick is that strtoull(), in

   qemu_opt_get_number()
 qemu_opt_get_number_helper()
   parse_option_number()
 qemu_strtou64()
   strtoull()

turns "-1" into (uint64_t)-1, which counts as a valid conversion, per
spec:


It's rather scary how much we rely on the grubby depths of the
implementations of our conversion routines.


If the subject sequence has the expected form and the value of /base/
is zero, the sequence of characters starting with the first digit is
interpreted as an integer constant according to the rules of 6.4.4.1.
If the subject sequence has the expected form and the value of /base/
is between 2 and 36, it is used as the base for conversion, ascribing
to each letter its value as given above. If the subject sequence
begins with a minus sign, the value resulting from the conversion is
negated (in the return type). A pointer to the final string is stored
in the object pointed to by /endptr/, provided that /endptr/ is not a
null pointer.


)

I don't insist though; if Phil is OK with the posted patch, I won't try
to block it.


I'm happy either way.


Thanks, queued with Laszlo's changes.

Regards,

Phil.



Re: [PATCH v7 05/11] qapi: add unplug primary event

2019-10-29 Thread Markus Armbruster
Jens Freimann  writes:

> On Tue, Oct 29, 2019 at 01:50:02PM +0100, Markus Armbruster wrote:
>>Jens Freimann  writes:
>>
>>> This event is emitted when we sent a request to unplug a
>>
>>Uh, "we sent a requestion [...] from the Guest OS"...  do you mean "we
>>received"?
>
> No, we sent a pci hotplug event to the guest by "pushing" the pcie attention
> button. So, it's QEMU requesting the unplug.

So if it's QEMU who does the sending, then saying "we sent [...] from
the Guest OS does not compute for me.  Do you mean "sent to"?

[...]




Re: [PATCH v7 05/11] qapi: add unplug primary event

2019-10-29 Thread Jens Freimann

On Tue, Oct 29, 2019 at 01:50:02PM +0100, Markus Armbruster wrote:

Jens Freimann  writes:


This event is emitted when we sent a request to unplug a


Uh, "we sent a requestion [...] from the Guest OS"...  do you mean "we
received"?


No, we sent a pci hotplug event to the guest by "pushing" the pcie attention
button. So, it's QEMU requesting the unplug.


+##
+# @UNPLUG_PRIMARY:
+#
+# Emitted from source side of a migration when migration state is
+# WAIT_UNPLUG. Device was unplugged by guest operating system.
+# Device resources in QEMU are kept on standby to be able to re-plug it in case
+# of migration failure.
+#
+# @device-id: QEMU device id of the unplugged device
+#
+# Since: 4.2
+#
+# Example:
+#   {"event": "UNPLUG_PRIMARY", "data": {"device-id": "hostdev0"} }
+#
+##
+{ 'event': 'UNPLUG_PRIMARY',
+  'data': { 'device-id': 'str' } }


Commit message might need a touch-up.  Regardless:
Acked-by: Markus Armbruster 


Thanks for the review!

regards,
Jens 





Re: [PATCH] MAINTAINERS: add more bitmap-related to Dirty Bitmaps section

2019-10-29 Thread John Snow



On 10/26/19 12:56 PM, Vladimir Sementsov-Ogievskiy wrote:
> Let's add bitmaps persistence qcow2 feature and postcopy bitmaps
> migration to Dirty Bitmaps section.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 

Reviewed-by: John Snow 

> ---
>  MAINTAINERS | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 556ce0bfe3..51f31b4011 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1829,6 +1829,8 @@ F: util/hbitmap.c
>  F: block/dirty-bitmap.c
>  F: include/qemu/hbitmap.h
>  F: include/block/dirty-bitmap.h
> +F: qcow2-bitmap.c
> +F: migration/block-dirty-bitmap.c
>  F: tests/test-hbitmap.c
>  F: docs/interop/bitmaps.rst
>  T: git https://github.com/jnsnow/qemu.git bitmaps
> 




Re: [PATCH v2 0/2] block/nvme: add support for write zeros and discard

2019-10-29 Thread John Snow



On 10/28/19 6:35 AM, Max Reitz wrote:
> On 13.09.19 15:36, Maxim Levitsky wrote:
>> This is the second part of the patches I prepared
>> for this driver back when I worked on mdev-nvme.
>>
>> V2: addressed review feedback, no major changes
>>
>> Best regards,
>>  Maxim Levitsky
>>
>> Maxim Levitsky (2):
>>   block/nvme: add support for write zeros
>>   block/nvme: add support for discard
>>
>>  block/nvme.c | 155 ++-
>>  block/trace-events   |   3 +
>>  include/block/nvme.h |  19 +-
>>  3 files changed, 175 insertions(+), 2 deletions(-)
> Thanks, fixed the indentation in nvme.h in patch 1, and applied to my
> block branch:
> 
> https://git.xanclic.moe/XanClic/qemu/commits/branch/block
> 
> For the record, I don’t think !!x has benefits over x != 0 and I
> personally prefer bool y = x over any of it. O:-)
> 

Well, that's even better :) For me, it's about making booleans obvious
as booleans and that's all.

--js




[Bug 1850378] [NEW] RISC-V unreliable IPIs

2019-10-29 Thread tm
Public bug reported:

I am working on a project with custom inter processor interrupts (IPIs) on the 
RISC-V virt machine.
After upgrading from version 3.1.0 to 4.1.0 which fixes a related issue 
(https://github.com/riscv/riscv-qemu/issues/132) I am able to use the CPU 
hotplug feature.

However, if I try to use IPIs for communication between two cores, the
wfi instruction behaves strangely. Either it does not return, or it
returns on timer interrupts, even though they are disabled. The code, I
use on one core to wait for an interrupt is the following.

csr_clear(sie, SIE_SEIE | SIE_STIE);
do {
wait_for_interrupt();
sipval = csr_read(sip);
sieval = csr_read(sie);
scauseval = csr_read(scause) & 0xFF;
/* only break if wfi returns for an software interrupt */
} while ((sipval & sieval) == 0 && scauseval != 1);
csr_set(sie, SIE_SEIE | SIE_STIE);

Since the resulting sequence does not seem to be deterministic, my guess
is, that it has something to do with the communication of qemu's threads
for the different cores.

** Affects: qemu
 Importance: Undecided
 Status: New


** Tags: riscv

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

Title:
  RISC-V unreliable IPIs

Status in QEMU:
  New

Bug description:
  I am working on a project with custom inter processor interrupts (IPIs) on 
the RISC-V virt machine.
  After upgrading from version 3.1.0 to 4.1.0 which fixes a related issue 
(https://github.com/riscv/riscv-qemu/issues/132) I am able to use the CPU 
hotplug feature.

  However, if I try to use IPIs for communication between two cores, the
  wfi instruction behaves strangely. Either it does not return, or it
  returns on timer interrupts, even though they are disabled. The code,
  I use on one core to wait for an interrupt is the following.

csr_clear(sie, SIE_SEIE | SIE_STIE);
do {
wait_for_interrupt();
sipval = csr_read(sip);
sieval = csr_read(sie);
scauseval = csr_read(scause) & 0xFF;
/* only break if wfi returns for an software interrupt */
} while ((sipval & sieval) == 0 && scauseval != 1);
csr_set(sie, SIE_SEIE | SIE_STIE);

  Since the resulting sequence does not seem to be deterministic, my
  guess is, that it has something to do with the communication of qemu's
  threads for the different cores.

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



Re: [PATCH v5 1/2] hw: rtc: Add Goldfish RTC device

2019-10-29 Thread Alistair Francis
On Fri, Oct 25, 2019 at 6:30 AM Anup Patel  wrote:
>
> This patch adds model for Google Goldfish virtual platform RTC device.
>
> We will be adding Goldfish RTC device to the QEMU RISC-V virt machine
> for providing real date-time to Guest Linux. The corresponding Linux
> driver for Goldfish RTC device is already available in upstream Linux.
>
> For now, VM migration support is available but untested for Goldfish RTC
> device. It will be hardened in-future when we implement VM migration for
> KVM RISC-V.
>
> Signed-off-by: Anup Patel 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  hw/rtc/Kconfig|   3 +
>  hw/rtc/Makefile.objs  |   1 +
>  hw/rtc/goldfish_rtc.c | 288 ++
>  hw/rtc/trace-events   |   4 +
>  include/hw/rtc/goldfish_rtc.h |  46 ++
>  5 files changed, 342 insertions(+)
>  create mode 100644 hw/rtc/goldfish_rtc.c
>  create mode 100644 include/hw/rtc/goldfish_rtc.h
>
> diff --git a/hw/rtc/Kconfig b/hw/rtc/Kconfig
> index 45daa8d655..bafe6ac2c9 100644
> --- a/hw/rtc/Kconfig
> +++ b/hw/rtc/Kconfig
> @@ -21,3 +21,6 @@ config MC146818RTC
>
>  config SUN4V_RTC
>  bool
> +
> +config GOLDFISH_RTC
> +bool
> diff --git a/hw/rtc/Makefile.objs b/hw/rtc/Makefile.objs
> index 8dc9fcd3a9..aa208d0d10 100644
> --- a/hw/rtc/Makefile.objs
> +++ b/hw/rtc/Makefile.objs
> @@ -11,3 +11,4 @@ common-obj-$(CONFIG_EXYNOS4) += exynos4210_rtc.o
>  obj-$(CONFIG_MC146818RTC) += mc146818rtc.o
>  common-obj-$(CONFIG_SUN4V_RTC) += sun4v-rtc.o
>  common-obj-$(CONFIG_ASPEED_SOC) += aspeed_rtc.o
> +common-obj-$(CONFIG_GOLDFISH_RTC) += goldfish_rtc.o
> diff --git a/hw/rtc/goldfish_rtc.c b/hw/rtc/goldfish_rtc.c
> new file mode 100644
> index 00..f71f6eaab0
> --- /dev/null
> +++ b/hw/rtc/goldfish_rtc.c
> @@ -0,0 +1,288 @@
> +/*
> + * Goldfish virtual platform RTC
> + *
> + * Copyright (C) 2019 Western Digital Corporation or its affiliates.
> + *
> + * For more details on Google Goldfish virtual platform refer:
> + * 
> https://android.googlesource.com/platform/external/qemu/+/master/docs/GOLDFISH-VIRTUAL-HARDWARE.TXT
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2 or later, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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 .
> + */
> +
> +#include "qemu/osdep.h"
> +#include "qemu-common.h"
> +#include "hw/rtc/goldfish_rtc.h"
> +#include "migration/vmstate.h"
> +#include "hw/irq.h"
> +#include "hw/qdev-properties.h"
> +#include "hw/sysbus.h"
> +#include "qemu/timer.h"
> +#include "sysemu/sysemu.h"
> +#include "qemu/cutils.h"
> +#include "qemu/log.h"
> +
> +#include "trace.h"
> +
> +#define RTC_TIME_LOW0x00
> +#define RTC_TIME_HIGH   0x04
> +#define RTC_ALARM_LOW   0x08
> +#define RTC_ALARM_HIGH  0x0c
> +#define RTC_IRQ_ENABLED 0x10
> +#define RTC_CLEAR_ALARM 0x14
> +#define RTC_ALARM_STATUS0x18
> +#define RTC_CLEAR_INTERRUPT 0x1c
> +
> +static void goldfish_rtc_update(GoldfishRTCState *s)
> +{
> +qemu_set_irq(s->irq, (s->irq_pending & s->irq_enabled) ? 1 : 0);
> +}
> +
> +static void goldfish_rtc_interrupt(void *opaque)
> +{
> +GoldfishRTCState *s = (GoldfishRTCState *)opaque;
> +
> +s->alarm_running = 0;
> +s->irq_pending = 1;
> +goldfish_rtc_update(s);
> +}
> +
> +static uint64_t goldfish_rtc_get_count(GoldfishRTCState *s)
> +{
> +return s->tick_offset + (uint64_t)qemu_clock_get_ns(rtc_clock);
> +}
> +
> +static void goldfish_rtc_clear_alarm(GoldfishRTCState *s)
> +{
> +timer_del(s->timer);
> +s->alarm_running = 0;
> +}
> +
> +static void goldfish_rtc_set_alarm(GoldfishRTCState *s)
> +{
> +uint64_t ticks = goldfish_rtc_get_count(s);
> +uint64_t event = s->alarm_next;
> +
> +if (event <= ticks) {
> +goldfish_rtc_clear_alarm(s);
> +goldfish_rtc_interrupt(s);
> +} else {
> +/*
> + * We should be setting timer expiry to:
> + * qemu_clock_get_ns(rtc_clock) + (event - ticks)
> + * but this is equivalent to:
> + * event - s->tick_offset
> + */
> +timer_mod(s->timer, event - s->tick_offset);
> +s->alarm_running = 1;
> +}
> +}
> +
> +static uint64_t goldfish_rtc_read(void *opaque, hwaddr offset,
> +  unsigned size)
> +{
> +GoldfishRTCState *s = opaque;
> +uint64_t r = 0;
> +
> +switch (offset) {
> +case RTC_TIME_LOW:
> +r = goldfish_rtc_get_count(s) & 0x;
> +

Re: [PATCH v5 0/2] RTC support for QEMU RISC-V virt machine

2019-10-29 Thread Alistair Francis
On Fri, Oct 25, 2019 at 6:28 AM Anup Patel  wrote:
>
> This series adds RTC device to QEMU RISC-V virt machine. We have
> selected Goldfish RTC device model for this. It's a pretty simple
> synthetic device with few MMIO registers and no dependency external
> clock. The driver for Goldfish RTC is already available in Linux so
> we just need to enable it in Kconfig for RISCV and also update Linux
> defconfigs.
>
> We have tested this series with Linux-5.4-rc4 plus defconfig changes
> available in 'goldfish_rtc_v2' branch of:
> https://github.com/avpatel/linux.git

@Peter Maydell this has been reviewed, do you mind taking this in you
next PR? I don't see a maintainer for hw/rtc.

Alistair

>
> Changes since v4:
>  - Fixed typo in trace event usage
>  - Moved goldfish_rtc.h to correct location
>
> Changes since v3:
>  - Address all nit comments from Alistair
>
> Changes since v2:
>  - Rebased on RTC code refactoring
>
> Changes since v1:
>  - Implemented VMState save/restore callbacks
>
> Anup Patel (2):
>   hw: rtc: Add Goldfish RTC device
>   riscv: virt: Use Goldfish RTC device
>
>  hw/riscv/Kconfig  |   1 +
>  hw/riscv/virt.c   |  15 ++
>  hw/rtc/Kconfig|   3 +
>  hw/rtc/Makefile.objs  |   1 +
>  hw/rtc/goldfish_rtc.c | 288 ++
>  hw/rtc/trace-events   |   4 +
>  include/hw/riscv/virt.h   |   2 +
>  include/hw/rtc/goldfish_rtc.h |  46 ++
>  8 files changed, 360 insertions(+)
>  create mode 100644 hw/rtc/goldfish_rtc.c
>  create mode 100644 include/hw/rtc/goldfish_rtc.h
>
> --
> 2.17.1
>



Re: [PATCH v7 1/4] block/replication.c: Ignore requests after failover

2019-10-29 Thread Max Reitz
On 24.10.19 16:25, Lukas Straub wrote:
> After failover the Secondary side of replication shouldn't change state, 
> because
> it now functions as our primary disk.
> 
> In replication_start, replication_do_checkpoint, replication_stop, ignore
> the request if current state is BLOCK_REPLICATION_DONE (sucessful failover) or
> BLOCK_REPLICATION_FAILOVER (failover in progres i.e. currently merging active
> and hidden images into the base image).
> 
> Signed-off-by: Lukas Straub 
> Reviewed-by: Zhang Chen 
> ---
>  block/replication.c | 35 ++-
>  1 file changed, 34 insertions(+), 1 deletion(-)

Acked-by: Max Reitz 



signature.asc
Description: OpenPGP digital signature


Re: [PATCH] fw_cfg: Allow reboot-timeout=-1 again

2019-10-29 Thread Dr. David Alan Gilbert
* Markus Armbruster (arm...@redhat.com) wrote:
> "Dr. David Alan Gilbert"  writes:
> 
> > * Markus Armbruster (arm...@redhat.com) wrote:
> >> "Dr. David Alan Gilbert (git)"  writes:
> >> 
> >> > From: "Dr. David Alan Gilbert" 
> >> >
> >> > Commit ee5d0f89de3e53cdb0dc added range checking on reboot-timeout
> >> > to only allow the range 0..65535; however both qemu and libvirt document
> >> > the special value -1  to mean don't reboot.
> >> > Allow it again.
> >> >
> >> > Fixes: ee5d0f89de3e53cdb0dc ("fw_cfg: Fix -boot reboot-timeout error 
> >> > checking")
> >> > RH bz: https://bugzilla.redhat.com/show_bug.cgi?id=1765443
> >> > Signed-off-by: Dr. David Alan Gilbert 
> >> > ---
> >> >  hw/nvram/fw_cfg.c | 5 +++--
> >> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
> >> > index 7dc3ac378e..1a9ec44232 100644
> >> > --- a/hw/nvram/fw_cfg.c
> >> > +++ b/hw/nvram/fw_cfg.c
> >> > @@ -247,10 +247,11 @@ static void fw_cfg_reboot(FWCfgState *s)
> >> >  
> >> >  if (reboot_timeout) {
> >> >  rt_val = qemu_opt_get_number(opts, "reboot-timeout", -1);
> >> > +
> >> >  /* validate the input */
> >> > -if (rt_val < 0 || rt_val > 0x) {
> >> > +if (rt_val < -1 || rt_val > 0x) {
> >> >  error_report("reboot timeout is invalid,"
> >> > - "it should be a value between 0 and 65535");
> >> > + "it should be a value between -1 and 65535");
> >> >  exit(1);
> >> >  }
> >> >  }
> >> 
> >> Semantic conflict with "PATCH] qemu-options.hx: Update for
> >> reboot-timeout parameter", Message-Id:
> >> <20191015151451.727323-1-h...@redhat.com>.
> >
> > Thanks for spotting that.
> > I think Han and also submitted patches to review it from libvirt
> > and it wasn't obvious what to do.  (Cc'd Han in).
> >
> >> I'm too tired right now to risk an opinion on which one we want.
> >
> > As is everyone else !  The problem here is that its documented
> > as a valid thing to do, and libvirt does it, and you might have 
> > a current XML file that did it.  Now I think you could change libvirt
> > to omit the reboot-timeout parameter if it was called with -1.
> >
> > So given its a documented thing in both qemu and libvirt xml
> > if we want to remove it then it sohuld be deprecated properly - but it's
> > already broken.
> 
> Since commit ee5d0f89d, v4.0.0.
> 
> If that commit had not made it into a release, we'd certainly treat the
> loss of "-1 means don't reboot" as regression.
> 
> But it has.  We can treat it as a regression anyway.  We can also
> declare "ship has sailed".
> 
> I'm leaning towads the former.
> 
> If we restore "-1 means don't reboot", then I don't see a need to
> deprecate it.  Just keep it.
> 
> What do you think?

That's also my view; especially since the problem seems to be an easy
fix.

Dave

--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK




Re: [PATCH v7 05/11] qapi: add unplug primary event

2019-10-29 Thread Markus Armbruster
Jens Freimann  writes:

> This event is emitted when we sent a request to unplug a

Uh, "we sent a requestion [...] from the Guest OS"...  do you mean "we
received"?

> failover primary device from the Guest OS and it includes the
> device id of the primary device.
>
> Signed-off-by: Jens Freimann 
> ---
>  qapi/migration.json | 19 +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/qapi/migration.json b/qapi/migration.json
> index 82feb5bd39..e9e7a97c03 100644
> --- a/qapi/migration.json
> +++ b/qapi/migration.json
> @@ -1448,3 +1448,22 @@
>  # Since: 3.0
>  ##
>  { 'command': 'migrate-pause', 'allow-oob': true }
> +
> +##
> +# @UNPLUG_PRIMARY:
> +#
> +# Emitted from source side of a migration when migration state is
> +# WAIT_UNPLUG. Device was unplugged by guest operating system.
> +# Device resources in QEMU are kept on standby to be able to re-plug it in 
> case
> +# of migration failure.
> +#
> +# @device-id: QEMU device id of the unplugged device
> +#
> +# Since: 4.2
> +#
> +# Example:
> +#   {"event": "UNPLUG_PRIMARY", "data": {"device-id": "hostdev0"} }
> +#
> +##
> +{ 'event': 'UNPLUG_PRIMARY',
> +  'data': { 'device-id': 'str' } }

Commit message might need a touch-up.  Regardless:
Acked-by: Markus Armbruster 




Re: [PATCH v7 06/11] qapi: add failover negotiated event

2019-10-29 Thread Markus Armbruster
Jens Freimann  writes:

> This event is sent to let libvirt know that VIRTIO_NET_F_STANDBY feature
> is enabled. The primary device this virtio-net (standby) device is
> associated with, is now hotplugged by the virtio-net device.
>
> Signed-off-by: Jens Freimann 
> ---
>  qapi/net.json | 19 +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/qapi/net.json b/qapi/net.json
> index 728990f4fb..ea64f7 100644
> --- a/qapi/net.json
> +++ b/qapi/net.json
> @@ -737,3 +737,22 @@
>  ##
>  { 'command': 'announce-self', 'boxed': true,
>'data' : 'AnnounceParameters'}
> +
> +##
> +# @FAILOVER_NEGOTIATED:
> +#
> +# Emitted when VIRTIO_NET_F_STANDBY was enabled during feature negotiation.
> +# Failover primary devices which were hidden (not hotplugged when requested)
> +# before will now be hotplugged by the virtio-net standby device.
> +#
> +# device-id: QEMU device id of the unplugged device
> +# Since: 4.2
> +#
> +# Example:
> +#
> +# <- { "event": "FAILOVER_NEGOTIATED",
> +#  "data": "net1" }
> +#
> +##
> +{ 'event': 'FAILOVER_NEGOTIATED',
> +  'data': {'device-id': 'str'} }

Acked-by: Markus Armbruster 




Re: [RFC 0/3] block/file-posix: Work around XFS bug

2019-10-29 Thread Max Reitz
On 29.10.19 13:19, Vladimir Sementsov-Ogievskiy wrote:
> 29.10.2019 15:11, Max Reitz wrote:
>> On 29.10.19 13:05, Vladimir Sementsov-Ogievskiy wrote:
>>> 29.10.2019 14:55, Max Reitz wrote:
 On 29.10.19 12:48, Vladimir Sementsov-Ogievskiy wrote:
> 29.10.2019 11:50, Max Reitz wrote:
>> On 28.10.19 12:25, Vladimir Sementsov-Ogievskiy wrote:
>>> 28.10.2019 14:04, Kevin Wolf wrote:
 Am 27.10.2019 um 13:35 hat Stefan Hajnoczi geschrieben:
> On Fri, Oct 25, 2019 at 11:58:46AM +0200, Max Reitz wrote:
>>
>> [...]
>>
>> (3) Drop handle_alloc_space(), i.e. revert c8bb23cbdbe32f.
>> To my knowledge I’m the only one who has provided any 
>> benchmarks for
>> this commit, and even then I was a bit skeptical because it 
>> performs
>> well in some cases and bad in others.  I concluded that it’s
>> probably worth it because the “some cases” are more likely 
>> to occur.
>>
>> Now we have this problem of corruption here (granted due to 
>> a bug in
>> the XFS driver), and another report of massively degraded
>> performance on ppc64
>> (https://bugzilla.redhat.com/show_bug.cgi?id=1745823 – 
>> sorry, a
>> private BZ; I hate that :-/  The report is about 40 % worse
>> performance for an in-guest fio write benchmark.)
>>
>> So I have to ask the question about what the justification 
>> for
>> keeping c8bb23cbdbe32f is.  How much does performance 
>> increase with
>> it actually?  (On non-(ppc64+XFS) machines, obviously)
>>
>> Advantages:
>> + Trivial
>> + No layering violations
>> + We wouldn’t need to keep track of whether the kernel bug 
>> has been
>>   fixed or not
>> + Fixes the ppc64+XFS performance problem
>>
>> Disadvantages:
>> - Reverts cluster allocation performance to 
>> pre-c8bb23cbdbe32f
>>   levels, whatever that means
>
> My favorite because it is clean and simple, but Vladimir has a valid
> use-case for requiring this performance optimization so reverting 
> isn't
> an option.

 Vladimir also said that qcow2 subclusters would probably also solve his
 problem, so maybe reverting and applying the subcluster patches instead
 is a possible solution, too?
>>>
>>> I'm not sure about ssd case, it may need write-zero optimization anyway.
>>
>> What exactly do you need?  Do you actually need to write zeroes (e.g.
>> because you’re storing images on block devices) or would it be
>> sufficient to just drop the COW areas when bdrv_has_zero_init() and
>> bdrv_has_zero_init_truncate() are true?
>
> Hmm, what do you mean? We need to zero COW areas. So, original way is to
> write real zeroes, optimized way is fallocate.. What do you mean by drop?
> Mark sublusters as zeroes by metadata?

 Why do you need to zero COW areas?  For normal files, any data will read
 as zero if you didn’t write anything there.
>>>
>>> Hmm, but when allocating new cluster in qcow2, it's not guaranteed to be 
>>> zero,
>>> as it may be reused previously allocated cluster..
>>
>> Hm, right.  We could special-case something for beyond the EOF, but I
>> don’t know whether that really makes it better.
>>
>> OTOH, maybe allocations at the EOF are the real bottleneck.  Reusing
>> existing clusters should be rare enough that maybe the existing code
>> which explicitly writes zeroes is sufficient.
> 
> But, as I understand pre-EOF fallocates are safe in xfs? So, we may just drop 
> calling
> fallocate past-EOF (it's zero anyway) and do fallocate pre-EOF (it's safe) ?

But probably slow still.  And there’s the question of how much
complexity we want to heap onto this.

Max



signature.asc
Description: OpenPGP digital signature


Re: [RFC 0/3] block/file-posix: Work around XFS bug

2019-10-29 Thread Vladimir Sementsov-Ogievskiy
29.10.2019 15:11, Max Reitz wrote:
> On 29.10.19 13:05, Vladimir Sementsov-Ogievskiy wrote:
>> 29.10.2019 14:55, Max Reitz wrote:
>>> On 29.10.19 12:48, Vladimir Sementsov-Ogievskiy wrote:
 29.10.2019 11:50, Max Reitz wrote:
> On 28.10.19 12:25, Vladimir Sementsov-Ogievskiy wrote:
>> 28.10.2019 14:04, Kevin Wolf wrote:
>>> Am 27.10.2019 um 13:35 hat Stefan Hajnoczi geschrieben:
 On Fri, Oct 25, 2019 at 11:58:46AM +0200, Max Reitz wrote:
>
> [...]
>
> (3) Drop handle_alloc_space(), i.e. revert c8bb23cbdbe32f.
> To my knowledge I’m the only one who has provided any 
> benchmarks for
> this commit, and even then I was a bit skeptical because it 
> performs
> well in some cases and bad in others.  I concluded that it’s
> probably worth it because the “some cases” are more likely to 
> occur.
>
> Now we have this problem of corruption here (granted due to a 
> bug in
> the XFS driver), and another report of massively degraded
> performance on ppc64
> (https://bugzilla.redhat.com/show_bug.cgi?id=1745823 – sorry, 
> a
> private BZ; I hate that :-/  The report is about 40 % worse
> performance for an in-guest fio write benchmark.)
>
> So I have to ask the question about what the justification for
> keeping c8bb23cbdbe32f is.  How much does performance 
> increase with
> it actually?  (On non-(ppc64+XFS) machines, obviously)
>
> Advantages:
> + Trivial
> + No layering violations
> + We wouldn’t need to keep track of whether the kernel bug 
> has been
>   fixed or not
> + Fixes the ppc64+XFS performance problem
>
> Disadvantages:
> - Reverts cluster allocation performance to pre-c8bb23cbdbe32f
>   levels, whatever that means

 My favorite because it is clean and simple, but Vladimir has a valid
 use-case for requiring this performance optimization so reverting isn't
 an option.
>>>
>>> Vladimir also said that qcow2 subclusters would probably also solve his
>>> problem, so maybe reverting and applying the subcluster patches instead
>>> is a possible solution, too?
>>
>> I'm not sure about ssd case, it may need write-zero optimization anyway.
>
> What exactly do you need?  Do you actually need to write zeroes (e.g.
> because you’re storing images on block devices) or would it be
> sufficient to just drop the COW areas when bdrv_has_zero_init() and
> bdrv_has_zero_init_truncate() are true?

 Hmm, what do you mean? We need to zero COW areas. So, original way is to
 write real zeroes, optimized way is fallocate.. What do you mean by drop?
 Mark sublusters as zeroes by metadata?
>>>
>>> Why do you need to zero COW areas?  For normal files, any data will read
>>> as zero if you didn’t write anything there.
>>
>> Hmm, but when allocating new cluster in qcow2, it's not guaranteed to be 
>> zero,
>> as it may be reused previously allocated cluster..
> 
> Hm, right.  We could special-case something for beyond the EOF, but I
> don’t know whether that really makes it better.
> 
> OTOH, maybe allocations at the EOF are the real bottleneck.  Reusing
> existing clusters should be rare enough that maybe the existing code
> which explicitly writes zeroes is sufficient.

But, as I understand pre-EOF fallocates are safe in xfs? So, we may just drop 
calling
fallocate past-EOF (it's zero anyway) and do fallocate pre-EOF (it's safe) ?
(the only special case is intersecting EOF.. so better is keep file length at 
cluster-size
boundary, truncating on exit)

> 
>>>
 But still we'll have COW areas in subcluster, and we'll need to directly 
 zero
 them.. And fallocate will most probably be faster on ssd ext4 case..

>
> I’m asking because Dave Chinner said
> (https://bugzilla.redhat.com/show_bug.cgi?id=1765547#c7) that
> fallocate() is always slow at least with aio=native because it needs to
> wait for all concurrent AIO writes to finish, and so it causes the AIO
> pipeline to stall.
>
> (He suggested using XFS extent size hints to get the same effect as
> write-zeroes for free, basically, but I don’t know whether that’s really
> useful to us; as unallocated areas on XFS read back as zero anyway.)
>
>>> We already have some cases where the existing handle_alloc_space()
>>> causes performance to actually become worse, and serialising requests as
>>> a workaround isn't going to make performance any better. So even on
>>> these grounds, keeping commit c8bb23cbdbe32f is questionable.
>>>
>>
>> 

Re: [PATCH v6 06/11] qapi: add failover negotiated event

2019-10-29 Thread Markus Armbruster
Jens Freimann  writes:

> On Fri, Oct 25, 2019 at 04:03:54PM +0200, Markus Armbruster wrote:
>>Bear with me, I know next to nothing about failover.
>>
>>Jens Freimann  writes:
>>
>>> This event is sent to let libvirt know that VIRTIO_NET_F_STANDBY feature
>>> was enabled. The primary device this virtio-net device is associated
>>> with, will now be hotplugged via qdev_device_add().
>>
>>Passive voice deftly avoids telling the reader who will do the
>>hot-plugging.  Intentional?
>
> Not really, it's in the comment to the event. The hotplug will be
> done by the virtio-net device code that activates the feature, in
> virtio_net_set_features().

If you need to respin, I suggest to work this bit of information into
the commit message.

>>> Signed-off-by: Jens Freimann 
>>> Acked-by: Cornelia Huck 
>>> ---
>>>  qapi/net.json | 19 +++
>>>  1 file changed, 19 insertions(+)
>>>
>>> diff --git a/qapi/net.json b/qapi/net.json
>>> index 728990f4fb..ea64f7 100644
>>> --- a/qapi/net.json
>>> +++ b/qapi/net.json
>>> @@ -737,3 +737,22 @@
>>>  ##
>>>  { 'command': 'announce-self', 'boxed': true,
>>>'data' : 'AnnounceParameters'}
>>> +
>>> +##
>>> +# @FAILOVER_NEGOTIATED:
>>> +#
>>> +# Emitted when VIRTIO_NET_F_STANDBY was enabled during feature negotiation.
>>> +# Failover primary devices which were hidden (not hotplugged when 
>>> requested)
>>> +# before will now be hotplugged by the virtio-net standby device.
>>> +#
>>> +# device-id: QEMU device id of the unplugged device
>>
>>@device-id is new since v5.
>>
>>A quick skim of
>>https://www.kernel.org/doc/html/latest/networking/net_failover.html
>>tells me there are three devices involved: master, primary slave,
>>standby slave.  Which one is @device-id?  Or am I confused?
>
> Yes, the device-id is new and it's the device-id of the standby (i.e.
> virtio-net) device.

Would working this into the doc comment make it clearer?




Re: [RFC 0/3] block/file-posix: Work around XFS bug

2019-10-29 Thread Max Reitz
On 29.10.19 13:05, Vladimir Sementsov-Ogievskiy wrote:
> 29.10.2019 14:55, Max Reitz wrote:
>> On 29.10.19 12:48, Vladimir Sementsov-Ogievskiy wrote:
>>> 29.10.2019 11:50, Max Reitz wrote:
 On 28.10.19 12:25, Vladimir Sementsov-Ogievskiy wrote:
> 28.10.2019 14:04, Kevin Wolf wrote:
>> Am 27.10.2019 um 13:35 hat Stefan Hajnoczi geschrieben:
>>> On Fri, Oct 25, 2019 at 11:58:46AM +0200, Max Reitz wrote:

 [...]

 (3) Drop handle_alloc_space(), i.e. revert c8bb23cbdbe32f.
To my knowledge I’m the only one who has provided any 
 benchmarks for
this commit, and even then I was a bit skeptical because it 
 performs
well in some cases and bad in others.  I concluded that it’s
probably worth it because the “some cases” are more likely to 
 occur.

Now we have this problem of corruption here (granted due to a 
 bug in
the XFS driver), and another report of massively degraded
performance on ppc64
(https://bugzilla.redhat.com/show_bug.cgi?id=1745823 – sorry, a
private BZ; I hate that :-/  The report is about 40 % worse
performance for an in-guest fio write benchmark.)

So I have to ask the question about what the justification for
keeping c8bb23cbdbe32f is.  How much does performance increase 
 with
it actually?  (On non-(ppc64+XFS) machines, obviously)

Advantages:
+ Trivial
+ No layering violations
+ We wouldn’t need to keep track of whether the kernel bug has 
 been
  fixed or not
+ Fixes the ppc64+XFS performance problem

Disadvantages:
- Reverts cluster allocation performance to pre-c8bb23cbdbe32f
  levels, whatever that means
>>>
>>> My favorite because it is clean and simple, but Vladimir has a valid
>>> use-case for requiring this performance optimization so reverting isn't
>>> an option.
>>
>> Vladimir also said that qcow2 subclusters would probably also solve his
>> problem, so maybe reverting and applying the subcluster patches instead
>> is a possible solution, too?
>
> I'm not sure about ssd case, it may need write-zero optimization anyway.

 What exactly do you need?  Do you actually need to write zeroes (e.g.
 because you’re storing images on block devices) or would it be
 sufficient to just drop the COW areas when bdrv_has_zero_init() and
 bdrv_has_zero_init_truncate() are true?
>>>
>>> Hmm, what do you mean? We need to zero COW areas. So, original way is to
>>> write real zeroes, optimized way is fallocate.. What do you mean by drop?
>>> Mark sublusters as zeroes by metadata?
>>
>> Why do you need to zero COW areas?  For normal files, any data will read
>> as zero if you didn’t write anything there.
> 
> Hmm, but when allocating new cluster in qcow2, it's not guaranteed to be zero,
> as it may be reused previously allocated cluster..

Hm, right.  We could special-case something for beyond the EOF, but I
don’t know whether that really makes it better.

OTOH, maybe allocations at the EOF are the real bottleneck.  Reusing
existing clusters should be rare enough that maybe the existing code
which explicitly writes zeroes is sufficient.

>>
>>> But still we'll have COW areas in subcluster, and we'll need to directly 
>>> zero
>>> them.. And fallocate will most probably be faster on ssd ext4 case..
>>>

 I’m asking because Dave Chinner said
 (https://bugzilla.redhat.com/show_bug.cgi?id=1765547#c7) that
 fallocate() is always slow at least with aio=native because it needs to
 wait for all concurrent AIO writes to finish, and so it causes the AIO
 pipeline to stall.

 (He suggested using XFS extent size hints to get the same effect as
 write-zeroes for free, basically, but I don’t know whether that’s really
 useful to us; as unallocated areas on XFS read back as zero anyway.)

>> We already have some cases where the existing handle_alloc_space()
>> causes performance to actually become worse, and serialising requests as
>> a workaround isn't going to make performance any better. So even on
>> these grounds, keeping commit c8bb23cbdbe32f is questionable.
>>
>
> Can keeping handle_alloc_space under some config option be an option?

 Hm.  A config option is weird if you’re the only one who’s going to
 enable it.  But other than that I don’t have anything against it.

>>>
>>> It's just a bit easier for us to maintain config option, than out-of-tree 
>>> patch.
>>> On the other hand, it's not a real problem to maintain this one patch in 
>>> separate.
>>> It may return again to the tree, when XFS bug fixed.

Re: [PATCH] fw_cfg: Allow reboot-timeout=-1 again

2019-10-29 Thread Markus Armbruster
"Dr. David Alan Gilbert"  writes:

> * Markus Armbruster (arm...@redhat.com) wrote:
>> "Dr. David Alan Gilbert (git)"  writes:
>> 
>> > From: "Dr. David Alan Gilbert" 
>> >
>> > Commit ee5d0f89de3e53cdb0dc added range checking on reboot-timeout
>> > to only allow the range 0..65535; however both qemu and libvirt document
>> > the special value -1  to mean don't reboot.
>> > Allow it again.
>> >
>> > Fixes: ee5d0f89de3e53cdb0dc ("fw_cfg: Fix -boot reboot-timeout error 
>> > checking")
>> > RH bz: https://bugzilla.redhat.com/show_bug.cgi?id=1765443
>> > Signed-off-by: Dr. David Alan Gilbert 
>> > ---
>> >  hw/nvram/fw_cfg.c | 5 +++--
>> >  1 file changed, 3 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
>> > index 7dc3ac378e..1a9ec44232 100644
>> > --- a/hw/nvram/fw_cfg.c
>> > +++ b/hw/nvram/fw_cfg.c
>> > @@ -247,10 +247,11 @@ static void fw_cfg_reboot(FWCfgState *s)
>> >  
>> >  if (reboot_timeout) {
>> >  rt_val = qemu_opt_get_number(opts, "reboot-timeout", -1);
>> > +
>> >  /* validate the input */
>> > -if (rt_val < 0 || rt_val > 0x) {
>> > +if (rt_val < -1 || rt_val > 0x) {
>> >  error_report("reboot timeout is invalid,"
>> > - "it should be a value between 0 and 65535");
>> > + "it should be a value between -1 and 65535");
>> >  exit(1);
>> >  }
>> >  }
>> 
>> Semantic conflict with "PATCH] qemu-options.hx: Update for
>> reboot-timeout parameter", Message-Id:
>> <20191015151451.727323-1-h...@redhat.com>.
>
> Thanks for spotting that.
> I think Han and also submitted patches to review it from libvirt
> and it wasn't obvious what to do.  (Cc'd Han in).
>
>> I'm too tired right now to risk an opinion on which one we want.
>
> As is everyone else !  The problem here is that its documented
> as a valid thing to do, and libvirt does it, and you might have 
> a current XML file that did it.  Now I think you could change libvirt
> to omit the reboot-timeout parameter if it was called with -1.
>
> So given its a documented thing in both qemu and libvirt xml
> if we want to remove it then it sohuld be deprecated properly - but it's
> already broken.

Since commit ee5d0f89d, v4.0.0.

If that commit had not made it into a release, we'd certainly treat the
loss of "-1 means don't reboot" as regression.

But it has.  We can treat it as a regression anyway.  We can also
declare "ship has sailed".

I'm leaning towads the former.

If we restore "-1 means don't reboot", then I don't see a need to
deprecate it.  Just keep it.

What do you think?




Re: [PATCH v5 1/3] tests/vm: netbsd autoinstall, using serial console

2019-10-29 Thread Alex Bennée


Thomas Huth  writes:

> On 18/10/2019 20.17, Eduardo Habkost wrote:
>> From: Gerd Hoffmann 
>>
>> Instead of fetching the prebuilt image from patchew download the install
>> iso and prepare the image locally.  Install to disk, using the serial
>> console.  Create qemu user, configure ssh login.  Install packages
>> needed for qemu builds.
>>
>> Signed-off-by: Gerd Hoffmann 
>> Reviewed-by: Kamil Rytarowski 
>> Tested-by: Thomas Huth 
>> [ehabkost: rebased to latest qemu.git master]
>> Signed-off-by: Eduardo Habkost 
>> ---
>>  tests/vm/netbsd | 189 +---
>>  1 file changed, 179 insertions(+), 10 deletions(-)
>>
>> diff --git a/tests/vm/netbsd b/tests/vm/netbsd
>> index ee9eaeab50..49a99477f4 100755
>> --- a/tests/vm/netbsd
>> +++ b/tests/vm/netbsd
>> @@ -2,10 +2,11 @@
>>  #
>>  # NetBSD VM image
>>  #
>> -# Copyright 2017 Red Hat Inc.
>> +# Copyright 2017-2019 Red Hat Inc.
>>  #
>>  # Authors:
>>  #  Fam Zheng 
>> +#  Gerd Hoffmann 
>>  #
>>  # This code is licensed under the GPL version 2 or later.  See
>>  # the COPYING file in the top-level directory.
>> @@ -13,30 +14,198 @@
>>
>>  import os
>>  import sys
>> +import time
>>  import subprocess
>>  import basevm
>>
>>  class NetBSDVM(basevm.BaseVM):
>>  name = "netbsd"
>>  arch = "x86_64"
>> +
>> +link = 
>> "https://cdn.netbsd.org/pub/NetBSD/NetBSD-8.0/images/NetBSD-8.0-amd64.iso;
>
> I'd like to suggest to go immediately with 8.1 instead of 8.0. I tested
> it and it worked for me out-of-the-box, without further modifications.

*Sigh* I had to drop this from my PR after it broke again. It looked
 like it was getting stuck on the installer waiting for something. I had
 it working at one point so I'm not sure why it's not working again.

The rest of the patches are merged now though.

>
>> +
>> +if os.path.exists(img):
>> +os.remove(img)
>
> These two lines have been removed recently with commit
> fcd2060e8efff83b7bdef04323077f87e011fdc4 ... please drop them from the
> patch.
>
>  Thanks,
>   Thomas


--
Alex Bennée



Re: [PATCH v1 1/1] target/riscv: Remove atomic accesses to MIP CSR

2019-10-29 Thread Alex Bennée


Alistair Francis  writes:

> Instead of relying on atomics to access the MIP register let's update
> our helper function to instead just lock the IO mutex thread before
> writing. This follows the same concept as used in PPC for handling
> interrupts
>
> Signed-off-by: Alistair Francis 

Acked-by: Alex Bennée 

Generally anything that can trigger an IRQ or IO type activity should be
locking with the BQL. MMIO accesses are automatically locked by the
memory sub-system but you need to take special care with system
registers that have cross vCPU effects.

> ---
>  target/riscv/cpu.c|  5 ++--
>  target/riscv/cpu.h|  9 
>  target/riscv/cpu_helper.c | 48 +++
>  target/riscv/csr.c|  2 +-
>  4 files changed, 21 insertions(+), 43 deletions(-)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index f13e298a36..e09dd7aa23 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -224,8 +224,7 @@ static void riscv_cpu_dump_state(CPUState *cs, FILE *f, 
> int flags)
>  #ifndef CONFIG_USER_ONLY
>  qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "mhartid ", env->mhartid);
>  qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "mstatus ", env->mstatus);
> -qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "mip ",
> - (target_ulong)atomic_read(>mip));
> +qemu_fprintf(f, " %s 0x%x\n", "mip ", env->mip);
>  qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "mie ", env->mie);
>  qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "mideleg ", env->mideleg);
>  qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "medeleg ", env->medeleg);
> @@ -275,7 +274,7 @@ static bool riscv_cpu_has_work(CPUState *cs)
>   * Definition of the WFI instruction requires it to ignore the privilege
>   * mode and delegation registers, but respect individual enables
>   */
> -return (atomic_read(>mip) & env->mie) != 0;
> +return (env->mip & env->mie) != 0;
>  #else
>  return true;
>  #endif
> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> index 124ed33ee4..a71473b243 100644
> --- a/target/riscv/cpu.h
> +++ b/target/riscv/cpu.h
> @@ -121,15 +121,6 @@ struct CPURISCVState {
>  target_ulong mhartid;
>  target_ulong mstatus;
>
> -/*
> - * CAUTION! Unlike the rest of this struct, mip is accessed asynchonously
> - * by I/O threads. It should be read with atomic_read. It should be 
> updated
> - * using riscv_cpu_update_mip with the iothread mutex held. The iothread
> - * mutex must be held because mip must be consistent with the CPU 
> inturrept
> - * state. riscv_cpu_update_mip calls cpu_interrupt or cpu_reset_interrupt
> - * wuth the invariant that CPU_INTERRUPT_HARD is set iff mip is non-zero.
> - * mip is 32-bits to allow atomic_read on 32-bit hosts.
> - */
>  uint32_t mip;
>  uint32_t miclaim;
>
> diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
> index 87dd6a6ece..4334978c2e 100644
> --- a/target/riscv/cpu_helper.c
> +++ b/target/riscv/cpu_helper.c
> @@ -19,6 +19,7 @@
>
>  #include "qemu/osdep.h"
>  #include "qemu/log.h"
> +#include "qemu/main-loop.h"
>  #include "cpu.h"
>  #include "exec/exec-all.h"
>  #include "tcg-op.h"
> @@ -38,7 +39,7 @@ static int riscv_cpu_local_irq_pending(CPURISCVState *env)
>  {
>  target_ulong mstatus_mie = get_field(env->mstatus, MSTATUS_MIE);
>  target_ulong mstatus_sie = get_field(env->mstatus, MSTATUS_SIE);
> -target_ulong pending = atomic_read(>mip) & env->mie;
> +target_ulong pending = env->mip & env->mie;
>  target_ulong mie = env->priv < PRV_M || (env->priv == PRV_M && 
> mstatus_mie);
>  target_ulong sie = env->priv < PRV_S || (env->priv == PRV_S && 
> mstatus_sie);
>  target_ulong irqs = (pending & ~env->mideleg & -mie) |
> @@ -92,42 +93,29 @@ int riscv_cpu_claim_interrupts(RISCVCPU *cpu, uint32_t 
> interrupts)
>  }
>  }
>
> -struct CpuAsyncInfo {
> -uint32_t new_mip;
> -};
> -
> -static void riscv_cpu_update_mip_irqs_async(CPUState *target_cpu_state,
> -run_on_cpu_data data)
> -{
> -struct CpuAsyncInfo *info = (struct CpuAsyncInfo *) data.host_ptr;
> -
> -if (info->new_mip) {
> -cpu_interrupt(target_cpu_state, CPU_INTERRUPT_HARD);
> -} else {
> -cpu_reset_interrupt(target_cpu_state, CPU_INTERRUPT_HARD);
> -}
> -
> -g_free(info);
> -}
> -
>  uint32_t riscv_cpu_update_mip(RISCVCPU *cpu, uint32_t mask, uint32_t value)
>  {
>  CPURISCVState *env = >env;
>  CPUState *cs = CPU(cpu);
> -struct CpuAsyncInfo *info;
> -uint32_t old, new, cmp = atomic_read(>mip);
> +uint32_t old = env->mip;
> +bool locked = false;
> +
> +if (!qemu_mutex_iothread_locked()) {
> +locked = true;
> +qemu_mutex_lock_iothread();
> +}
>
> -do {
> -old = cmp;
> -new = (old & ~mask) | (value & mask);
> -cmp = atomic_cmpxchg(>mip, old, new);
> -} while (old 

Re: [RFC 0/3] block/file-posix: Work around XFS bug

2019-10-29 Thread Vladimir Sementsov-Ogievskiy
29.10.2019 14:55, Max Reitz wrote:
> On 29.10.19 12:48, Vladimir Sementsov-Ogievskiy wrote:
>> 29.10.2019 11:50, Max Reitz wrote:
>>> On 28.10.19 12:25, Vladimir Sementsov-Ogievskiy wrote:
 28.10.2019 14:04, Kevin Wolf wrote:
> Am 27.10.2019 um 13:35 hat Stefan Hajnoczi geschrieben:
>> On Fri, Oct 25, 2019 at 11:58:46AM +0200, Max Reitz wrote:
>>>
>>> [...]
>>>
>>> (3) Drop handle_alloc_space(), i.e. revert c8bb23cbdbe32f.
>>>To my knowledge I’m the only one who has provided any benchmarks 
>>> for
>>>this commit, and even then I was a bit skeptical because it 
>>> performs
>>>well in some cases and bad in others.  I concluded that it’s
>>>probably worth it because the “some cases” are more likely to 
>>> occur.
>>>
>>>Now we have this problem of corruption here (granted due to a 
>>> bug in
>>>the XFS driver), and another report of massively degraded
>>>performance on ppc64
>>>(https://bugzilla.redhat.com/show_bug.cgi?id=1745823 – sorry, a
>>>private BZ; I hate that :-/  The report is about 40 % worse
>>>performance for an in-guest fio write benchmark.)
>>>
>>>So I have to ask the question about what the justification for
>>>keeping c8bb23cbdbe32f is.  How much does performance increase 
>>> with
>>>it actually?  (On non-(ppc64+XFS) machines, obviously)
>>>
>>>Advantages:
>>>+ Trivial
>>>+ No layering violations
>>>+ We wouldn’t need to keep track of whether the kernel bug has 
>>> been
>>>  fixed or not
>>>+ Fixes the ppc64+XFS performance problem
>>>
>>>Disadvantages:
>>>- Reverts cluster allocation performance to pre-c8bb23cbdbe32f
>>>  levels, whatever that means
>>
>> My favorite because it is clean and simple, but Vladimir has a valid
>> use-case for requiring this performance optimization so reverting isn't
>> an option.
>
> Vladimir also said that qcow2 subclusters would probably also solve his
> problem, so maybe reverting and applying the subcluster patches instead
> is a possible solution, too?

 I'm not sure about ssd case, it may need write-zero optimization anyway.
>>>
>>> What exactly do you need?  Do you actually need to write zeroes (e.g.
>>> because you’re storing images on block devices) or would it be
>>> sufficient to just drop the COW areas when bdrv_has_zero_init() and
>>> bdrv_has_zero_init_truncate() are true?
>>
>> Hmm, what do you mean? We need to zero COW areas. So, original way is to
>> write real zeroes, optimized way is fallocate.. What do you mean by drop?
>> Mark sublusters as zeroes by metadata?
> 
> Why do you need to zero COW areas?  For normal files, any data will read
> as zero if you didn’t write anything there.

Hmm, but when allocating new cluster in qcow2, it's not guaranteed to be zero,
as it may be reused previously allocated cluster..

> 
>> But still we'll have COW areas in subcluster, and we'll need to directly zero
>> them.. And fallocate will most probably be faster on ssd ext4 case..
>>
>>>
>>> I’m asking because Dave Chinner said
>>> (https://bugzilla.redhat.com/show_bug.cgi?id=1765547#c7) that
>>> fallocate() is always slow at least with aio=native because it needs to
>>> wait for all concurrent AIO writes to finish, and so it causes the AIO
>>> pipeline to stall.
>>>
>>> (He suggested using XFS extent size hints to get the same effect as
>>> write-zeroes for free, basically, but I don’t know whether that’s really
>>> useful to us; as unallocated areas on XFS read back as zero anyway.)
>>>
> We already have some cases where the existing handle_alloc_space()
> causes performance to actually become worse, and serialising requests as
> a workaround isn't going to make performance any better. So even on
> these grounds, keeping commit c8bb23cbdbe32f is questionable.
>

 Can keeping handle_alloc_space under some config option be an option?
>>>
>>> Hm.  A config option is weird if you’re the only one who’s going to
>>> enable it.  But other than that I don’t have anything against it.
>>>
>>
>> It's just a bit easier for us to maintain config option, than out-of-tree 
>> patch.
>> On the other hand, it's not a real problem to maintain this one patch in 
>> separate.
>> It may return again to the tree, when XFS bug fixed.
> 
> We’ll still have the problem that fallocate() must stall aio=native
> requests.
> 

Does it mean that fallocate is bad in general? Practice shows the opposite..
At least I have my examples with qemu-img bench. Can that thing be shown with
qemu-img bench or something?


-- 
Best regards,
Vladimir


[PATCH v7 11/11] vfio: unplug failover primary device before migration

2019-10-29 Thread Jens Freimann
As usual block all vfio-pci devices from being migrated, but make an
exception for failover primary devices. This is achieved by setting
unmigratable to 0 but also add a migration blocker for all vfio-pci
devices except failover primary devices. These will be unplugged before
migration happens by the migration handler of the corresponding
virtio-net standby device.

Signed-off-by: Jens Freimann 
Acked-by: Alex Williamson 
---
 hw/vfio/pci.c | 26 --
 hw/vfio/pci.h |  1 +
 2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 12fac39804..e6569a7968 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -40,6 +40,7 @@
 #include "pci.h"
 #include "trace.h"
 #include "qapi/error.h"
+#include "migration/blocker.h"
 
 #define TYPE_VFIO_PCI "vfio-pci"
 #define PCI_VFIO(obj)OBJECT_CHECK(VFIOPCIDevice, obj, TYPE_VFIO_PCI)
@@ -2732,6 +2733,17 @@ static void vfio_realize(PCIDevice *pdev, Error **errp)
 return;
 }
 
+if (!pdev->failover_pair_id) {
+error_setg(>migration_blocker,
+"VFIO device doesn't support migration");
+ret = migrate_add_blocker(vdev->migration_blocker, );
+if (err) {
+error_propagate(errp, err);
+error_free(vdev->migration_blocker);
+return;
+}
+}
+
 vdev->vbasedev.name = g_path_get_basename(vdev->vbasedev.sysfsdev);
 vdev->vbasedev.ops = _pci_ops;
 vdev->vbasedev.type = VFIO_DEVICE_TYPE_PCI;
@@ -3008,6 +3020,10 @@ out_teardown:
 vfio_bars_exit(vdev);
 error:
 error_prepend(errp, VFIO_MSG_PREFIX, vdev->vbasedev.name);
+if (vdev->migration_blocker) {
+migrate_del_blocker(vdev->migration_blocker);
+error_free(vdev->migration_blocker);
+}
 }
 
 static void vfio_instance_finalize(Object *obj)
@@ -3019,6 +3035,10 @@ static void vfio_instance_finalize(Object *obj)
 vfio_bars_finalize(vdev);
 g_free(vdev->emulated_config_bits);
 g_free(vdev->rom);
+if (vdev->migration_blocker) {
+migrate_del_blocker(vdev->migration_blocker);
+error_free(vdev->migration_blocker);
+}
 /*
  * XXX Leaking igd_opregion is not an oversight, we can't remove the
  * fw_cfg entry therefore leaking this allocation seems like the safest
@@ -3151,11 +3171,6 @@ static Property vfio_pci_dev_properties[] = {
 DEFINE_PROP_END_OF_LIST(),
 };
 
-static const VMStateDescription vfio_pci_vmstate = {
-.name = "vfio-pci",
-.unmigratable = 1,
-};
-
 static void vfio_pci_dev_class_init(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
@@ -3163,7 +3178,6 @@ static void vfio_pci_dev_class_init(ObjectClass *klass, 
void *data)
 
 dc->reset = vfio_pci_reset;
 dc->props = vfio_pci_dev_properties;
-dc->vmsd = _pci_vmstate;
 dc->desc = "VFIO-based PCI device assignment";
 set_bit(DEVICE_CATEGORY_MISC, dc->categories);
 pdc->realize = vfio_realize;
diff --git a/hw/vfio/pci.h b/hw/vfio/pci.h
index 834a90d646..b329d50338 100644
--- a/hw/vfio/pci.h
+++ b/hw/vfio/pci.h
@@ -168,6 +168,7 @@ typedef struct VFIOPCIDevice {
 bool no_vfio_ioeventfd;
 bool enable_ramfb;
 VFIODisplay *dpy;
+Error *migration_blocker;
 } VFIOPCIDevice;
 
 uint32_t vfio_pci_read_config(PCIDevice *pdev, uint32_t addr, int len);
-- 
2.21.0




  1   2   >