Re: [Qemu-devel] [PATCH v13 20/30] sdbus: add trace events
On 04/30/2018 10:49 AM, Edgar E. Iglesias wrote:
> On Fri, Apr 27, 2018 at 12:55:21PM +0100, Peter Maydell wrote:
>> On 13 February 2018 at 04:07, Philippe Mathieu-Daudé wrote:
>>> Signed-off-by: Philippe Mathieu-Daudé
>>> Reviewed-by: Alistair Francis
>>
>>> @@ -39,6 +45,7 @@ int sdbus_do_command(SDBus *sdbus, SDRequest *req,
>>> uint8_t *response)
>>> {
>>> SDState *card = get_card(sdbus);
>>>
>>> +trace_sdbus_command(sdbus_name(sdbus), req->cmd, req->arg, req->crc);
>>> if (card) {
>>> SDCardClass *sc = SD_CARD_GET_CLASS(card);
>>
>> Hi -- as a result of this trace event being added, we now get
>> warnings from Coverity that it might use uninitialized data
>> (CID1386074, CID1390571, CID1386072, CID1386076). This is because not
>> all of our SD
>> controllers bother to initialize req->crc, because up til now
>> nothing in the SD code looks at it. (I think at least bcm2835_sdhost.c
>> sdhci.c and ssi-sd.c do this).
I was pretty sure we ran Coverity before the stable release :|
Maybe they added new 'uninitialized data' checks recently.
>>
>> Could you have a look at this, please? I think there are
>> three plausible lines of approach:
>>
>> (1) just don't bother to trace the CRC field
>> (2) make bcm2835_sdhost.c, sdhci.c, ssi-sd.c set crc to 0 like
>> omap and pxa2xx already do
>
> Hi,
>
> Philippe, any opinion here?
>
> Otherwise I suggest we do #2 right away to avoid the warnings
> until someone cares enough to implement #3...
I prefer to start with #3 directly, else we'll keep this forever.
>
> Cheers,
> Edgar
>
>
>
>> (3) "proper" implementation of CRC, so that an sd controller
>> can either (a) mark the SDRequest as "no CRC" and have
>> sd_req_crc_validate() always pass, or (b) mark the SDRequest
>> as having a CRC and have sd_req_crc_validate() actually
>> do the check which it currently stubs out with "return 0"
>>
>> (3 is because it doesn't seem very sensible to spend time
>> calculating a CRC just to test it against a CRC calculated
>> a little bit later on; but we don't really want to drop the
>> CRC stuff entirely because on some controllers like
>> milkymist-memcard.c the CRC byte comes from the guest and
>> we'd ideally like to check it.)
>>
>> I don't have a strong preference for which of 1/2/3 we do.
>>
>> PS: CID1005332 is the coverity issue for "sd_req_crc_validate
>> stubs out its check code with 'return 0' leaving a line of
>> unreachable code".
>>
>> thanks
>> -- PMM
>
Re: [Qemu-devel] [PATCH] net: Fix memory leak in net_param_nic()
On 04/30/2018 04:26 AM, Thomas Huth wrote:
> The early exits in case of errors leak the memory allocated for nd_id.
> Fix it by using a "goto out" to the cleanup at the end of the function
> instead.
>
> Signed-off-by: Thomas Huth
Reviewed-by: Philippe Mathieu-Daudé
> ---
> net/net.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/net/net.c b/net/net.c
> index 29f8398..65457b7 100644
> --- a/net/net.c
> +++ b/net/net.c
> @@ -1502,11 +1502,12 @@ static int net_param_nic(void *dummy, QemuOpts *opts,
> Error **errp)
> g_free(mac);
> if (ret) {
> error_setg(errp, "invalid syntax for ethernet address");
> -return -1;
> +goto out;
> }
> if (is_multicast_ether_addr(ni->macaddr.a)) {
> error_setg(errp, "NIC cannot have multicast MAC address");
> -return -1;
> +ret = -1;
> +goto out;
> }
> }
> qemu_macaddr_default_if_unset(&ni->macaddr);
> @@ -1518,6 +1519,7 @@ static int net_param_nic(void *dummy, QemuOpts *opts,
> Error **errp)
> nb_nics++;
> }
>
> +out:
> g_free(nd_id);
> return ret;
> }
>
Re: [Qemu-devel] [PATCH] trivial: Do not include pci.h if it is not necessary
On 04/30/2018 04:32 AM, Thomas Huth wrote: > There is no need to include pci.h in these files. > > Signed-off-by: Thomas Huth > --- > include/hw/ppc/ppc4xx.h| 2 -- > include/hw/virtio/virtio-balloon.h | 1 - > include/hw/virtio/virtio-gpu.h | 1 - > 3 files changed, 4 deletions(-) > > diff --git a/include/hw/ppc/ppc4xx.h b/include/hw/ppc/ppc4xx.h > index cb0bb55..3a2a04c 100644 > --- a/include/hw/ppc/ppc4xx.h > +++ b/include/hw/ppc/ppc4xx.h > @@ -25,8 +25,6 @@ > #ifndef PPC4XX_H > #define PPC4XX_H > > -#include "hw/pci/pci.h" > - > /* PowerPC 4xx core initialization */ > PowerPCCPU *ppc4xx_init(const char *cpu_model, > clk_setup_t *cpu_clk, clk_setup_t *tb_clk, "ppc4xx.h" misses various includes... > diff --git a/include/hw/virtio/virtio-balloon.h > b/include/hw/virtio/virtio-balloon.h > index 1ea13bd..e0df352 100644 > --- a/include/hw/virtio/virtio-balloon.h > +++ b/include/hw/virtio/virtio-balloon.h > @@ -17,7 +17,6 @@ > > #include "standard-headers/linux/virtio_balloon.h" > #include "hw/virtio/virtio.h" > -#include "hw/pci/pci.h" > > #define TYPE_VIRTIO_BALLOON "virtio-balloon-device" > #define VIRTIO_BALLOON(obj) \ > diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h > index 22ac3c2..79bb3fb 100644 > --- a/include/hw/virtio/virtio-gpu.h > +++ b/include/hw/virtio/virtio-gpu.h > @@ -18,7 +18,6 @@ > #include "ui/qemu-pixman.h" > #include "ui/console.h" > #include "hw/virtio/virtio.h" > -#include "hw/pci/pci.h" > #include "qemu/log.h" > > #include "standard-headers/linux/virtio_gpu.h" > Weirdness of virtio-gpu.h, it uses VIRTIO_PCI_FLAG_USE_IOEVENTFD which is defined in the local hw/virtio/virtio-pci.h (local = not under include/) Anyway any of those requires "hw/pci/pci.h", so: Reviewed-by: Philippe Mathieu-Daudé
Re: [Qemu-devel] [PATCH 1/2] m68k: Fix floatx80_lognp1 (Coverity CID1390587)
On 04/30/2018 02:01 PM, Laurent Vivier wrote:
> return the result of packFloatx80() instead of
> dropping it.
(missed in 4b5c65b8f02).
>
> Signed-off-by: Laurent Vivier
Reviewed-by: Philippe Mathieu-Daudé
> ---
> target/m68k/softfloat.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/target/m68k/softfloat.c b/target/m68k/softfloat.c
> index dffb371c71..2c069a5efb 100644
> --- a/target/m68k/softfloat.c
> +++ b/target/m68k/softfloat.c
> @@ -334,7 +334,8 @@ floatx80 floatx80_lognp1(floatx80 a, float_status *status)
> if (aSign && aExp >= one_exp) {
> if (aExp == one_exp && aSig == one_sig) {
> float_raise(float_flag_divbyzero, status);
> -packFloatx80(aSign, floatx80_infinity.high,
> floatx80_infinity.low);
> +return packFloatx80(aSign, floatx80_infinity.high,
> +floatx80_infinity.low);
> }
> float_raise(float_flag_invalid, status);
> return floatx80_default_nan(status);
>
Re: [Qemu-devel] [PATCH 2/7] hw/rdma: Fix possible usage of a NULL pointer
On 04/30/2018 05:02 PM, Marcel Apfelbaum wrote:
> Coverity CID 1390586; The cq handle is provided by the guest
> and cannot be trusted to be previuosly allocated.
> Fix it by exiting the completion flow.
>
> Reported-by: Peter Maydell
> Signed-off-by: Marcel Apfelbaum
> Reviewed-by: Yuval Shaia
Reviewed-by: Philippe Mathieu-Daudé
> ---
> hw/rdma/vmw/pvrdma_qp_ops.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/hw/rdma/vmw/pvrdma_qp_ops.c b/hw/rdma/vmw/pvrdma_qp_ops.c
> index 750ade6c31..99bb5e 100644
> --- a/hw/rdma/vmw/pvrdma_qp_ops.c
> +++ b/hw/rdma/vmw/pvrdma_qp_ops.c
> @@ -216,6 +216,7 @@ void pvrdma_cq_poll(RdmaDeviceResources *dev_res,
> uint32_t cq_handle)
> cq = rdma_rm_get_cq(dev_res, cq_handle);
> if (!cq) {
> pr_dbg("Invalid CQ# %d\n", cq_handle);
> +return;
> }
>
> rdma_backend_poll_cq(dev_res, &cq->backend_cq);
>
[Qemu-devel] [Bug 1762179] Re: Record and replay replay fails with: "ERROR:replay/replay-time.c:49:replay_read_clock: assertion failed"
@Ciro, I hope this solves the problem for me too. Thanks for highlighting the patch. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1762179 Title: Record and replay replay fails with: "ERROR:replay/replay- time.c:49:replay_read_clock: assertion failed" Status in QEMU: New Bug description: QEMU master at 915d34c5f99b0ab91517c69f54272bfdb6ca2b32 Ubuntu 17.10 host. QEMU commands: ``` #!/usr/bin/env bash cmd="\ time \ ./x86_64-softmmu/qemu-system-x86_64 \ -append 'root=/dev/sda console=ttyS0 nokaslr printk.time=y - lkmc_eval=\"/rand_check.out;/sbin/ifup -a;wget -S google.com;/poweroff.out;\"' \ -kernel 'out/x86_64/buildroot/images/bzImage' \ -nographic \ \ -drive file=out/x86_64/buildroot/images/rootfs.ext2.qcow2,if=none,id=img-direct,format=qcow2 \ -drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay \ -device ide-hd,drive=img-blkreplay \ \ -netdev user,id=net1 \ -device rtl8139,netdev=net1 \ -object filter-replay,id=replay,netdev=net1 \ " echo "$cmd" eval "$cmd -icount 'shift=7,rr=record,rrfile=replay.bin'" eval "$cmd -icount 'shift=7,rr=replay,rrfile=replay.bin'" ``` This tries to stay as close as possible to the documented commands: https://github.com/qemu/qemu/blob/08e173f29461396575c85510eb41474b993cb1fb/docs/replay.txt#L28 Images uploaded to: https://github.com/cirosantilli/linux-kernel- module-cheat/releases/download/test-replay-arm/images4.zip Images generated with: https://github.com/cirosantilli/linux-kernel- module-cheat/tree/9513c162ef57e6cb70006dfe870856f94ee9a133 The replay failed straight out with: ``` ERROR:replay/replay-time.c:49:replay_read_clock: assertion failed: (replay_file && replay_mutex_locked()) ``` QEMU configure: ``` ./configure --enable-debug --enable-trace-backends=simple --target-list=x86_64-softmmu ``` To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1762179/+subscriptions
Re: [Qemu-devel] [PATCH] memory.h: Improve IOMMU related documentation
On Mon, Apr 30, 2018 at 08:28:35AM -0600, Alex Williamson wrote: > On Mon, 30 Apr 2018 14:35:20 +0100 > Peter Maydell wrote: > > > On 30 April 2018 at 14:08, Paolo Bonzini wrote: > > > On 30/04/2018 14:57, Peter Maydell wrote: > > >> On 30 April 2018 at 13:54, Paolo Bonzini wrote: > > >>> On 30/04/2018 14:24, Peter Maydell wrote: > > -/* Set this up to provide customized IOMMU replay function */ > > +/* Set this up to provide customized IOMMU replay function. > > + * Optional method. > > + */ > > void (*replay)(IOMMUMemoryRegion *iommu, IOMMUNotifier > > *notifier); > > >>> > > >>> replay is needed if you want to support IOMMU notifiers. After > > >>> memory_region_register_iommu_notifier you're only notified about future > > >>> changes to the mappings; memory_region_iommu_replay calls the replay > > >>> method so that the IOMMUNotifier is called for each existing mapping. > > >> > > >> Is it then unrelated to record-and-replay ? That's what I guessed > > >> it was for... Also, some IOMMUs (eg spapr_iommu.c) seem to support > > >> notifiers but don't implement it. > > > > > > Yes, it's completely unrelated. I have no idea why spapr_iommu.c > > > doesn't need it, so I am CCing the sPAPR and VFIO experts... > > > > There does seem to be a default implementation in > > memory_region_iommu_replay(), maybe that is sufficient for spapr? > > AIUI, the default implementation is used by spapr, it was added here: > > commit a788f227ef7bd2912fcaacdfe13d13ece2998149 > Author: David Gibson > Date: Wed Sep 30 12:13:55 2015 +1000 > > memory: Allow replay of IOMMU mapping notifications > > When we have guest visible IOMMUs, we allow notifiers to be registered > which will be informed of all changes to IOMMU mappings. This is used by > vfio to keep the host IOMMU mappings in sync with guest IOMMU mappings. > > However, unlike with a memory region listener, an iommu notifier won't be > told about any mappings which already exist in the (guest) IOMMU at the > time it is registered. This can cause problems if hotplugging a VFIO > device onto a guest bus which had existing guest IOMMU mappings, but > didn't > previously have an VFIO devices (and hence no host IOMMU mappings). > > This adds a memory_region_iommu_replay() function to handle this case. It > replays any existing mappings in an IOMMU memory region to a specified > notifier. Because the IOMMU memory region doesn't internally remember the > granularity of the guest IOMMU it has a small hack where the caller must > specify a granularity at which to replay mappings. > > If there are finer mappings in the guest IOMMU these will be reported in > the iotlb structures passed to the notifier which it must handle (probably > causing it to flag an error). This isn't new - the VFIO iommu notifier > must already handle notifications about guest IOMMU mappings too short > for it to represent in the host IOMMU. > > Signed-off-by: David Gibson > Reviewed-by: Laurent Vivier > Acked-by: Paolo Bonzini > Signed-off-by: Alex Williamson > > VT-d emulation then needed its own replay and that hook was later added > here: Yes, that's right. We actually introduced the replay for spapr's benefit, initially with just the default implementation not a hook. When x86 needed it, the default implementation although correct, was grossly inefficient so the hook was added. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: [Qemu-devel] [RFC PATCH 2/7] avocado: Update python scripts to upstream codebase
On 04/19/2018 12:46 PM, Philippe Mathieu-Daudé wrote:
> QEMUMachine arguments member is called '_args'.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> scripts/qemu.py| 14 +++---
> tests/avocado/avocado_qemu/test.py | 12 ++--
> tests/qemu-iotests/iotests.py | 28 ++--
> 3 files changed, 27 insertions(+), 27 deletions(-)
>
> diff --git a/scripts/qemu.py b/scripts/qemu.py
> index bd66620f45..0eecc44d09 100644
> --- a/scripts/qemu.py
> +++ b/scripts/qemu.py
> @@ -81,7 +81,7 @@ class QEMUMachine(object):
> self._qemu_log_file = None
> self._popen = None
> self._binary = binary
> -self.args = list(args) # Force copy args in case we modify them
> +self._args = list(args) # Force copy args in case we modify them
> self._wrapper = wrapper
> self._events = []
> self._iolog = None
> @@ -109,8 +109,8 @@ class QEMUMachine(object):
> # This can be used to add an unused monitor instance.
> def add_monitor_telnet(self, ip, port):
> args = 'tcp:%s:%d,server,nowait,telnet' % (ip, port)
> -self.args.append('-monitor')
> -self.args.append(args)
> +self._args.append('-monitor')
> +self._args.append(args)
>
> def add_fd(self, fd, fdset, opaque, opts=''):
> '''Pass a file descriptor to the VM'''
> @@ -120,8 +120,8 @@ class QEMUMachine(object):
> if opts:
> options.append(opts)
>
> -self.args.append('-add-fd')
> -self.args.append(','.join(options))
> +self._args.append('-add-fd')
> +self._args.append(','.join(options))
> return self
>
> def send_fd_scm(self, fd_file_path):
> @@ -184,7 +184,7 @@ class QEMUMachine(object):
> '-display', 'none', '-vga', 'none']
>
> def _create_console(self, console_address):
> -for item in self.args:
> +for item in self._args:
> for option in ['isa-serial', 'spapr-vty', 'sclpconsole']:
> if option in item:
> return []
> @@ -274,7 +274,7 @@ class QEMUMachine(object):
> bargs = self._base_args()
> bargs.extend(self._create_console(console_address))
> self._qemu_full_args = (self._wrapper + [self._binary] +
> -bargs + self.args)
> +bargs + self._args)
> self._popen = subprocess.Popen(self._qemu_full_args,
> stdin=devnull,
> stdout=self._qemu_log_file,
> diff --git a/tests/avocado/avocado_qemu/test.py
> b/tests/avocado/avocado_qemu/test.py
> index 5a08dace45..1ead917014 100644
> --- a/tests/avocado/avocado_qemu/test.py
> +++ b/tests/avocado/avocado_qemu/test.py
> @@ -297,8 +297,8 @@ class _VM(qemu.QEMUMachine):
> port = self.ports.find_free_port()
> newvm = _VM(self.qemu_dst_bin, self._arch, username=self.username,
> password=self.password)
> -newvm.args = self.args
> -newvm.args.extend(['-incoming', 'tcp:0:%s' % port])
> +newvm._args = self._args
> +newvm._args.extend(['-incoming', 'tcp:0:%s' % port])
> newvm.username = self.username
> newvm.password = self.password
>
> @@ -329,7 +329,7 @@ class _VM(qemu.QEMUMachine):
> :param extra: Extra parameters to the -drive option
> """
> file_option = 'file=%s' % path
> -for item in self.args:
> +for item in self._args:
> if file_option in item:
> logging.error('Image %s already present', path)
> return
> @@ -340,7 +340,7 @@ class _VM(qemu.QEMUMachine):
> if snapshot:
> file_option += ',snapshot=on'
>
> -self.args.extend(['-drive', file_option])
> +self._args.extend(['-drive', file_option])
>
> if username is not None:
> self.username = username
> @@ -387,7 +387,7 @@ class _VM(qemu.QEMUMachine):
> process.run("%s -output %s -volid cidata -joliet -rock %s %s" %
> (geniso_bin, iso_path, metadata_path, userdata_path))
>
> -self.args.extend(['-cdrom', iso_path])
> +self._args.extend(['-cdrom', iso_path])
>
> class QemuTest(Test):
>
> @@ -415,4 +415,4 @@ class QemuTest(Test):
> if machine_kvm_type is not None:
> machine += "kvm-type=%s," % machine_kvm_type
> if machine:
> -self.vm.args.extend(['-machine', machine])
> +self.vm._args.extend(['-machine', machine])
> diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
> index a2e4f03743..b25d48a91b 100644
> --- a/tests/qemu-iotests/iotests.py
> +++ b/tests/qemu-iotests/iotests.py
> @@ -293,18 +293,18 @@ class VM(qtest.QEMUQtestMachine):
> self._num_drives = 0
>
> def add_object(self,
Re: [Qemu-devel] [RFC PATCH 0/7] avocado: Add acceptance tests parsing the Linux boot console
On 04/19/2018 12:46 PM, Philippe Mathieu-Daudé wrote: > Hi, > > While previously working on a Super I/O refactor, I encountered some problems > at runtime, after building the codebase successfully and running qtests. > I had to manually start to boot different guests and check the bootlog. > > I wanted to give a try at Avocado which seems designed to simplify that kind > of functional tests. > > I applied Amador Pahim work following Cleber Rosa documentation from > http://lists.nongnu.org/archive/html/qemu-devel/2018-01/msg03891.html, > however I had to modify few things to parse the boot console. > Since his work is not merged, I included it in this series. > > The tests simply expect to find a string reported by Linux printk when a > device is detected/initialized, such "ttyS0 at I/O 0x3f8 (irq = 4) is a > 16550A" > and "i8042 KBD port at 0x60,0x64 irq 1" for the Super I/O chip, or such > "registered as PCnet/PCI II 79C970A" to confirms the PCI subsystem and network > device are correctly detected: > > > self.assertIn(u'ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A', bootlog) > self.assertIn(u'ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A', bootlog) > self.assertIn(u'i8042 KBD port at 0x60,0x64 irq 1', bootlog) > self.assertIn(u'i8042 AUX port at 0x60,0x64 irq 12', bootlog) > > Example of the tests output: > > $ avocado run test_linux-boot-console.py -m > test_linux-boot-console.py.data/parameters.yaml > JOB ID : 695094c9bbe8f6011226da7c2031c2c53e949910 > JOB LOG: > /home/phil/avocado/job-results/job-2018-04-19T13.36-695094c/job.log > (1/6) > test_linux-boot-console.py:TestAlphaClipperBoot2_6.test_boot_console;alpha-2582: > PASS (4.76 s) > (2/6) > test_linux-boot-console.py:TestAlphaClipperBoot2_6.test_boot_console;mips-4a72: > PASS (0.00 s) > (3/6) > test_linux-boot-console.py:TestMips4kcMaltaBoot2_6.test_boot_console;alpha-2582: > PASS (0.00 s) > (4/6) > test_linux-boot-console.py:TestMips4kcMaltaBoot2_6.test_boot_console;mips-4a72: > PASS (3.92 s) > (5/6) > test_linux-boot-console.py:TestMips4kcMaltaBoot3_2.test_boot_console;alpha-2582: > PASS (0.00 s) > (6/6) > test_linux-boot-console.py:TestMips4kcMaltaBoot3_2.test_boot_console;mips-4a72: > PASS (4.08 s) > RESULTS: PASS 6 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 | > CANCEL 0 > JOB TIME : 13.31 s > > Please apologize my ugly Python, this series is just a proof-of-concept :) > I couldn't figure out how to use the @skipUnless(correct arch) decorator. > > Regards, > > Phil. > Hi Philippe, Thanks for this interesting RFC/PoC. As someone who has spent more time "on the other" side of this code, this perspective is invaluable. I'll respond to the major feature utilization points here, and then proceed to review the individual patches. One of the distinguishing features of Avocado is the ability to reuse test code in different scenarios (thus reducing the amount of duplicated code while still improving the overall coverage). I noticed you grasped the overall usage pattern of the "YAML to Mux" plugin, by means of the "parameter.yaml". This is an alternative proposal for the "parameter.yaml" file: --- "parameter.yaml" STARTS HERE architechture: !mux alpha: arch: alpha machine_type: clipper kernel_url: http://archive.debian.org/debian/dists/lenny/main/installer-alpha/current/images/cdrom/vmlinuz mips: arch: mips machine_type: malta check_pci: True kernel_versions: !mux 2_6: kernel_url: http://people.debian.org/~aurel32/qemu/mips/vmlinux-2.6.32-5-4kc-malta 3_2: kernel_url: http://people.debian.org/~aurel32/qemu/mips/vmlinux-3.2.0-4-4kc-malta --- "parameter.yaml" ENDS HERE This file content produces the following tree (run it with "avocado -c -t -m parameter.yaml"): Multiplex tree representation: ┗━━ run ┗━━ architechture ╠══ alpha ║ → arch: alpha ║ → machine_type: clipper ║ → kernel_url: http://archive.debian.org/debian/dists/lenny/main/installer-alpha/current/images/cdrom/vmlinuz ╚══ mips ┃ → check_pci: True ┃ → arch: mips ┃ → machine_type: malta ┗━━ kernel_versions ╠══ 2_6 ║ → kernel_url: http://people.debian.org/~aurel32/qemu/mips/vmlinux-2.6.32-5-4kc-malta ╚══ 3_2 → kernel_url: http://people.debian.org/~aurel32/qemu/mips/vmlinux-3.2.0-4-4kc-malta And it generates the following variants (run it with "avocado -m parameters.yaml"): Multiplex variants (3): Variant alpha-deaa: /run/architechture/alpha Variant 2_6-6f08:/run/architechture/mips/kernel_versions/2_6 Variant 3_2-e556:/run/architechture/mips/kernel_versions/3_2 With these variants, it's possible to have a single code test implementation. Here's my alternat
Re: [Qemu-devel] [PULL 00/42] Linux user for 2.13 patches
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20180430091037.13878-1-laur...@vivier.eu
Subject: [Qemu-devel] [PULL 00/42] Linux user for 2.13 patches
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done
exit $failed
=== TEST SCRIPT END ===
Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
t [tag update]
patchew/1525073205-22394-1-git-send-email-th...@redhat.com ->
patchew/1525073205-22394-1-git-send-email-th...@redhat.com
* [new tag] patchew/20180430091037.13878-1-laur...@vivier.eu ->
patchew/20180430091037.13878-1-laur...@vivier.eu
Switched to a new branch 'test'
e8d201b9d7 linux-user: Add ARM get_tls syscall support
fff36991c4 linux-user: move xtensa cpu loop to xtensa directory
715eff8d69 linux-user: move hppa cpu loop to hppa directory
085f6b7889 linux-user: move riscv cpu loop to riscv directory
642674846e linux-user: move tilegx cpu loop to tilegx directory
40a79fbb0e linux-user: move s390x cpu loop to s390x directory
13bd8c3081 linux-user: move alpha cpu loop to alpha directory
d27e453571 linux-user: move m68k cpu loop to m68k directory
de1e4e198b linux-user: move microblaze cpu loop to microblaze directory
6edc94bd8e linux-user: move cris cpu loop to cris directory
5a09d0be10 linux-user: move sh4 cpu loop to sh4 directory
fb23bae8fe linux-user: move openrisc cpu loop to openrisc directory
0e28504595 linux-user: move nios2 cpu loop to nios2 directory
1ca42788d4 linux-user: move mips/mips64 cpu loop to mips directory
5df6189c35 linux-user: move ppc/ppc64 cpu loop to ppc directory
f9c62efd39 linux-user: move sparc/sparc64 cpu loop to sparc directory
8652473692 linux-user: move arm cpu loop to arm directory
6a92edde2b linux-user: move aarch64 cpu loop to aarch64 directory
1fd2f6f49c linux-user: move i386/x86_64 cpu loop to i386 directory
2b9c15a3f8 linux-user: create a dummy per arch cpu_loop.c
cf8175f080 linux-user: define TARGET_ARCH_HAS_SETUP_FRAME
81c693f4e3 linux-user: move ppc/ppc64 signal.c parts to ppc directory
bd02c1b83e linux-user: move mips/mips64 signal.c parts to mips directory
45be36076f linux-user: move sparc/sparc64 signal.c parts to sparc directory
3bbc202d8a linux-user: move i386/x86_64 signal.c parts to i386 directory
a1d614b53e linux-user: move xtensa signal.c parts to xtensa directory
2ea46f4874 linux-user: move hppa signal.c parts to hppa directory
87988af5d6 linux-user: move riscv signal.c parts to riscv directory
835a931479 linux-user: move tilegx signal.c parts to tilegx directory
c61b39796b linux-user: move alpha signal.c parts to alpha directory
b053a18ac5 linux-user: move m68k signal.c parts to m68k directory
477e97e2d2 linux-user: move s390x signal.c parts to s390x directory
3636147402 linux-user: move openrisc signal.c parts to openrisc directory
c85301917c linux-user: move nios2 signal.c parts to nios2 directory
590445d3ac linux-user: move cris signal.c parts to cris directory
48394e2491 linux-user: move microblaze signal.c parts to microblaze directory
af9fd39b8a linux-user: move sh4 signal.c parts to sh4 directory
6b75852825 linux-user: move arm signal.c parts to arm directory
17f3177971 linux-user: move aarch64 signal.c parts to aarch64 directory
58300191b0 linux-user: create a dummy per arch signal.c
58ba5c5111 linux-user: Fix getdents emulation for 64 bit guest on 32 bit host
eae6494620 linux-user: set minimum uname for RISC-V
=== OUTPUT BEGIN ===
Checking PATCH 1/42: linux-user: set minimum uname for RISC-V...
Checking PATCH 2/42: linux-user: Fix getdents emulation for 64 bit guest on 32
bit host...
WARNING: architecture specific defines should be avoided
#43: FILE: linux-user/syscall.c:269:
+#if defined(__NR_getdents) && HOST_LONG_BITS >= TARGET_ABI_BITS
total: 0 errors, 1 warnings, 32 lines checked
Your patch has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Checking PATCH 3/42: linux-user: create a dummy per arch signal.c...
Checking PATCH 4/42: linux-user: move aarch64 signal.c parts to aarch64
directory...
Checking PATCH 5/42: linux-user: move arm signal.c parts to arm directory...
ERROR: open brace '{' following struct go on the same line
#110: FILE: linux-user/arm/signal.c:102:
+struct sigframe_v1
+{
ERROR: spaces required around that '-' (ctx:VxV)
#112: FILE: linux-user/arm/signal.c:104:
+abi_ulong extramask[TARGET_NSIG_WORDS-1];
Re: [Qemu-devel] [PATCH v2 0/3] NBD export bitmaps
On 04/13/2018 01:13 PM, Vladimir Sementsov-Ogievskiy wrote: Hi all. This is a proposal and realization of new NBD meta context: qemu. (I hope to send corresponding proposal to NBD protocol soon) New possible queries will look like: qemu:dirty-bitmap: qapi/block.json | 23 + include/block/nbd.h | 6 ++ blockdev-nbd.c | 23 + nbd/server.c| 274 ++-- 4 files changed, 297 insertions(+), 29 deletions(-) We need something in docs/interop/ that documents the qemu: namespace within NBD, so that the upstream NBD spec can point to our document as a reference for other clients to be aware of what semantics we are exporting. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: [Qemu-devel] [PATCH 7/7] hw/rdma: Fix possible out of bounds access to port GID index
On 04/30/2018 03:02 PM, Marcel Apfelbaum wrote:
Make sure the backend GID index is less then port's
git table length.
s/git/gid/
Signed-off-by: Marcel Apfelbaum
Reviewed-by: Yuval Shaia
---
hw/rdma/rdma_backend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/rdma/rdma_backend.c b/hw/rdma/rdma_backend.c
index 5c7b3d8949..e9ced6f9ef 100644
--- a/hw/rdma/rdma_backend.c
+++ b/hw/rdma/rdma_backend.c
@@ -774,7 +774,7 @@ int rdma_backend_init(RdmaBackendDev *backend_dev,
goto out_destroy_comm_channel;
}
-if (backend_dev->backend_gid_idx > port_attr.gid_tbl_len) {
+if (backend_dev->backend_gid_idx >= port_attr.gid_tbl_len) {
error_setg(errp, "Invalid backend_gid_idx, should be less than %d",
port_attr.gid_tbl_len);
goto out_destroy_comm_channel;
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
[Qemu-devel] [PATCH] target/tricore: Fix QEMU crashing when using -singlestep
when -singlestep is enabled we will actually return a tb->size of 0,
even though we emit one instruction. This is because we do the update to ctx.pc
after exiting the translation loop on the singlestep path. Therefore we
substract pc_start from ctx.pc, aka pc_start.
Signed-off-by: Bastian Koppelmann
---
target/tricore/translate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/tricore/translate.c b/target/tricore/translate.c
index aef0d9cf06..be2579d189 100644
--- a/target/tricore/translate.c
+++ b/target/tricore/translate.c
@@ -8843,12 +8843,12 @@ void gen_intermediate_code(CPUState *cs, struct
TranslationBlock *tb)
ctx.opcode = cpu_ldl_code(env, ctx.pc);
decode_opc(env, &ctx, 0);
+ctx.pc = ctx.next_pc;
if (num_insns >= max_insns || tcg_op_buf_full()) {
gen_save_pc(ctx.next_pc);
tcg_gen_exit_tb(0);
break;
}
-ctx.pc = ctx.next_pc;
}
gen_tb_end(tb, num_insns);
--
2.11.0
[Qemu-devel] [PATCH 7/7] hw/rdma: Fix possible out of bounds access to port GID index
Make sure the backend GID index is less then port's
git table length.
Signed-off-by: Marcel Apfelbaum
Reviewed-by: Yuval Shaia
---
hw/rdma/rdma_backend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/rdma/rdma_backend.c b/hw/rdma/rdma_backend.c
index 5c7b3d8949..e9ced6f9ef 100644
--- a/hw/rdma/rdma_backend.c
+++ b/hw/rdma/rdma_backend.c
@@ -774,7 +774,7 @@ int rdma_backend_init(RdmaBackendDev *backend_dev,
goto out_destroy_comm_channel;
}
-if (backend_dev->backend_gid_idx > port_attr.gid_tbl_len) {
+if (backend_dev->backend_gid_idx >= port_attr.gid_tbl_len) {
error_setg(errp, "Invalid backend_gid_idx, should be less than %d",
port_attr.gid_tbl_len);
goto out_destroy_comm_channel;
--
2.14.3
[Qemu-devel] [PATCH 6/7] hw/rdma: Delete duplicate definition of MAX_RM_TBL_NAME
From: Yuval Shaia
By a mistake this constant was defined twice - remove the duplication.
Signed-off-by: Yuval Shaia
Reviewed-by: Marcel Apfelbaum
---
hw/rdma/rdma_rm.c | 2 --
hw/rdma/rdma_rm_defs.h | 4 ++--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/hw/rdma/rdma_rm.c b/hw/rdma/rdma_rm.c
index 51a47d7292..415da15efe 100644
--- a/hw/rdma/rdma_rm.c
+++ b/hw/rdma/rdma_rm.c
@@ -21,8 +21,6 @@
#include "rdma_backend.h"
#include "rdma_rm.h"
-#define MAX_RM_TBL_NAME 16
-
/* Page directory and page tables */
#define PG_DIR_SZ { TARGET_PAGE_SIZE / sizeof(__u64) }
#define PG_TBL_SZ { TARGET_PAGE_SIZE / sizeof(__u64) }
diff --git a/hw/rdma/rdma_rm_defs.h b/hw/rdma/rdma_rm_defs.h
index 4d22a20e4c..226011176d 100644
--- a/hw/rdma/rdma_rm_defs.h
+++ b/hw/rdma/rdma_rm_defs.h
@@ -34,9 +34,9 @@
#define MAX_QP_INIT_RD_ATOM 16
#define MAX_AH64
-#define MAX_RMRESTBL_NAME_SZ 16
+#define MAX_RM_TBL_NAME 16
typedef struct RdmaRmResTbl {
-char name[MAX_RMRESTBL_NAME_SZ];
+char name[MAX_RM_TBL_NAME];
QemuMutex lock;
unsigned long *bitmap;
size_t tbl_sz;
--
2.14.3
[Qemu-devel] [PATCH 2/7] hw/rdma: Fix possible usage of a NULL pointer
Coverity CID 1390586; The cq handle is provided by the guest
and cannot be trusted to be previuosly allocated.
Fix it by exiting the completion flow.
Reported-by: Peter Maydell
Signed-off-by: Marcel Apfelbaum
Reviewed-by: Yuval Shaia
---
hw/rdma/vmw/pvrdma_qp_ops.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/rdma/vmw/pvrdma_qp_ops.c b/hw/rdma/vmw/pvrdma_qp_ops.c
index 750ade6c31..99bb5e 100644
--- a/hw/rdma/vmw/pvrdma_qp_ops.c
+++ b/hw/rdma/vmw/pvrdma_qp_ops.c
@@ -216,6 +216,7 @@ void pvrdma_cq_poll(RdmaDeviceResources *dev_res, uint32_t
cq_handle)
cq = rdma_rm_get_cq(dev_res, cq_handle);
if (!cq) {
pr_dbg("Invalid CQ# %d\n", cq_handle);
+return;
}
rdma_backend_poll_cq(dev_res, &cq->backend_cq);
--
2.14.3
[Qemu-devel] [PATCH 5/7] hw/rdma: Fix possible out of bounds access to regs array
From: Yuval Shaia
Coverity (CID1390589, CID1390608).
Array size is RDMA_BAR1_REGS_SIZE, let's make sure the given address is
in range.
While there also:
1. Adjust the size of this bar to reasonable size
2. Report the size of the array with sizeof(array)
Reported-by: Peter Maydell
Signed-off-by: Yuval Shaia
Reviewed-by: Marcel Apfelbaum
---
hw/rdma/vmw/pvrdma.h | 6 +++---
hw/rdma/vmw/pvrdma_main.c | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/hw/rdma/vmw/pvrdma.h b/hw/rdma/vmw/pvrdma.h
index 8c173cb824..0b46dc5a9b 100644
--- a/hw/rdma/vmw/pvrdma.h
+++ b/hw/rdma/vmw/pvrdma.h
@@ -31,7 +31,7 @@
#define RDMA_REG_BAR_IDX 1
#define RDMA_UAR_BAR_IDX 2
#define RDMA_BAR0_MSIX_SIZE (16 * 1024)
-#define RDMA_BAR1_REGS_SIZE 256
+#define RDMA_BAR1_REGS_SIZE 64
#define RDMA_BAR2_UAR_SIZE (0x1000 * MAX_UCS) /* each uc gets page */
/* MSIX */
@@ -86,7 +86,7 @@ static inline int get_reg_val(PVRDMADev *dev, hwaddr addr,
uint32_t *val)
{
int idx = addr >> 2;
-if (idx > RDMA_BAR1_REGS_SIZE) {
+if (idx >= RDMA_BAR1_REGS_SIZE) {
return -EINVAL;
}
@@ -99,7 +99,7 @@ static inline int set_reg_val(PVRDMADev *dev, hwaddr addr,
uint32_t val)
{
int idx = addr >> 2;
-if (idx > RDMA_BAR1_REGS_SIZE) {
+if (idx >= RDMA_BAR1_REGS_SIZE) {
return -EINVAL;
}
diff --git a/hw/rdma/vmw/pvrdma_main.c b/hw/rdma/vmw/pvrdma_main.c
index 994220b58e..3ed7409763 100644
--- a/hw/rdma/vmw/pvrdma_main.c
+++ b/hw/rdma/vmw/pvrdma_main.c
@@ -449,14 +449,14 @@ static void init_bars(PCIDevice *pdev)
/* BAR 1 - Registers */
memset(&dev->regs_data, 0, sizeof(dev->regs_data));
memory_region_init_io(&dev->regs, OBJECT(dev), ®s_ops, dev,
- "pvrdma-regs", RDMA_BAR1_REGS_SIZE);
+ "pvrdma-regs", sizeof(dev->regs_data));
pci_register_bar(pdev, RDMA_REG_BAR_IDX, PCI_BASE_ADDRESS_SPACE_MEMORY,
&dev->regs);
/* BAR 2 - UAR */
memset(&dev->uar_data, 0, sizeof(dev->uar_data));
memory_region_init_io(&dev->uar, OBJECT(dev), &uar_ops, dev, "rdma-uar",
- RDMA_BAR2_UAR_SIZE);
+ sizeof(dev->uar_data));
pci_register_bar(pdev, RDMA_UAR_BAR_IDX, PCI_BASE_ADDRESS_SPACE_MEMORY,
&dev->uar);
}
--
2.14.3
[Qemu-devel] [PATCH 0/7] hw/rdma: coverity fixes
From: Marcel Apfelbaum Various fixes that were found by coverity. (run by Peter, thanks!) Thanks, Marcel Marcel Apfelbaum (3): hw/rdma: Fix possible munmap call on a NULL pointer hw/rdma: Fix possible usage of a NULL pointer hw/rdma: Fix possible out of bounds access to port GID index Yuval Shaia (4): hw/rdma: Delete port's pkey table hw/rdma: Fix possible out of bounds access to GID table hw/rdma: Fix possible out of bounds access to regs array hw/rdma: Delete duplicate definition of MAX_RM_TBL_NAME hw/rdma/rdma_backend.c | 2 +- hw/rdma/rdma_rm.c | 2 -- hw/rdma/rdma_rm_defs.h | 9 - hw/rdma/vmw/pvrdma.h| 6 +++--- hw/rdma/vmw/pvrdma_cmd.c| 10 +++--- hw/rdma/vmw/pvrdma_main.c | 19 ++- hw/rdma/vmw/pvrdma_qp_ops.c | 1 + 7 files changed, 18 insertions(+), 31 deletions(-) -- 2.14.3
[Qemu-devel] [PATCH 4/7] hw/rdma: Fix possible out of bounds access to GID table
From: Yuval Shaia
Array size is MAX_PORT_GIDS, let's make sure the given index is in
range.
While there limit device table size to 1.
Reported-by: Peter Maydell
Signed-off-by: Yuval Shaia
Reviewed-by: Marcel Apfelbaum
---
hw/rdma/rdma_rm_defs.h | 2 +-
hw/rdma/vmw/pvrdma_cmd.c | 8 ++--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/hw/rdma/rdma_rm_defs.h b/hw/rdma/rdma_rm_defs.h
index 45503f14e0..4d22a20e4c 100644
--- a/hw/rdma/rdma_rm_defs.h
+++ b/hw/rdma/rdma_rm_defs.h
@@ -20,9 +20,9 @@
#define MAX_PORTS 1
#define MAX_PORT_GIDS 1
+#define MAX_GIDS MAX_PORT_GIDS
#define MAX_PORT_PKEYS1
#define MAX_PKEYS MAX_PORT_PKEYS
-#define MAX_GIDS 2048
#define MAX_UCS 512
#define MAX_MR_SIZE (1UL << 27)
#define MAX_QP1024
diff --git a/hw/rdma/vmw/pvrdma_cmd.c b/hw/rdma/vmw/pvrdma_cmd.c
index f9dd78cb27..14255d609f 100644
--- a/hw/rdma/vmw/pvrdma_cmd.c
+++ b/hw/rdma/vmw/pvrdma_cmd.c
@@ -576,7 +576,7 @@ static int create_bind(PVRDMADev *dev, union pvrdma_cmd_req
*req,
pr_dbg("index=%d\n", cmd->index);
-if (cmd->index > MAX_PORT_GIDS) {
+if (cmd->index >= MAX_PORT_GIDS) {
return -EINVAL;
}
@@ -603,7 +603,11 @@ static int destroy_bind(PVRDMADev *dev, union
pvrdma_cmd_req *req,
{
struct pvrdma_cmd_destroy_bind *cmd = &req->destroy_bind;
-pr_dbg("clear index %d\n", cmd->index);
+pr_dbg("index=%d\n", cmd->index);
+
+if (cmd->index >= MAX_PORT_GIDS) {
+return -EINVAL;
+}
memset(dev->rdma_dev_res.ports[0].gid_tbl[cmd->index].raw, 0,
sizeof(dev->rdma_dev_res.ports[0].gid_tbl[cmd->index].raw));
--
2.14.3
[Qemu-devel] [PATCH 1/7] hw/rdma: Fix possible munmap call on a NULL pointer
Coverity CID 1390620: we call munmap() on a NULL pointer.
Reported-by: Peter Maydell
Signed-off-by: Marcel Apfelbaum
Reviewed-by: Yuval Shaia
---
hw/rdma/vmw/pvrdma_cmd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/rdma/vmw/pvrdma_cmd.c b/hw/rdma/vmw/pvrdma_cmd.c
index 99019d8741..f9dd78cb27 100644
--- a/hw/rdma/vmw/pvrdma_cmd.c
+++ b/hw/rdma/vmw/pvrdma_cmd.c
@@ -232,7 +232,7 @@ static int create_mr(PVRDMADev *dev, union pvrdma_cmd_req
*req,
cmd->start, cmd->length, host_virt,
cmd->access_flags, &resp->mr_handle,
&resp->lkey, &resp->rkey);
-if (!resp->hdr.err) {
+if (host_virt && !resp->hdr.err) {
munmap(host_virt, cmd->length);
}
--
2.14.3
[Qemu-devel] [PATCH 3/7] hw/rdma: Delete port's pkey table
From: Yuval Shaia
Support for PKEY is not yet implemented. Removing the unneeded table
until a support will be added.
Signed-off-by: Yuval Shaia
Reviewed-by: Marcel Apfelbaum
---
hw/rdma/rdma_rm_defs.h| 3 +--
hw/rdma/vmw/pvrdma_main.c | 15 ---
2 files changed, 1 insertion(+), 17 deletions(-)
diff --git a/hw/rdma/rdma_rm_defs.h b/hw/rdma/rdma_rm_defs.h
index fc646da61f..45503f14e0 100644
--- a/hw/rdma/rdma_rm_defs.h
+++ b/hw/rdma/rdma_rm_defs.h
@@ -21,7 +21,7 @@
#define MAX_PORTS 1
#define MAX_PORT_GIDS 1
#define MAX_PORT_PKEYS1
-#define MAX_PKEYS 1
+#define MAX_PKEYS MAX_PORT_PKEYS
#define MAX_GIDS 2048
#define MAX_UCS 512
#define MAX_MR_SIZE (1UL << 27)
@@ -87,7 +87,6 @@ typedef struct RdmaRmQP {
typedef struct RdmaRmPort {
union ibv_gid gid_tbl[MAX_PORT_GIDS];
enum ibv_port_state state;
-int *pkey_tbl; /* TODO: Not yet supported */
} RdmaRmPort;
typedef struct RdmaDeviceResources {
diff --git a/hw/rdma/vmw/pvrdma_main.c b/hw/rdma/vmw/pvrdma_main.c
index c552248c90..994220b58e 100644
--- a/hw/rdma/vmw/pvrdma_main.c
+++ b/hw/rdma/vmw/pvrdma_main.c
@@ -275,15 +275,6 @@ static void init_dsr_dev_caps(PVRDMADev *dev)
pr_dbg("Initialized\n");
}
-static void free_ports(PVRDMADev *dev)
-{
-int i;
-
-for (i = 0; i < MAX_PORTS; i++) {
-g_free(dev->rdma_dev_res.ports[i].gid_tbl);
-}
-}
-
static void init_ports(PVRDMADev *dev, Error **errp)
{
int i;
@@ -292,10 +283,6 @@ static void init_ports(PVRDMADev *dev, Error **errp)
for (i = 0; i < MAX_PORTS; i++) {
dev->rdma_dev_res.ports[i].state = IBV_PORT_DOWN;
-
-dev->rdma_dev_res.ports[i].pkey_tbl =
-g_malloc0(sizeof(*dev->rdma_dev_res.ports[i].pkey_tbl) *
- MAX_PORT_PKEYS);
}
}
@@ -622,8 +609,6 @@ static void pvrdma_exit(PCIDevice *pdev)
pvrdma_qp_ops_fini();
-free_ports(dev);
-
rdma_rm_fini(&dev->rdma_dev_res);
rdma_backend_fini(&dev->backend_dev);
--
2.14.3
Re: [Qemu-devel] [PATCH v4 3/9] cli: add -preconfig option
* Eduardo Habkost (ehabk...@redhat.com) wrote: > On Tue, Apr 03, 2018 at 03:49:07PM +0200, Igor Mammedov wrote: > > On Thu, 29 Mar 2018 13:57:54 -0300 > > Eduardo Habkost wrote: > > > > [...] > > > > As for the future, I agree it would be much more flexible > > > > to allow both -preconfig and -incoming at the same time, > > > > so we could start target with empty CLI, and then feed it > > > > options from source. It would require audit/refactoring of > > > > INMIGRATE state and making 'all' current CLI options > > > > available via QMP interface. > > > > > > > > But for now I'd prefer to keep using old way to start target. > > > > > > Well, if management software developers tell us that -preconfig > > > will be already useful without -incoming support, I won't object. > > As Peter said, mgmt can/will use -preconfig even without -incoming, > > since it lets deal with initial (source) start-up problem (i.e. > > avoid restarting QEMU) and lets us make numa configuration work > > in qemu/libvirt stack without guess work. (that's the end goal of > > the series) > > > > > But it would be very nice for management software if they can > > > simply assume that -preconfig and -incoming will work together > > > since the first version. Can we have this as a goal for 2.13? > > I can't promise to refactor -incoming in near future, as I'm working > > on ARM cpu-hotplug currently and next in queue is ARM memory hotplug. > > > > Peter suggested an alternative idea, to abandon -incoming and > > enable incoming migration from QMP after all configuration is done. > > Amount of refactoring need probably would be the same but at least > > interface and runstate transitions wise it looks cleaner. > > Also, support for the "start incoming migration" QMP command > would be very easy to probe using existing mechanisms. Sounds > good to me. You could stick to -incoming defer, that already says that you want to do an inward migration but doesn't say where from until later. Note there are some other bits of code scattered around for checking whether we're in -incoming mode, for example to stop you do an outwards migration while waiting for an incoming one, or to stop you doing a migrate-incoming while you're already waiting for one. Dave > -- > Eduardo > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
[Qemu-devel] [PATCH] Migration+TLS: Fix crash due to double cleanup
From: "Dr. David Alan Gilbert"
During a TLS connect we see:
migration_channel_connect calls
migration_tls_channel_connect
(calls after TLS setup)
migration_channel_connect
My previous error handling fix made migration_channel_connect
call migrate_fd_connect in all cases; unfortunately the above
means it gets called twice and crashes doing double cleanup.
Fixes: 688a3dcba98
Reported-by: Peter Krempa
Signed-off-by: Dr. David Alan Gilbert
---
migration/channel.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/migration/channel.c b/migration/channel.c
index c5eaf0fa0e..7a32b5aca4 100644
--- a/migration/channel.c
+++ b/migration/channel.c
@@ -71,6 +71,15 @@ void migration_channel_connect(MigrationState *s,
!object_dynamic_cast(OBJECT(ioc),
TYPE_QIO_CHANNEL_TLS)) {
migration_tls_channel_connect(s, ioc, hostname, &error);
+
+if (!error) {
+/* tls_channel_connect will call back to this
+ * function after the TLS handshake,
+ * so we mustn't call migrate_fd_connect until then
+ */
+
+return;
+}
} else {
QEMUFile *f = qemu_fopen_channel_output(ioc);
--
2.17.0
Re: [Qemu-devel] [RFC PATCH 00/11] iommu: add MemTxAttrs argument to IOMMU translate function
Hi, This series failed docker-build@min-glib build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. Type: series Message-id: 20180430181905.32327-1-peter.mayd...@linaro.org Subject: [Qemu-devel] [RFC PATCH 00/11] iommu: add MemTxAttrs argument to IOMMU translate function === TEST SCRIPT BEGIN === #!/bin/bash set -e git submodule update --init dtc # Let docker tests dump environment info export SHOW_ENV=1 export J=8 time make docker-test-build@min-glib === TEST SCRIPT END === Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384 Switched to a new branch 'test' cd9412c16c Add MemTxAttrs argument to IOMMU translate function 16fe38db6a Make flatview_do_translate() take a MemTxAttrs argument 9a1df04f18 Make address_space_get_iotlb_entry() take a MemTxAttrs argument 08589fc271 Make flatview_translate() take a MemTxAttrs argument 2395cbbe2b Make flatview_access_valid() take a MemTxAttrs argument 091afc75a7 Make MemoryRegion valid.accepts callback take a MemTxAttrs argument 52c5d9c919 Make memory_region_access_valid() take a MemTxAttrs argument 7a0cd561c3 Make flatview_extend_translation() take a MemTxAttrs argument 3378d6f6a1 Make address_space_access_valid() take a MemTxAttrs argument a311c102d6 Make address_space_map() take a MemTxAttrs argument 3ebdff307a Make address_space_translate() take a MemTxAttrs argument === OUTPUT BEGIN === Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc' Cloning into '/var/tmp/patchew-tester-tmp-4dfn8gyn/src/dtc'... Submodule path 'dtc': checked out 'e54388015af1fb4bf04d0bca99caba1074d9cc42' BUILD min-glib make[1]: Entering directory '/var/tmp/patchew-tester-tmp-4dfn8gyn/src' GEN /var/tmp/patchew-tester-tmp-4dfn8gyn/src/docker-src.2018-04-30-14.40.46.2096/qemu.tar Cloning into '/var/tmp/patchew-tester-tmp-4dfn8gyn/src/docker-src.2018-04-30-14.40.46.2096/qemu.tar.vroot'... done. Checking out files: 28% (1743/6111) Checking out files: 29% (1773/6111) Checking out files: 30% (1834/6111) Checking out files: 31% (1895/6111) Checking out files: 32% (1956/6111) Checking out files: 33% (2017/6111) Checking out files: 34% (2078/6111) Checking out files: 35% (2139/6111) Checking out files: 36% (2200/6111) Checking out files: 37% (2262/6111) Checking out files: 38% (2323/6111) Checking out files: 39% (2384/6111) Checking out files: 40% (2445/6111) Checking out files: 41% (2506/6111) Checking out files: 42% (2567/6111) Checking out files: 43% (2628/6111) Checking out files: 44% (2689/6111) Checking out files: 45% (2750/6111) Checking out files: 46% (2812/6111) Checking out files: 47% (2873/6111) Checking out files: 48% (2934/6111) Checking out files: 49% (2995/6111) Checking out files: 50% (3056/6111) Checking out files: 51% (3117/6111) Checking out files: 52% (3178/6111) Checking out files: 53% (3239/6111) Checking out files: 54% (3300/6111) Checking out files: 55% (3362/6111) Checking out files: 56% (3423/6111) Checking out files: 57% (3484/6111) Checking out files: 58% (3545/6111) Checking out files: 59% (3606/6111) Checking out files: 60% (3667/6111) Checking out files: 61% (3728/6111) Checking out files: 62% (3789/6111) Checking out files: 63% (3850/6111) Checking out files: 64% (3912/6111) Checking out files: 65% (3973/6111) Checking out files: 66% (4034/6111) Checking out files: 67% (4095/6111) Checking out files: 68% (4156/6111) Checking out files: 69% (4217/6111) Checking out files: 70% (4278/6111) Checking out files: 71% (4339/6111) Checking out files: 72% (4400/6111) Checking out files: 73% (4462/6111) Checking out files: 74% (4523/6111) Checking out files: 75% (4584/6111) Checking out files: 76% (4645/6111) Checking out files: 77% (4706/6111) Checking out files: 78% (4767/6111) Checking out files: 79% (4828/6111) Checking out files: 80% (4889/6111) Checking out files: 81% (4950/6111) Checking out files: 82% (5012/6111) Checking out files: 83% (5073/6111) Checking out files: 84% (5134/6111) Checking out files: 85% (5195/6111) Checking out files: 86% (5256/6111) Checking out files: 87% (5317/6111) Checking out files: 88% (5378/6111) Checking out files: 89% (5439/6111) Checking out files: 90% (5500/6111) Checking out files: 91% (5562/6111) Checking out files: 92% (5623/6111) Checking out files: 93% (5684/6111) Checking out files: 94% (5745/6111) Checking out files: 95% (5806/6111) Checking out files: 96% (5867/6111) Checking out files: 97% (5928/6111) Checking out files: 98% (5989/6111) Checking out files: 99% (6050/6111) Checking out files: 100% (6111/6111) Checking out files: 100% (6111/6111), done. Your branch is up-to-date with 'origin/test'. Submodule 'dtc' (git://git.qe
Re: [Qemu-devel] [RFC PATCH 00/11] iommu: add MemTxAttrs argument to IOMMU translate function
Hi, This series failed 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. Type: series Message-id: 20180430181905.32327-1-peter.mayd...@linaro.org Subject: [Qemu-devel] [RFC PATCH 00/11] iommu: add MemTxAttrs argument to IOMMU translate function === TEST SCRIPT BEGIN === #!/bin/bash set -e git submodule update --init dtc # Let docker tests dump environment info export SHOW_ENV=1 export J=8 time make docker-test-mingw@fedora === TEST SCRIPT END === Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384 Switched to a new branch 'test' cd9412c16c Add MemTxAttrs argument to IOMMU translate function 16fe38db6a Make flatview_do_translate() take a MemTxAttrs argument 9a1df04f18 Make address_space_get_iotlb_entry() take a MemTxAttrs argument 08589fc271 Make flatview_translate() take a MemTxAttrs argument 2395cbbe2b Make flatview_access_valid() take a MemTxAttrs argument 091afc75a7 Make MemoryRegion valid.accepts callback take a MemTxAttrs argument 52c5d9c919 Make memory_region_access_valid() take a MemTxAttrs argument 7a0cd561c3 Make flatview_extend_translation() take a MemTxAttrs argument 3378d6f6a1 Make address_space_access_valid() take a MemTxAttrs argument a311c102d6 Make address_space_map() take a MemTxAttrs argument 3ebdff307a Make address_space_translate() take a MemTxAttrs argument === OUTPUT BEGIN === Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc' Cloning into '/var/tmp/patchew-tester-tmp-wmtn08ap/src/dtc'... Submodule path 'dtc': checked out 'e54388015af1fb4bf04d0bca99caba1074d9cc42' BUILD fedora make[1]: Entering directory '/var/tmp/patchew-tester-tmp-wmtn08ap/src' GEN /var/tmp/patchew-tester-tmp-wmtn08ap/src/docker-src.2018-04-30-14.34.38.27157/qemu.tar Cloning into '/var/tmp/patchew-tester-tmp-wmtn08ap/src/docker-src.2018-04-30-14.34.38.27157/qemu.tar.vroot'... done. Checking out files: 26% (1605/6111) Checking out files: 27% (1650/6111) Checking out files: 28% (1712/6111) Checking out files: 29% (1773/6111) Checking out files: 30% (1834/6111) Checking out files: 31% (1895/6111) Checking out files: 32% (1956/6111) Checking out files: 33% (2017/6111) Checking out files: 34% (2078/6111) Checking out files: 35% (2139/6111) Checking out files: 36% (2200/6111) Checking out files: 37% (2262/6111) Checking out files: 38% (2323/6111) Checking out files: 39% (2384/6111) Checking out files: 40% (2445/6111) Checking out files: 41% (2506/6111) Checking out files: 42% (2567/6111) Checking out files: 43% (2628/6111) Checking out files: 44% (2689/6111) Checking out files: 45% (2750/6111) Checking out files: 46% (2812/6111) Checking out files: 47% (2873/6111) Checking out files: 48% (2934/6111) Checking out files: 49% (2995/6111) Checking out files: 50% (3056/6111) Checking out files: 51% (3117/6111) Checking out files: 52% (3178/6111) Checking out files: 53% (3239/6111) Checking out files: 54% (3300/6111) Checking out files: 55% (3362/6111) Checking out files: 56% (3423/6111) Checking out files: 57% (3484/6111) Checking out files: 58% (3545/6111) Checking out files: 59% (3606/6111) Checking out files: 60% (3667/6111) Checking out files: 61% (3728/6111) Checking out files: 62% (3789/6111) Checking out files: 63% (3850/6111) Checking out files: 64% (3912/6111) Checking out files: 65% (3973/6111) Checking out files: 66% (4034/6111) Checking out files: 67% (4095/6111) Checking out files: 68% (4156/6111) Checking out files: 68% (4176/6111) Checking out files: 69% (4217/6111) Checking out files: 70% (4278/6111) Checking out files: 71% (4339/6111) Checking out files: 72% (4400/6111) Checking out files: 73% (4462/6111) Checking out files: 74% (4523/6111) Checking out files: 75% (4584/6111) Checking out files: 76% (4645/6111) Checking out files: 77% (4706/6111) Checking out files: 78% (4767/6111) Checking out files: 79% (4828/6111) Checking out files: 80% (4889/6111) Checking out files: 81% (4950/6111) Checking out files: 82% (5012/6111) Checking out files: 83% (5073/6111) Checking out files: 84% (5134/6111) Checking out files: 85% (5195/6111) Checking out files: 86% (5256/6111) Checking out files: 87% (5317/6111) Checking out files: 88% (5378/6111) Checking out files: 89% (5439/6111) Checking out files: 90% (5500/6111) Checking out files: 91% (5562/6111) Checking out files: 92% (5623/6111) Checking out files: 93% (5684/6111) Checking out files: 94% (5745/6111) Checking out files: 95% (5806/6111) Checking out files: 96% (5867/6111) Checking out files: 97% (5928/6111) Checking out files: 98% (5989/6111) Checking out files: 99% (6050/6111) Checking out files: 100% (6111/6111) Che
Re: [Qemu-devel] [RFC PATCH 00/11] iommu: add MemTxAttrs argument to IOMMU translate function
Hi, This series failed build test on s390x host. Please find the details below. Type: series Message-id: 20180430181905.32327-1-peter.mayd...@linaro.org Subject: [Qemu-devel] [RFC PATCH 00/11] iommu: add MemTxAttrs argument to IOMMU translate function === TEST SCRIPT BEGIN === #!/bin/bash # Testing script will be invoked under the git checkout with # HEAD pointing to a commit that has the patches applied on top of "base" # branch set -e echo "=== ENV ===" env echo "=== PACKAGES ===" rpm -qa echo "=== TEST BEGIN ===" CC=$HOME/bin/cc INSTALL=$PWD/install BUILD=$PWD/build echo -n "Using CC: " realpath $CC mkdir -p $BUILD $INSTALL SRC=$PWD cd $BUILD $SRC/configure --cc=$CC --prefix=$INSTALL make -j4 # XXX: we need reliable clean up # make check -j4 V=1 make install === TEST SCRIPT END === Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384 From https://github.com/patchew-project/qemu * [new tag] patchew/20180430181905.32327-1-peter.mayd...@linaro.org -> patchew/20180430181905.32327-1-peter.mayd...@linaro.org Switched to a new branch 'test' cd9412c16c Add MemTxAttrs argument to IOMMU translate function 16fe38db6a Make flatview_do_translate() take a MemTxAttrs argument 9a1df04f18 Make address_space_get_iotlb_entry() take a MemTxAttrs argument 08589fc271 Make flatview_translate() take a MemTxAttrs argument 2395cbbe2b Make flatview_access_valid() take a MemTxAttrs argument 091afc75a7 Make MemoryRegion valid.accepts callback take a MemTxAttrs argument 52c5d9c919 Make memory_region_access_valid() take a MemTxAttrs argument 7a0cd561c3 Make flatview_extend_translation() take a MemTxAttrs argument 3378d6f6a1 Make address_space_access_valid() take a MemTxAttrs argument a311c102d6 Make address_space_map() take a MemTxAttrs argument 3ebdff307a Make address_space_translate() take a MemTxAttrs argument === OUTPUT BEGIN === === ENV === LANG=en_US.UTF-8 XDG_SESSION_ID=162768 USER=fam PWD=/var/tmp/patchew-tester-tmp-8r5jv968/src HOME=/home/fam SHELL=/bin/sh SHLVL=2 PATCHEW=/home/fam/patchew/patchew-cli -s http://patchew.org --nodebug LOGNAME=fam DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1012/bus XDG_RUNTIME_DIR=/run/user/1012 PATH=/usr/bin:/bin _=/usr/bin/env === PACKAGES === gpg-pubkey-873529b8-54e386ff glibc-debuginfo-common-2.24-10.fc25.s390x fedora-release-26-1.noarch dejavu-sans-mono-fonts-2.35-4.fc26.noarch xemacs-filesystem-21.5.34-22.20170124hgf412e9f093d4.fc26.noarch bash-4.4.12-7.fc26.s390x libSM-1.2.2-5.fc26.s390x libmpc-1.0.2-6.fc26.s390x libaio-0.3.110-7.fc26.s390x libverto-0.2.6-7.fc26.s390x perl-Scalar-List-Utils-1.48-1.fc26.s390x iptables-libs-1.6.1-2.fc26.s390x tcl-8.6.6-2.fc26.s390x libxshmfence-1.2-4.fc26.s390x expect-5.45-23.fc26.s390x perl-Thread-Queue-3.12-1.fc26.noarch perl-encoding-2.19-6.fc26.s390x keyutils-1.5.10-1.fc26.s390x gmp-devel-6.1.2-4.fc26.s390x enchant-1.6.0-16.fc26.s390x python-gobject-base-3.24.1-1.fc26.s390x python3-enchant-1.6.10-1.fc26.noarch python-lockfile-0.11.0-6.fc26.noarch python2-pyparsing-2.1.10-3.fc26.noarch python2-lxml-4.1.1-1.fc26.s390x librados2-10.2.7-2.fc26.s390x trousers-lib-0.3.13-7.fc26.s390x libdatrie-0.2.9-4.fc26.s390x libsoup-2.58.2-1.fc26.s390x passwd-0.79-9.fc26.s390x bind99-libs-9.9.10-3.P3.fc26.s390x python3-rpm-4.13.0.2-1.fc26.s390x systemd-233-7.fc26.s390x virglrenderer-0.6.0-1.20170210git76b3da97b.fc26.s390x s390utils-ziomon-1.36.1-3.fc26.s390x s390utils-osasnmpd-1.36.1-3.fc26.s390x libXrandr-1.5.1-2.fc26.s390x libglvnd-glx-1.0.0-1.fc26.s390x texlive-ifxetex-svn19685.0.5-33.fc26.2.noarch texlive-psnfss-svn33946.9.2a-33.fc26.2.noarch texlive-dvipdfmx-def-svn40328-33.fc26.2.noarch texlive-natbib-svn20668.8.31b-33.fc26.2.noarch texlive-xdvi-bin-svn40750-33.20160520.fc26.2.s390x texlive-cm-svn32865.0-33.fc26.2.noarch texlive-beton-svn15878.0-33.fc26.2.noarch texlive-fpl-svn15878.1.002-33.fc26.2.noarch texlive-mflogo-svn38628-33.fc26.2.noarch texlive-texlive-docindex-svn41430-33.fc26.2.noarch texlive-luaotfload-bin-svn34647.0-33.20160520.fc26.2.noarch texlive-koma-script-svn41508-33.fc26.2.noarch texlive-pst-tree-svn24142.1.12-33.fc26.2.noarch texlive-breqn-svn38099.0.98d-33.fc26.2.noarch texlive-xetex-svn41438-33.fc26.2.noarch gstreamer1-plugins-bad-free-1.12.3-1.fc26.s390x xorg-x11-font-utils-7.5-33.fc26.s390x ghostscript-fonts-5.50-36.fc26.noarch libXext-devel-1.3.3-5.fc26.s390x libusbx-devel-1.0.21-2.fc26.s390x libglvnd-devel-1.0.0-1.fc26.s390x emacs-25.3-3.fc26.s390x alsa-lib-devel-1.1.4.1-1.fc26.s390x kbd-2.0.4-2.fc26.s390x dconf-0.26.0-2.fc26.s390x mc-4.8.19-5.fc26.s390x doxygen-1.8.13-9.fc26.s390x dpkg-1.18.24-1.fc26.s390x libtdb-1.3.13-1.fc26.s390x python2-pynacl-1.1.1-1.fc26.s390x perl-Filter-1.58-1.fc26.s390x python2-pip-9.0.1-11.fc26.noarch dnf-2.7.5-2.fc26.noarch bind-license-9.11.2-1.P1.fc26.noarch libtasn1-4.13-1.fc26.s390x cpp-7.3.1-2.fc26.s390x pkgconf-1.3.12-2.fc26.s390x python2-fedora-0.10.0-1.fc26.noarch cmake-filesystem-3.10.1-11.fc26.s390x python3-requests-kerberos-0.12.0-1.fc26.noarch libmicrohttpd-0.9.59-1.fc26.s390x
Re: [Qemu-devel] [PULL 11/13] migration: add postcopy migration of dirty bitmaps
On 04/27/2018 09:22 AM, Peter Maydell wrote:
> On 13 March 2018 at 21:14, John Snow wrote:
>> From: Vladimir Sementsov-Ogievskiy
>>
>> Postcopy migration of dirty bitmaps. Only named dirty bitmaps are migrated.
>>
>> If destination qemu is already containing a dirty bitmap with the same name
>> as a migrated bitmap (for the same node), then, if their granularities are
>> the same the migration will be done, otherwise the error will be generated.
>>
>> If destination qemu doesn't contain such bitmap it will be created.
>>
>> Signed-off-by: Vladimir Sementsov-Ogievskiy
>> Reviewed-by: Dr. David Alan Gilbert
>> Message-id: 20180313180320.339796-12-vsement...@virtuozzo.com
>> [Changed '+' to '*' as per list discussion. --js]
>> Signed-off-by: John Snow
>
>> +static int init_dirty_bitmap_migration(void)
>> +{
>
> Hi; Coverity (CID1390625) complains about a possible dereference
> after NULL check in this function:
>
>> +BlockDriverState *bs;
>> +BdrvDirtyBitmap *bitmap;
>> +DirtyBitmapMigBitmapState *dbms;
>> +BdrvNextIterator it;
>> +
>> +dirty_bitmap_mig_state.bulk_completed = false;
>> +dirty_bitmap_mig_state.prev_bs = NULL;
>> +dirty_bitmap_mig_state.prev_bitmap = NULL;
>> +dirty_bitmap_mig_state.no_bitmaps = false;
>> +
>> +for (bs = bdrv_first(&it); bs; bs = bdrv_next(&it)) {
>> +const char *drive_name = bdrv_get_device_or_node_name(bs);
>> +
>> +/* skip automatically inserted nodes */
>> +while (bs && bs->drv && bs->implicit) {
>> +bs = backing_bs(bs);
>> +}
>
> The 'bs' test in this while() loop implies that we might
> leave the loop because bs == NULL...
>
>> +
>> +for (bitmap = bdrv_dirty_bitmap_next(bs, NULL); bitmap;
>
> ...but this call to bdrv_dirty_bitmap_next() will always
> dereference bs, so if it's NULL we'll crash.
>
>> + bitmap = bdrv_dirty_bitmap_next(bs, bitmap))
>
> thanks
> -- PMM
>
I have some patches on the way to clean up this file. Sorry for the delay.
[Qemu-devel] [RFC PATCH 01/11] Make address_space_translate() take a MemTxAttrs argument
As part of plumbing MemTxAttrs down to the IOMMU translate method,
add MemTxAttrs as an argument to address_space_translate().
Its callers either have an attrs value to hand, or don't care
and can use MEMTXATTRS_UNSPECIFIED.
Signed-off-by: Peter Maydell
---
include/exec/memory.h | 4 +++-
accel/tcg/translate-all.c | 2 +-
exec.c| 6 --
hw/vfio/common.c | 3 ++-
memory_ldst.inc.c | 18 +-
target/riscv/helper.c | 2 +-
6 files changed, 20 insertions(+), 15 deletions(-)
diff --git a/include/exec/memory.h b/include/exec/memory.h
index e62965a0c8..f416d1e985 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -1909,6 +1909,7 @@ IOMMUTLBEntry address_space_get_iotlb_entry(AddressSpace
*as, hwaddr addr,
* #MemoryRegion.
* @len: pointer to length
* @is_write: indicates the transfer direction
+ * @attrs: memory attributes
*/
MemoryRegion *flatview_translate(FlatView *fv,
hwaddr addr, hwaddr *xlat,
@@ -1916,7 +1917,8 @@ MemoryRegion *flatview_translate(FlatView *fv,
static inline MemoryRegion *address_space_translate(AddressSpace *as,
hwaddr addr, hwaddr *xlat,
-hwaddr *len, bool is_write)
+hwaddr *len, bool is_write,
+MemTxAttrs attrs)
{
return flatview_translate(address_space_to_flatview(as),
addr, xlat, len, is_write);
diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
index f04a922ef7..52f7bd59a9 100644
--- a/accel/tcg/translate-all.c
+++ b/accel/tcg/translate-all.c
@@ -1679,7 +1679,7 @@ void tb_invalidate_phys_addr(AddressSpace *as, hwaddr
addr, MemTxAttrs attrs)
hwaddr l = 1;
rcu_read_lock();
-mr = address_space_translate(as, addr, &addr, &l, false);
+mr = address_space_translate(as, addr, &addr, &l, false, attrs);
if (!(memory_region_is_ram(mr)
|| memory_region_is_romd(mr))) {
rcu_read_unlock();
diff --git a/exec.c b/exec.c
index df35e6dd85..a0f27b7b8c 100644
--- a/exec.c
+++ b/exec.c
@@ -3287,7 +3287,8 @@ static inline void
cpu_physical_memory_write_rom_internal(AddressSpace *as,
rcu_read_lock();
while (len > 0) {
l = len;
-mr = address_space_translate(as, addr, &addr1, &l, true);
+mr = address_space_translate(as, addr, &addr1, &l, true,
+ MEMTXATTRS_UNSPECIFIED);
if (!(memory_region_is_ram(mr) ||
memory_region_is_romd(mr))) {
@@ -3716,7 +3717,8 @@ bool cpu_physical_memory_is_io(hwaddr phys_addr)
rcu_read_lock();
mr = address_space_translate(&address_space_memory,
- phys_addr, &phys_addr, &l, false);
+ phys_addr, &phys_addr, &l, false,
+ MEMTXATTRS_UNSPECIFIED);
res = !(memory_region_is_ram(mr) || memory_region_is_romd(mr));
rcu_read_unlock();
diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index 07ffa0ba10..8e57265edf 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -324,7 +324,8 @@ static bool vfio_get_vaddr(IOMMUTLBEntry *iotlb, void
**vaddr,
*/
mr = address_space_translate(&address_space_memory,
iotlb->translated_addr,
- &xlat, &len, writable);
+ &xlat, &len, writable,
+ MEMTXATTRS_UNSPECIFIED);
if (!memory_region_is_ram(mr)) {
error_report("iommu map to non memory area %"HWADDR_PRIx"",
xlat);
diff --git a/memory_ldst.inc.c b/memory_ldst.inc.c
index 5dbff9cef8..860ba31ac8 100644
--- a/memory_ldst.inc.c
+++ b/memory_ldst.inc.c
@@ -33,7 +33,7 @@ static inline uint32_t glue(address_space_ldl_internal,
SUFFIX)(ARG1_DECL,
bool release_lock = false;
RCU_READ_LOCK();
-mr = TRANSLATE(addr, &addr1, &l, false);
+mr = TRANSLATE(addr, &addr1, &l, false, attrs);
if (l < 4 || !IS_DIRECT(mr, false)) {
release_lock |= prepare_mmio_access(mr);
@@ -127,7 +127,7 @@ static inline uint64_t glue(address_space_ldq_internal,
SUFFIX)(ARG1_DECL,
bool release_lock = false;
RCU_READ_LOCK();
-mr = TRANSLATE(addr, &addr1, &l, false);
+mr = TRANSLATE(addr, &addr1, &l, false, attrs);
if (l < 8 || !IS_DIRECT(mr, false)) {
release_lock |= prepare_mmio_access(mr);
@@ -219,7 +219,7 @@ uint32_t glue(address_space_ldub, SUFFIX)(ARG1_DECL,
bool release_lock = false;
RCU_READ_LOCK();
-mr = TRANSLATE(addr, &addr1, &l, false);
+mr = TRANSLATE(addr, &addr1, &l, false, attrs);
if (!IS_DIRECT(mr, false)) {
release_lock |= prepare_mmio_access(mr);
@@ -261,7 +261,7 @@ static inline uint32_t glue(address_space_ld
[Qemu-devel] [RFC PATCH 07/11] Make flatview_access_valid() take a MemTxAttrs argument
As part of plumbing MemTxAttrs down to the IOMMU translate method,
add MemTxAttrs as an argument to flatview_access_valid().
Its callers now all have an attrs value to hand, so we can
correct our earlier temporary use of MEMTXATTRS_UNSPECIFIED.
Signed-off-by: Peter Maydell
---
exec.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/exec.c b/exec.c
index 3ceeb0643f..0eef4702a5 100644
--- a/exec.c
+++ b/exec.c
@@ -2662,7 +2662,7 @@ static MemTxResult flatview_read(FlatView *fv, hwaddr
addr,
static MemTxResult flatview_write(FlatView *fv, hwaddr addr, MemTxAttrs attrs,
const uint8_t *buf, int len);
static bool flatview_access_valid(FlatView *fv, hwaddr addr, int len,
- bool is_write);
+ bool is_write, MemTxAttrs attrs);
static MemTxResult subpage_read(void *opaque, hwaddr addr, uint64_t *data,
unsigned len, MemTxAttrs attrs)
@@ -2738,7 +2738,7 @@ static bool subpage_accepts(void *opaque, hwaddr addr,
#endif
return flatview_access_valid(subpage->fv, addr + subpage->base,
- len, is_write);
+ len, is_write, attrs);
}
static const MemoryRegionOps subpage_ops = {
@@ -3426,7 +3426,7 @@ static void cpu_notify_map_clients(void)
}
static bool flatview_access_valid(FlatView *fv, hwaddr addr, int len,
- bool is_write)
+ bool is_write, MemTxAttrs attrs)
{
MemoryRegion *mr;
hwaddr l, xlat;
@@ -3437,8 +3437,7 @@ static bool flatview_access_valid(FlatView *fv, hwaddr
addr, int len,
if (!memory_access_is_direct(mr, is_write)) {
l = memory_access_size(mr, l, addr);
/* When our callers all have attrs we'll pass them through here */
-if (!memory_region_access_valid(mr, xlat, l, is_write,
-MEMTXATTRS_UNSPECIFIED)) {
+if (!memory_region_access_valid(mr, xlat, l, is_write, attrs)) {
return false;
}
}
@@ -3458,7 +3457,7 @@ bool address_space_access_valid(AddressSpace *as, hwaddr
addr,
rcu_read_lock();
fv = address_space_to_flatview(as);
-result = flatview_access_valid(fv, addr, len, is_write);
+result = flatview_access_valid(fv, addr, len, is_write, attrs);
rcu_read_unlock();
return result;
}
--
2.17.0
[Qemu-devel] [RFC PATCH 11/11] Add MemTxAttrs argument to IOMMU translate function
Add a MemTxAttrs argument to the IOMMU translate function; this is
necessary for IOMMU implementations that care about transaction
attributes such as user/privileged or secure/nonsecure when
deciding whether a transaction is permitted.
Signed-off-by: Peter Maydell
---
include/exec/memory.h| 3 ++-
exec.c | 2 +-
hw/alpha/typhoon.c | 3 ++-
hw/dma/rc4030.c | 3 ++-
hw/i386/amd_iommu.c | 3 ++-
hw/i386/intel_iommu.c| 3 ++-
hw/ppc/spapr_iommu.c | 3 ++-
hw/s390x/s390-pci-bus.c | 3 ++-
hw/sparc/sun4m_iommu.c | 3 ++-
hw/sparc64/sun4u_iommu.c | 3 ++-
memory.c | 3 ++-
11 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/include/exec/memory.h b/include/exec/memory.h
index 16a82d9722..2c7dd4b373 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -221,9 +221,10 @@ typedef struct IOMMUMemoryRegionClass {
* @iommu: the IOMMUMemoryRegion
* @hwaddr: address to be translated within the memory region
* @flag: requested access permissions
+ * @attrs: memory transaction attributes
*/
IOMMUTLBEntry (*translate)(IOMMUMemoryRegion *iommu, hwaddr addr,
- IOMMUAccessFlags flag);
+ IOMMUAccessFlags flag, MemTxAttrs attrs);
/* Returns minimum supported page size in bytes.
* If this method is not provided then the minimum is assumed to
* be TARGET_PAGE_SIZE.
diff --git a/exec.c b/exec.c
index 9c6d9aae28..e346424172 100644
--- a/exec.c
+++ b/exec.c
@@ -513,7 +513,7 @@ static MemoryRegionSection flatview_do_translate(FlatView
*fv,
imrc = memory_region_get_iommu_class_nocheck(iommu_mr);
iotlb = imrc->translate(iommu_mr, addr, is_write ?
-IOMMU_WO : IOMMU_RO);
+IOMMU_WO : IOMMU_RO, attrs);
addr = ((iotlb.translated_addr & ~iotlb.addr_mask)
| (addr & iotlb.addr_mask));
page_mask &= iotlb.addr_mask;
diff --git a/hw/alpha/typhoon.c b/hw/alpha/typhoon.c
index 6a40869488..49192ab24d 100644
--- a/hw/alpha/typhoon.c
+++ b/hw/alpha/typhoon.c
@@ -666,7 +666,8 @@ static bool window_translate(TyphoonWindow *win, hwaddr
addr,
Pchip and generate a machine check interrupt. */
static IOMMUTLBEntry typhoon_translate_iommu(IOMMUMemoryRegion *iommu,
hwaddr addr,
- IOMMUAccessFlags flag)
+ IOMMUAccessFlags flag,
+ MemTxAttrs attrs)
{
TyphoonPchip *pchip = container_of(iommu, TyphoonPchip, iommu);
IOMMUTLBEntry ret;
diff --git a/hw/dma/rc4030.c b/hw/dma/rc4030.c
index 5d4833eeca..89686ae7dc 100644
--- a/hw/dma/rc4030.c
+++ b/hw/dma/rc4030.c
@@ -491,7 +491,8 @@ static const MemoryRegionOps jazzio_ops = {
};
static IOMMUTLBEntry rc4030_dma_translate(IOMMUMemoryRegion *iommu, hwaddr
addr,
- IOMMUAccessFlags flag)
+ IOMMUAccessFlags flag,
+ MemTxAttrs attrs)
{
rc4030State *s = container_of(iommu, rc4030State, dma_mr);
IOMMUTLBEntry ret = {
diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
index 63d46ff6ee..5f530b5fe6 100644
--- a/hw/i386/amd_iommu.c
+++ b/hw/i386/amd_iommu.c
@@ -991,7 +991,8 @@ static inline bool amdvi_is_interrupt_addr(hwaddr addr)
}
static IOMMUTLBEntry amdvi_translate(IOMMUMemoryRegion *iommu, hwaddr addr,
- IOMMUAccessFlags flag)
+ IOMMUAccessFlags flag,
+ MemTxAttrs attrs)
{
AMDVIAddressSpace *as = container_of(iommu, AMDVIAddressSpace, iommu);
AMDVIState *s = as->iommu_state;
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index fb31de9416..483ff305f8 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -2282,7 +2282,8 @@ static void vtd_mem_write(void *opaque, hwaddr addr,
}
static IOMMUTLBEntry vtd_iommu_translate(IOMMUMemoryRegion *iommu, hwaddr addr,
- IOMMUAccessFlags flag)
+ IOMMUAccessFlags flag,
+ MemTxAttrs attrs)
{
VTDAddressSpace *vtd_as = container_of(iommu, VTDAddressSpace, iommu);
IntelIOMMUState *s = vtd_as->iommu_state;
diff --git a/hw/ppc/spapr_iommu.c b/hw/ppc/spapr_iommu.c
index aaa6010d5c..199612095a 100644
--- a/hw/ppc/spapr_iommu.c
+++ b/hw/ppc/spapr_iommu.c
@@ -112,7 +112,8 @@ static void spapr_tce_free_table(uint64_t *table, int fd,
uint32_t nb_table)
/* Called from RCU critical section */
static IOMMUTLBEntry spapr_tce_translate_iommu(IOMMUMemoryRegion *iommu,
hwaddr addr,
- IOM
[Qemu-devel] [Bug 1745312] Re: Regression report: Disk subsystem I/O failures/issues surfacing in DOS/early Windows [two separate issues: one bisected, one root-caused]
I have a similar bug: 1674114
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1745312
Title:
Regression report: Disk subsystem I/O failures/issues surfacing in
DOS/early Windows [two separate issues: one bisected, one root-caused]
Status in QEMU:
New
Bug description:
[Headsup: This report is long-ish due to the amount of detail I've
stumbled on along the way that I think is relevant to include. I can't
speak as to the complexity of the actual bugs, but the size of this
report should not suggest that the reproduction process is
particularly headache-inducing.]
Hi!
I recently needed to fire up some ancient software for research
purposes and got very distracted discovering and playing with old
versions of Windows :). In the process I've discovered some glitches
with disk I/O.
I believe I've stumbled on two completely separate issues that
coincidentally surfaced at the same time. It's possible that
components of this report will be re-filed as more specific new bugs,
but I'm not an authority on QEMU internals or how to narrow
down/categorize what I've found.
- The first bug only surfaces when the "isapc" machine type is used.
It intermittently produces "General failure {read,writ}ing drive _"
under MS-DOS 6.22, and also somehow interferes with early bootstrap of
Windows NT 4 (in NTLDR). Enabling or disabling KVM (I'm on Linux)
appears to make no difference whatsoever, which may help with
debugging.
- The second issue involves
- a WinNT4 disk image
- created by running through a bog-standard NT4 install inside QEMU 2.9.0
- which will now fail to boot in any version of QEMU - even version 1.0
- but which VirtualBox will boot fine
- but only if I point VirtualBox at QEMU's raw disk image via a
hacked-together VMDK file
- if the raw image is converted to VHD(X), VirtualBox will also fail
to boot the image with exactly the same error as QEMU
- this state of affairs is not affected by image sparseness (which makes
sense)
I'm confident I've bisected the first issue.
I wasn't able to bisect the second issue (as all tested versions of
QEMU behaved identically), but I've figured out a working repro
testcase and I believe I've managed to pin down a solid root cause.
== #1: Intermittent I/O issues when `-M isapc` is used =
These symptoms sometimes take a small amount of time and fiddling to
trigger, but I AM able to consistently surface them on my machine
after a short while. (I am very very interested to hear if others
cannot reproduce them.)
So, first of all:
https://github.com/qemu/qemu/commit/306ec6c3cece7004429c79c1ac93d49919f1f1cc
(Jul 30 2013): the last version that works
https://github.com/qemu/qemu/commit/e689f7c668cbd9d08f330e17c3dd3a059c9553d3
(Oct 30 2013): the first version that intermittently fails
Maybe lift out and build these branches while reading. *shrug*
(How to do this can be found at the end of this report - along with a
time-saving ./configure line, FWIW)
Here are the changelists between these two revisions:
https://github.com/qemu/qemu/compare/306ec6c...e689f7c
(Compare direction: OLD to NEW) (Commits: 166 Files changed: 192)
https://github.com/qemu/qemu/compare/e689f7c...306ec6c
(Compare direction: NEW to OLD) (Commits: 30 Files changed: 22)
(Someone else more familiar with Git might know why GitHub returns
results for both compare directions, and/or if the 2nd link is useful
information. The first link returns a lot more results than the 2nd
one, at least. Does comparing new>old return deletions?)
---
Now on to the symptoms. In a moment I'll describe reproduction.
# MS-DOS 6.22
The first symptom I discovered was that trivial read and write
operations under MS-DOS would sometimes fail:
C:\>echo test > hi
General failure writing drive C
Abort, Retry, Fail?
Anything else that exercises the disk behaves similarly:
C:\>dir /s > nul
General failure reading drive C
Abort, Retry, Fail?
(Note that the above demonstrates both write and read failures)
(Also, FWIW, `dir /s` == `ls -R`)
The behavior of the I/O errors is not possible to characterise as it
fluctuates so much. For example something as simple as DIR can produce
wildly differing results: in one run, poking around with DIR ended
with DOS deciding C:\ was empty at one point; at another point in a
different run C:\ mysteriously dropped 50% of its contents only to
magically gain it all back moments later after some poking around in
one of the subdirectories that was still visible.
The time it takes to trigger these errors is also highly variable.
QEMU may fall over as early as hanging forever at "Starting MS-
DOS...", or I might get all the way into Windows 3.1 before it
triggers (
[Qemu-devel] [RFC PATCH 06/11] Make MemoryRegion valid.accepts callback take a MemTxAttrs argument
As part of plumbing MemTxAttrs down to the IOMMU translate method,
add MemTxAttrs as an argument to the MemoryRegion valid.accepts
callback. We'll need this for subpage_accepts().
We could take the approach we used with the read and write
callbacks and add new a new _with_attrs version, but since there
are so few implementations of the accepts hook we just change
them all.
Signed-off-by: Peter Maydell
---
include/exec/memory.h | 3 ++-
exec.c| 9 ++---
hw/hppa/dino.c| 3 ++-
hw/nvram/fw_cfg.c | 12
hw/scsi/esp.c | 3 ++-
hw/xen/xen_pt_msi.c | 3 ++-
memory.c | 5 +++--
7 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/include/exec/memory.h b/include/exec/memory.h
index eb1ceace27..7c461b9718 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -166,7 +166,8 @@ struct MemoryRegionOps {
* as a machine check exception).
*/
bool (*accepts)(void *opaque, hwaddr addr,
-unsigned size, bool is_write);
+unsigned size, bool is_write,
+MemTxAttrs attrs);
} valid;
/* Internal implementation constraints: */
struct {
diff --git a/exec.c b/exec.c
index 57a984758e..3ceeb0643f 100644
--- a/exec.c
+++ b/exec.c
@@ -2504,7 +2504,8 @@ static void notdirty_mem_write(void *opaque, hwaddr
ram_addr,
}
static bool notdirty_mem_accepts(void *opaque, hwaddr addr,
- unsigned size, bool is_write)
+ unsigned size, bool is_write,
+ MemTxAttrs attrs)
{
return is_write;
}
@@ -2727,7 +2728,8 @@ static MemTxResult subpage_write(void *opaque, hwaddr
addr,
}
static bool subpage_accepts(void *opaque, hwaddr addr,
-unsigned len, bool is_write)
+unsigned len, bool is_write,
+MemTxAttrs attrs)
{
subpage_t *subpage = opaque;
#if defined(DEBUG_SUBPAGE)
@@ -2810,7 +2812,8 @@ static void readonly_mem_write(void *opaque, hwaddr addr,
}
static bool readonly_mem_accepts(void *opaque, hwaddr addr,
- unsigned size, bool is_write)
+ unsigned size, bool is_write,
+ MemTxAttrs attrs)
{
return is_write;
}
diff --git a/hw/hppa/dino.c b/hw/hppa/dino.c
index 15aefde09c..77463672a3 100644
--- a/hw/hppa/dino.c
+++ b/hw/hppa/dino.c
@@ -137,7 +137,8 @@ static void gsc_to_pci_forwarding(DinoState *s)
}
static bool dino_chip_mem_valid(void *opaque, hwaddr addr,
-unsigned size, bool is_write)
+unsigned size, bool is_write,
+MemTxAttrs attrs)
{
switch (addr) {
case DINO_IAR0:
diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index 2a0739d0e9..b23e7f64a8 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -420,14 +420,16 @@ static void fw_cfg_dma_mem_write(void *opaque, hwaddr
addr,
}
static bool fw_cfg_dma_mem_valid(void *opaque, hwaddr addr,
- unsigned size, bool is_write)
+ unsigned size, bool is_write,
+ MemTxAttrs attrs)
{
return !is_write || ((size == 4 && (addr == 0 || addr == 4)) ||
(size == 8 && addr == 0));
}
static bool fw_cfg_data_mem_valid(void *opaque, hwaddr addr,
- unsigned size, bool is_write)
+ unsigned size, bool is_write,
+ MemTxAttrs attrs)
{
return addr == 0;
}
@@ -439,7 +441,8 @@ static void fw_cfg_ctl_mem_write(void *opaque, hwaddr addr,
}
static bool fw_cfg_ctl_mem_valid(void *opaque, hwaddr addr,
- unsigned size, bool is_write)
+ unsigned size, bool is_write,
+ MemTxAttrs attrs)
{
return is_write && size == 2;
}
@@ -458,7 +461,8 @@ static void fw_cfg_comb_write(void *opaque, hwaddr addr,
}
static bool fw_cfg_comb_valid(void *opaque, hwaddr addr,
- unsigned size, bool is_write)
+ unsigned size, bool is_write,
+ MemTxAttrs attrs)
{
return (size == 1) || (is_write && size == 2);
}
diff --git a/hw/scsi/esp.c b/hw/scsi/esp.c
index 64ec285826..9ed9727744 100644
--- a/hw/scsi/esp.c
+++ b/hw/scsi/esp.c
@@ -564,7 +564,8 @@ void esp_reg_write(ESPState *s, uint32_t saddr, uint64_t
val)
}
static bool esp_mem_accepts(void *opaque, hwaddr addr,
-unsigned size, bool is_write)
+unsigned size, bool is_write,
+MemTxAttrs attrs)
{
return (size == 1) || (is_write && size == 4);
}
diff --gi
[Qemu-devel] [RFC PATCH 10/11] Make flatview_do_translate() take a MemTxAttrs argument
As part of plumbing MemTxAttrs down to the IOMMU translate method,
add MemTxAttrs as an argument to flatview_do_translate().
Signed-off-by: Peter Maydell
---
exec.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/exec.c b/exec.c
index c29bf47ce2..9c6d9aae28 100644
--- a/exec.c
+++ b/exec.c
@@ -476,6 +476,7 @@ address_space_translate_internal(AddressSpaceDispatch *d,
hwaddr addr, hwaddr *x
*would tell. It can be @NULL if we don't care about it.
* @is_write: whether the translation operation is for write
* @is_mmio: whether this can be MMIO, set true if it can
+ * @attrs: memory transaction attributes
*
* This function is called from RCU critical section
*/
@@ -486,7 +487,8 @@ static MemoryRegionSection flatview_do_translate(FlatView
*fv,
hwaddr *page_mask_out,
bool is_write,
bool is_mmio,
- AddressSpace **target_as)
+ AddressSpace **target_as,
+ MemTxAttrs attrs)
{
IOMMUTLBEntry iotlb;
MemoryRegionSection *section;
@@ -557,7 +559,8 @@ IOMMUTLBEntry address_space_get_iotlb_entry(AddressSpace
*as, hwaddr addr,
* but page mask.
*/
section = flatview_do_translate(address_space_to_flatview(as), addr, &xlat,
-NULL, &page_mask, is_write, false, &as);
+NULL, &page_mask, is_write, false, &as,
+attrs);
/* Illegal translation */
if (section.mr == &io_mem_unassigned) {
@@ -592,7 +595,7 @@ MemoryRegion *flatview_translate(FlatView *fv, hwaddr addr,
hwaddr *xlat,
/* This can be MMIO, so setup MMIO bit. */
section = flatview_do_translate(fv, addr, xlat, plen, NULL,
-is_write, true, &as);
+is_write, true, &as, attrs);
mr = section.mr;
if (xen_enabled() && memory_access_is_direct(mr, is_write)) {
--
2.17.0
[Qemu-devel] [RFC PATCH 02/11] Make address_space_map() take a MemTxAttrs argument
As part of plumbing MemTxAttrs down to the IOMMU translate method,
add MemTxAttrs as an argument to address_space_map().
Its callers either have an attrs value to hand, or don't care
and can use MEMTXATTRS_UNSPECIFIED.
Signed-off-by: Peter Maydell
---
include/exec/memory.h | 3 ++-
include/sysemu/dma.h| 3 ++-
exec.c | 6 --
target/ppc/mmu-hash64.c | 3 ++-
4 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/include/exec/memory.h b/include/exec/memory.h
index f416d1e985..1af4e3cd5b 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -1953,9 +1953,10 @@ bool address_space_access_valid(AddressSpace *as, hwaddr
addr, int len, bool is_
* @addr: address within that address space
* @plen: pointer to length of buffer; updated on return
* @is_write: indicates the transfer direction
+ * @attrs: memory attributes
*/
void *address_space_map(AddressSpace *as, hwaddr addr,
-hwaddr *plen, bool is_write);
+hwaddr *plen, bool is_write, MemTxAttrs attrs);
/* address_space_unmap: Unmaps a memory region previously mapped by
address_space_map()
*
diff --git a/include/sysemu/dma.h b/include/sysemu/dma.h
index c228c66513..0d73902634 100644
--- a/include/sysemu/dma.h
+++ b/include/sysemu/dma.h
@@ -132,7 +132,8 @@ static inline void *dma_memory_map(AddressSpace *as,
hwaddr xlen = *len;
void *p;
-p = address_space_map(as, addr, &xlen, dir == DMA_DIRECTION_FROM_DEVICE);
+p = address_space_map(as, addr, &xlen, dir == DMA_DIRECTION_FROM_DEVICE,
+ MEMTXATTRS_UNSPECIFIED);
*len = xlen;
return p;
}
diff --git a/exec.c b/exec.c
index a0f27b7b8c..eb6471abfe 100644
--- a/exec.c
+++ b/exec.c
@@ -3494,7 +3494,8 @@ flatview_extend_translation(FlatView *fv, hwaddr addr,
void *address_space_map(AddressSpace *as,
hwaddr addr,
hwaddr *plen,
-bool is_write)
+bool is_write,
+MemTxAttrs attrs)
{
hwaddr len = *plen;
hwaddr l, xlat;
@@ -3581,7 +3582,8 @@ void *cpu_physical_memory_map(hwaddr addr,
hwaddr *plen,
int is_write)
{
-return address_space_map(&address_space_memory, addr, plen, is_write);
+return address_space_map(&address_space_memory, addr, plen, is_write,
+ MEMTXATTRS_UNSPECIFIED);
}
void cpu_physical_memory_unmap(void *buffer, hwaddr len,
diff --git a/target/ppc/mmu-hash64.c b/target/ppc/mmu-hash64.c
index 7e0adecfd9..4839dc22f0 100644
--- a/target/ppc/mmu-hash64.c
+++ b/target/ppc/mmu-hash64.c
@@ -431,7 +431,8 @@ const ppc_hash_pte64_t *ppc_hash64_map_hptes(PowerPCCPU
*cpu,
return NULL;
}
-hptes = address_space_map(CPU(cpu)->as, base + pte_offset, &plen, false);
+hptes = address_space_map(CPU(cpu)->as, base + pte_offset, &plen, false,
+ MEMTXATTRS_UNSPECIFIED);
if (plen < (n * HASH_PTE_SIZE_64)) {
hw_error("%s: Unable to map all requested HPTEs\n", __func__);
}
--
2.17.0
[Qemu-devel] [RFC PATCH 09/11] Make address_space_get_iotlb_entry() take a MemTxAttrs argument
As part of plumbing MemTxAttrs down to the IOMMU translate method,
add MemTxAttrs as an argument to address_space_get_iotlb_entry().
Signed-off-by: Peter Maydell
---
include/exec/memory.h | 2 +-
exec.c| 2 +-
hw/virtio/vhost.c | 3 ++-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/exec/memory.h b/include/exec/memory.h
index bd50424804..16a82d9722 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -1897,7 +1897,7 @@ void stq_be_phys_cached(MemoryRegionCache *cache, hwaddr
addr, uint64_t val);
* entry. Should be called from an RCU critical section.
*/
IOMMUTLBEntry address_space_get_iotlb_entry(AddressSpace *as, hwaddr addr,
-bool is_write);
+bool is_write, MemTxAttrs attrs);
/* address_space_translate: translate an address range into an address space
* into a MemoryRegion and an address range into that section. Should be
diff --git a/exec.c b/exec.c
index 41f7a7f5c4..c29bf47ce2 100644
--- a/exec.c
+++ b/exec.c
@@ -547,7 +547,7 @@ translate_fail:
/* Called from RCU critical section */
IOMMUTLBEntry address_space_get_iotlb_entry(AddressSpace *as, hwaddr addr,
-bool is_write)
+bool is_write, MemTxAttrs attrs)
{
MemoryRegionSection section;
hwaddr xlat, page_mask;
diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index 9d5850a7d7..48f4fd7cc9 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -895,7 +895,8 @@ int vhost_device_iotlb_miss(struct vhost_dev *dev, uint64_t
iova, int write)
rcu_read_lock();
iotlb = address_space_get_iotlb_entry(dev->vdev->dma_as,
- iova, write);
+ iova, write,
+ MEMTXATTRS_UNSPECIFIED);
if (iotlb.target_as != NULL) {
ret = vhost_memory_region_lookup(dev, iotlb.translated_addr,
&uaddr, &len);
--
2.17.0
[Qemu-devel] [RFC PATCH 04/11] Make flatview_extend_translation() take a MemTxAttrs argument
As part of plumbing MemTxAttrs down to the IOMMU translate method,
add MemTxAttrs as an argument to flatview_extend_translation().
Its callers either have an attrs value to hand, or don't care
and can use MEMTXATTRS_UNSPECIFIED.
Signed-off-by: Peter Maydell
---
exec.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/exec.c b/exec.c
index 87650dc7ed..e56c3442c7 100644
--- a/exec.c
+++ b/exec.c
@@ -3460,9 +3460,9 @@ bool address_space_access_valid(AddressSpace *as, hwaddr
addr,
static hwaddr
flatview_extend_translation(FlatView *fv, hwaddr addr,
- hwaddr target_len,
- MemoryRegion *mr, hwaddr base, hwaddr len,
- bool is_write)
+hwaddr target_len,
+MemoryRegion *mr, hwaddr base, hwaddr len,
+bool is_write, MemTxAttrs attrs)
{
hwaddr done = 0;
hwaddr xlat;
@@ -3539,7 +3539,7 @@ void *address_space_map(AddressSpace *as,
memory_region_ref(mr);
*plen = flatview_extend_translation(fv, addr, len, mr, xlat,
- l, is_write);
+l, is_write, attrs);
ptr = qemu_ram_ptr_length(mr->ram_block, xlat, plen, true);
rcu_read_unlock();
--
2.17.0
[Qemu-devel] [RFC PATCH 03/11] Make address_space_access_valid() take a MemTxAttrs argument
As part of plumbing MemTxAttrs down to the IOMMU translate method,
add MemTxAttrs as an argument to address_space_access_valid().
Its callers either have an attrs value to hand, or don't care
and can use MEMTXATTRS_UNSPECIFIED.
Signed-off-by: Peter Maydell
---
include/exec/memory.h | 4 +++-
include/sysemu/dma.h | 3 ++-
exec.c | 3 ++-
target/s390x/diag.c| 6 --
target/s390x/excp_helper.c | 3 ++-
target/s390x/mmu_helper.c | 3 ++-
target/s390x/sigp.c| 3 ++-
7 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/include/exec/memory.h b/include/exec/memory.h
index 1af4e3cd5b..eb1ceace27 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -1938,8 +1938,10 @@ static inline MemoryRegion
*address_space_translate(AddressSpace *as,
* @addr: address within that address space
* @len: length of the area to be checked
* @is_write: indicates the transfer direction
+ * @attrs: memory attributes
*/
-bool address_space_access_valid(AddressSpace *as, hwaddr addr, int len, bool
is_write);
+bool address_space_access_valid(AddressSpace *as, hwaddr addr, int len,
+bool is_write, MemTxAttrs attrs);
/* address_space_map: map a physical memory region into a host virtual address
*
diff --git a/include/sysemu/dma.h b/include/sysemu/dma.h
index 0d73902634..5da3c4e3c5 100644
--- a/include/sysemu/dma.h
+++ b/include/sysemu/dma.h
@@ -77,7 +77,8 @@ static inline bool dma_memory_valid(AddressSpace *as,
DMADirection dir)
{
return address_space_access_valid(as, addr, len,
- dir == DMA_DIRECTION_FROM_DEVICE);
+ dir == DMA_DIRECTION_FROM_DEVICE,
+ MEMTXATTRS_UNSPECIFIED);
}
static inline int dma_memory_rw_relaxed(AddressSpace *as, dma_addr_t addr,
diff --git a/exec.c b/exec.c
index eb6471abfe..87650dc7ed 100644
--- a/exec.c
+++ b/exec.c
@@ -3445,7 +3445,8 @@ static bool flatview_access_valid(FlatView *fv, hwaddr
addr, int len,
}
bool address_space_access_valid(AddressSpace *as, hwaddr addr,
-int len, bool is_write)
+int len, bool is_write,
+MemTxAttrs attrs)
{
FlatView *fv;
bool result;
diff --git a/target/s390x/diag.c b/target/s390x/diag.c
index a755837ad5..6ab473e7b6 100644
--- a/target/s390x/diag.c
+++ b/target/s390x/diag.c
@@ -140,7 +140,8 @@ void handle_diag_308(CPUS390XState *env, uint64_t r1,
uint64_t r3, uintptr_t ra)
return;
}
if (!address_space_access_valid(&address_space_memory, addr,
-sizeof(IplParameterBlock), false)) {
+sizeof(IplParameterBlock), false,
+MEMTXATTRS_UNSPECIFIED)) {
s390_program_interrupt(env, PGM_ADDRESSING, ILEN_AUTO, ra);
return;
}
@@ -169,7 +170,8 @@ out:
return;
}
if (!address_space_access_valid(&address_space_memory, addr,
-sizeof(IplParameterBlock), true)) {
+sizeof(IplParameterBlock), true,
+MEMTXATTRS_UNSPECIFIED)) {
s390_program_interrupt(env, PGM_ADDRESSING, ILEN_AUTO, ra);
return;
}
diff --git a/target/s390x/excp_helper.c b/target/s390x/excp_helper.c
index dfee22..f0ce60cff2 100644
--- a/target/s390x/excp_helper.c
+++ b/target/s390x/excp_helper.c
@@ -120,7 +120,8 @@ int s390_cpu_handle_mmu_fault(CPUState *cs, vaddr
orig_vaddr, int size,
/* check out of RAM access */
if (!address_space_access_valid(&address_space_memory, raddr,
-TARGET_PAGE_SIZE, rw)) {
+TARGET_PAGE_SIZE, rw,
+MEMTXATTRS_UNSPECIFIED)) {
DPRINTF("%s: raddr %" PRIx64 " > ram_size %" PRIx64 "\n", __func__,
(uint64_t)raddr, (uint64_t)ram_size);
trigger_pgm_exception(env, PGM_ADDRESSING, ILEN_AUTO);
diff --git a/target/s390x/mmu_helper.c b/target/s390x/mmu_helper.c
index a25deef5dd..145b62a7ef 100644
--- a/target/s390x/mmu_helper.c
+++ b/target/s390x/mmu_helper.c
@@ -461,7 +461,8 @@ static int translate_pages(S390CPU *cpu, vaddr addr, int
nr_pages,
return ret;
}
if (!address_space_access_valid(&address_space_memory, pages[i],
-TARGET_PAGE_SIZE, is_write)) {
+TARGET_PAGE_SIZE, is_write,
+MEMTXATTRS_UNSPECIFIED)) {
trigger_access_exception(env, PGM_ADDRESSING, ILEN_AUTO, 0);
return -EFAULT;
}
diff --git a/target/s390x/sigp.c b/target/s390x/sigp.c
[Qemu-devel] [RFC PATCH 00/11] iommu: add MemTxAttrs argument to IOMMU translate function
This is an RFC patchset because it's a little bit unmotivated
and only lightly tested, but in principle it could be
committed, so half-RFC-half-not :-)
The Arm SMMU wants to know if the transaction it is handling
is secure/nonsecure and user/privileged, because the iommu
page tables can be configured by the guest to only allow
transactions which satisfy those criteria. At the moment
Eric's implementation ignores all that, because we don't
provide the IOMMUMemoryRegion translate function with any
memory transaction attribute information. This patchset fixes
that by plumbing through transaction attributes.
Most of the patchset is just starting at the leaves of the calltree
rooted at "flatview_do_translate()" and making callsites provide
attributes where appropriate or plumbing through existing attribute
information where it exists. General principles of when I made a
caller pass MEMTXATTRS_UNSPECIFIED and when I had it take an
attrs value from further up:
* dma_memory_* functions all assume UNSPECIFIED (matching
the read/write/rw functions that already do that)
* cpu_physical_memory_* also all assume UNSPECIFIED,
following the pattern of existing functions in that family
* address_space_* take an attributes argument, by analogy
with existing functions in that family
* endpoints like target-specific code or vhost has to
provide attributes, but for all the targets affected here
they don't care about attributes and can use UNSPECIFIED
As well as the SMMU, I'm also thinking about using the IOMMU
infrastructure for the v8M Memory Protection Controller
(though that is a bit trickier as I also need it to support
TCG execution in an IOMMU-controlled region, which is an
orthogonal bit of work to attribute support).
Based-on: <20180430122404.10741-1-peter.mayd...@linaro.org>
("memory.h: Improve IOMMU related documentation") but
only for textual reasons.
thanks
-- PMM
Peter Maydell (11):
Make address_space_translate() take a MemTxAttrs argument
Make address_space_map() take a MemTxAttrs argument
Make address_space_access_valid() take a MemTxAttrs argument
Make flatview_extend_translation() take a MemTxAttrs argument
Make memory_region_access_valid() take a MemTxAttrs argument
Make MemoryRegion valid.accepts callback take a MemTxAttrs argument
Make flatview_access_valid() take a MemTxAttrs argument
Make flatview_translate() take a MemTxAttrs argument
Make address_space_get_iotlb_entry() take a MemTxAttrs argument
Make flatview_do_translate() take a MemTxAttrs argument
Add MemTxAttrs argument to IOMMU translate function
include/exec/memory-internal.h | 3 +-
include/exec/memory.h | 26 +++-
include/sysemu/dma.h | 6 ++-
accel/tcg/translate-all.c | 2 +-
exec.c | 73 --
hw/alpha/typhoon.c | 3 +-
hw/dma/rc4030.c| 3 +-
hw/hppa/dino.c | 3 +-
hw/i386/amd_iommu.c| 3 +-
hw/i386/intel_iommu.c | 3 +-
hw/nvram/fw_cfg.c | 12 --
hw/ppc/spapr_iommu.c | 3 +-
hw/s390x/s390-pci-bus.c| 3 +-
hw/s390x/s390-pci-inst.c | 3 +-
hw/scsi/esp.c | 3 +-
hw/sparc/sun4m_iommu.c | 3 +-
hw/sparc64/sun4u_iommu.c | 3 +-
hw/vfio/common.c | 3 +-
hw/virtio/vhost.c | 3 +-
hw/xen/xen_pt_msi.c| 3 +-
memory.c | 15 ---
memory_ldst.inc.c | 18 -
target/ppc/mmu-hash64.c| 3 +-
target/riscv/helper.c | 2 +-
target/s390x/diag.c| 6 ++-
target/s390x/excp_helper.c | 3 +-
target/s390x/mmu_helper.c | 3 +-
target/s390x/sigp.c| 3 +-
28 files changed, 134 insertions(+), 83 deletions(-)
--
2.17.0
[Qemu-devel] [RFC PATCH 05/11] Make memory_region_access_valid() take a MemTxAttrs argument
As part of plumbing MemTxAttrs down to the IOMMU translate method,
add MemTxAttrs as an argument to memory_region_access_valid().
Its callers either have an attrs value to hand, or don't care
and can use MEMTXATTRS_UNSPECIFIED.
The callsite in flatview_access_valid() is part of a recursive
loop flatview_access_valid() -> memory_region_access_valid() ->
subpage_accepts() -> flatview_access_valid(); we make it pass
MEMTXATTRS_UNSPECIFIED for now, until the next several commits
have plumbed an attrs parameter through the rest of the loop
and we can add an attrs parameter to flatview_access_valid().
Signed-off-by: Peter Maydell
---
include/exec/memory-internal.h | 3 ++-
exec.c | 4 +++-
hw/s390x/s390-pci-inst.c | 3 ++-
memory.c | 7 ---
4 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/include/exec/memory-internal.h b/include/exec/memory-internal.h
index 6a5ee42d36..063dca0475 100644
--- a/include/exec/memory-internal.h
+++ b/include/exec/memory-internal.h
@@ -34,7 +34,8 @@ static inline AddressSpaceDispatch
*address_space_to_dispatch(AddressSpace *as)
extern const MemoryRegionOps unassigned_mem_ops;
bool memory_region_access_valid(MemoryRegion *mr, hwaddr addr,
-unsigned size, bool is_write);
+unsigned size, bool is_write,
+MemTxAttrs attrs);
void flatview_add_to_dispatch(FlatView *fv, MemoryRegionSection *section);
AddressSpaceDispatch *address_space_dispatch_new(FlatView *fv);
diff --git a/exec.c b/exec.c
index e56c3442c7..57a984758e 100644
--- a/exec.c
+++ b/exec.c
@@ -3433,7 +3433,9 @@ static bool flatview_access_valid(FlatView *fv, hwaddr
addr, int len,
mr = flatview_translate(fv, addr, &xlat, &l, is_write);
if (!memory_access_is_direct(mr, is_write)) {
l = memory_access_size(mr, l, addr);
-if (!memory_region_access_valid(mr, xlat, l, is_write)) {
+/* When our callers all have attrs we'll pass them through here */
+if (!memory_region_access_valid(mr, xlat, l, is_write,
+MEMTXATTRS_UNSPECIFIED)) {
return false;
}
}
diff --git a/hw/s390x/s390-pci-inst.c b/hw/s390x/s390-pci-inst.c
index 3fcc330fe3..2e7b4068c0 100644
--- a/hw/s390x/s390-pci-inst.c
+++ b/hw/s390x/s390-pci-inst.c
@@ -770,7 +770,8 @@ int pcistb_service_call(S390CPU *cpu, uint8_t r1, uint8_t
r3, uint64_t gaddr,
mr = s390_get_subregion(mr, offset, len);
offset -= mr->addr;
-if (!memory_region_access_valid(mr, offset, len, true)) {
+if (!memory_region_access_valid(mr, offset, len, true,
+MEMTXATTRS_UNSPECIFIED)) {
s390_program_interrupt(env, PGM_OPERAND, 6, ra);
return 0;
}
diff --git a/memory.c b/memory.c
index e70b64b8b9..0f8f37a57b 100644
--- a/memory.c
+++ b/memory.c
@@ -1347,7 +1347,8 @@ static const MemoryRegionOps ram_device_mem_ops = {
bool memory_region_access_valid(MemoryRegion *mr,
hwaddr addr,
unsigned size,
-bool is_write)
+bool is_write,
+MemTxAttrs attrs)
{
int access_size_min, access_size_max;
int access_size, i;
@@ -1416,7 +1417,7 @@ MemTxResult memory_region_dispatch_read(MemoryRegion *mr,
{
MemTxResult r;
-if (!memory_region_access_valid(mr, addr, size, false)) {
+if (!memory_region_access_valid(mr, addr, size, false, attrs)) {
*pval = unassigned_mem_read(mr, addr, size);
return MEMTX_DECODE_ERROR;
}
@@ -1458,7 +1459,7 @@ MemTxResult memory_region_dispatch_write(MemoryRegion *mr,
unsigned size,
MemTxAttrs attrs)
{
-if (!memory_region_access_valid(mr, addr, size, true)) {
+if (!memory_region_access_valid(mr, addr, size, true, attrs)) {
unassigned_mem_write(mr, addr, data, size);
return MEMTX_DECODE_ERROR;
}
--
2.17.0
[Qemu-devel] [RFC PATCH 08/11] Make flatview_translate() take a MemTxAttrs argument
As part of plumbing MemTxAttrs down to the IOMMU translate method,
add MemTxAttrs as an argument to flatview_translate(); all its
callers now have attrs available.
Signed-off-by: Peter Maydell
---
include/exec/memory.h | 7 ---
exec.c| 17 +
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/include/exec/memory.h b/include/exec/memory.h
index 7c461b9718..bd50424804 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -1914,7 +1914,8 @@ IOMMUTLBEntry address_space_get_iotlb_entry(AddressSpace
*as, hwaddr addr,
*/
MemoryRegion *flatview_translate(FlatView *fv,
hwaddr addr, hwaddr *xlat,
- hwaddr *len, bool is_write);
+ hwaddr *len, bool is_write,
+ MemTxAttrs attrs);
static inline MemoryRegion *address_space_translate(AddressSpace *as,
hwaddr addr, hwaddr *xlat,
@@ -1922,7 +1923,7 @@ static inline MemoryRegion
*address_space_translate(AddressSpace *as,
MemTxAttrs attrs)
{
return flatview_translate(address_space_to_flatview(as),
- addr, xlat, len, is_write);
+ addr, xlat, len, is_write, attrs);
}
/* address_space_access_valid: check for validity of accessing an address
@@ -2024,7 +2025,7 @@ MemTxResult address_space_read(AddressSpace *as, hwaddr
addr,
rcu_read_lock();
fv = address_space_to_flatview(as);
l = len;
-mr = flatview_translate(fv, addr, &addr1, &l, false);
+mr = flatview_translate(fv, addr, &addr1, &l, false, attrs);
if (len == l && memory_access_is_direct(mr, false)) {
ptr = qemu_map_ram_ptr(mr->ram_block, addr1);
memcpy(buf, ptr, len);
diff --git a/exec.c b/exec.c
index 0eef4702a5..41f7a7f5c4 100644
--- a/exec.c
+++ b/exec.c
@@ -583,7 +583,8 @@ iotlb_fail:
/* Called from RCU critical section */
MemoryRegion *flatview_translate(FlatView *fv, hwaddr addr, hwaddr *xlat,
- hwaddr *plen, bool is_write)
+ hwaddr *plen, bool is_write,
+ MemTxAttrs attrs)
{
MemoryRegion *mr;
MemoryRegionSection section;
@@ -3117,7 +3118,7 @@ static MemTxResult flatview_write_continue(FlatView *fv,
hwaddr addr,
}
l = len;
-mr = flatview_translate(fv, addr, &addr1, &l, true);
+mr = flatview_translate(fv, addr, &addr1, &l, true, attrs);
}
return result;
@@ -3133,7 +3134,7 @@ static MemTxResult flatview_write(FlatView *fv, hwaddr
addr, MemTxAttrs attrs,
MemTxResult result = MEMTX_OK;
l = len;
-mr = flatview_translate(fv, addr, &addr1, &l, true);
+mr = flatview_translate(fv, addr, &addr1, &l, true, attrs);
result = flatview_write_continue(fv, addr, attrs, buf, len,
addr1, l, mr);
@@ -3204,7 +3205,7 @@ MemTxResult flatview_read_continue(FlatView *fv, hwaddr
addr,
}
l = len;
-mr = flatview_translate(fv, addr, &addr1, &l, false);
+mr = flatview_translate(fv, addr, &addr1, &l, false, attrs);
}
return result;
@@ -3219,7 +3220,7 @@ static MemTxResult flatview_read(FlatView *fv, hwaddr
addr,
MemoryRegion *mr;
l = len;
-mr = flatview_translate(fv, addr, &addr1, &l, false);
+mr = flatview_translate(fv, addr, &addr1, &l, false, attrs);
return flatview_read_continue(fv, addr, attrs, buf, len,
addr1, l, mr);
}
@@ -3433,7 +3434,7 @@ static bool flatview_access_valid(FlatView *fv, hwaddr
addr, int len,
while (len > 0) {
l = len;
-mr = flatview_translate(fv, addr, &xlat, &l, is_write);
+mr = flatview_translate(fv, addr, &xlat, &l, is_write, attrs);
if (!memory_access_is_direct(mr, is_write)) {
l = memory_access_size(mr, l, addr);
/* When our callers all have attrs we'll pass them through here */
@@ -3482,7 +3483,7 @@ flatview_extend_translation(FlatView *fv, hwaddr addr,
len = target_len;
this_mr = flatview_translate(fv, addr, &xlat,
- &len, is_write);
+ &len, is_write, attrs);
if (this_mr != mr || xlat != base + done) {
return done;
}
@@ -3515,7 +3516,7 @@ void *address_space_map(AddressSpace *as,
l = len;
rcu_read_lock();
fv = address_space_to_flatview(as);
-mr = flatview_translate(fv, addr, &xlat, &l, is_write);
+mr = flatview_translate(fv, addr, &xlat, &l, is_write, attrs);
if (!memory_access_is_direct(mr, is_write)) {
if (atomic_xchg(&bounce.in_use, true)) {
--
2.17.0
Re: [Qemu-devel] How to check if Vt-d is capable of posted-interrupt?
On Mon, Apr 30, 2018 at 2:09 PM, Alex Williamson wrote: > On Mon, 30 Apr 2018 13:44:23 -0400 > Jintack Lim wrote: > >> Add iommu mailing list since this question might be more related to iommu. >> >> On Mon, Apr 30, 2018 at 10:11 AM, Jintack Lim >> wrote: >> > Hi, >> > >> > I wonder how to check if Vt-d is capable of posted-interrupt? I'm >> > using Intel E5-2630 v3. >> > >> > I was once told that APICv and posted-interrupt capability always come >> > together. But it seems like my cpu support APICv >> > (/sys/module/kvm_intel/parameters/enable_apicv is Y), but >> > posted-interrupt capability is only shipped with the next generation >> > of the cpu (E5-2600 v4, which is Broadwell). >> > >> > What would be an easy way to check this? > > PI support is bit 59 in the capability register which is exposed > through sysfs at /sys/class/iommu/dmar*/intel-iommu/cap so you could do > something like: > > # for i in $(find /sys/class/iommu/dmar* -type l); do echo -n "$i: "; echo > $(( ( 0x$(cat $i/intel-iommu/cap) >> 59 ) & 1 )); done > Thanks for a nice solution, Alex. It turns out my cpu doesn't have the PI capability. /sys/class/iommu/dmar0: 0 /sys/class/iommu/dmar1: 0 > I think the relationship between APICv and PI goes the other direction, > if you have PI, you probably have APICv. Having APICv implies nothing > about having PI. Thanks, Yeah, I think that makes sense. Thanks, Jintack > > Alex >
Re: [Qemu-devel] How to check if Vt-d is capable of posted-interrupt?
On Mon, 30 Apr 2018 13:44:23 -0400 Jintack Lim wrote: > Add iommu mailing list since this question might be more related to iommu. > > On Mon, Apr 30, 2018 at 10:11 AM, Jintack Lim wrote: > > Hi, > > > > I wonder how to check if Vt-d is capable of posted-interrupt? I'm > > using Intel E5-2630 v3. > > > > I was once told that APICv and posted-interrupt capability always come > > together. But it seems like my cpu support APICv > > (/sys/module/kvm_intel/parameters/enable_apicv is Y), but > > posted-interrupt capability is only shipped with the next generation > > of the cpu (E5-2600 v4, which is Broadwell). > > > > What would be an easy way to check this? PI support is bit 59 in the capability register which is exposed through sysfs at /sys/class/iommu/dmar*/intel-iommu/cap so you could do something like: # for i in $(find /sys/class/iommu/dmar* -type l); do echo -n "$i: "; echo $(( ( 0x$(cat $i/intel-iommu/cap) >> 59 ) & 1 )); done I think the relationship between APICv and PI goes the other direction, if you have PI, you probably have APICv. Having APICv implies nothing about having PI. Thanks, Alex
[Qemu-devel] [PATCH v4 3/3] net: Get rid of 'vlan' terminology and use 'hub' instead in the doc files
'vlan' is very confusing since it does not mean something like IEEE
802.1Q, but rather emulated hubs, so let's switch to that terminology
instead. While we're at it, move the subsection about hub a little bit
downward in the documentation (it's not as important anymore as it was
before the invention of the -netdev parameter), and extend it a little
bit.
Buglink: https://bugs.launchpad.net/qemu/+bug/658904
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Thomas Huth
---
qemu-doc.texi | 42 +++---
1 file changed, 23 insertions(+), 19 deletions(-)
diff --git a/qemu-doc.texi b/qemu-doc.texi
index b901cc2..22418f5 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -714,20 +714,12 @@ state is not saved or restored properly (in particular
USB).
@node pcsys_network
@section Network emulation
-QEMU can simulate several network cards (PCI or ISA cards on the PC
-target) and can connect them to an arbitrary number of Virtual Local
-Area Networks (VLANs). Host TAP devices can be connected to any QEMU
-VLAN. VLAN can be connected between separate instances of QEMU to
-simulate large networks. For simpler usage, a non privileged user mode
-network stack can replace the TAP device to have a basic network
-connection.
-
-@subsection VLANs
-
-QEMU simulates several VLANs. A VLAN can be symbolised as a virtual
-connection between several network devices. These devices can be for
-example QEMU virtual Ethernet cards or virtual Host ethernet devices
-(TAP devices).
+QEMU can simulate several network cards (e.g. PCI or ISA cards on the PC
+target) and can connect them to a network backend on the host or an emulated
+hub. The various host network backends can either be used to connect the NIC of
+the guest to a real network (e.g. by using a TAP devices or the non-privileged
+user mode network stack), or to other guest instances running in another QEMU
+process (e.g. by using the socket host network backend).
@subsection Using TAP network interfaces
@@ -763,7 +755,7 @@ network). The virtual network configuration is the
following:
@example
- QEMU VLAN <--> Firewall/DHCP server <-> Internet
+ guest (10.0.2.15) <--> Firewall/DHCP server <-> Internet
| (10.0.2.2)
|
> DNS server (10.0.2.3)
@@ -798,11 +790,23 @@ When using the @option{'-netdev user,hostfwd=...'}
option, TCP or UDP
connections can be redirected from the host to the guest. It allows for
example to redirect X11, telnet or SSH connections.
-@subsection Connecting VLANs between QEMU instances
+@subsection Hubs
+
+QEMU can simulate several hubs. A hub can be thought of as a virtual connection
+between several network devices. These devices can be for example QEMU virtual
+ethernet cards or virtual Host ethernet devices (TAP devices). You can connect
+guest NICs or host network backends to such a hub using the @option{-netdev
+hubport} or @option{-nic hubport} options. The legacy @option{-net} option
+also connects the given device to the emulated hub with ID 0 (i.e. the default
+hub) unless you specify a netdev with @option{-net nic,netdev=xxx} here.
+
+@subsection Connecting emulated networks between QEMU instances
-Using the @option{-net socket} option, it is possible to make VLANs
-that span several QEMU instances. See @ref{sec_invocation} to have a
-basic example.
+Using the @option{-netdev socket} (or @option{-nic socket} or
+@option{-net socket}) option, it is possible to create emulated
+networks that span several QEMU instances.
+See the description of the @option{-netdev socket} option in the
+@ref{sec_invocation,,Invocation chapter} to have a basic example.
@node pcsys_other_devs
@section Other Devices
--
1.8.3.1
[Qemu-devel] [PATCH v4 1/3] net: Remove the deprecated "vlan" parameter
It's been marked as deprecated since QEMU v2.9.0, so that should have
been enough time for everybody to either just drop unnecessary "vlan=0"
parameters, to switch to the modern -device + -netdev syntax for connecting
guest NICs with host network backends, or to switch to the "hubport" netdev
in case hubs are really wanted instead.
Buglink: https://bugs.launchpad.net/qemu/+bug/658904
Signed-off-by: Thomas Huth
---
docs/qdev-device-use.txt | 3 --
hw/core/qdev-properties-system.c | 80
include/hw/qdev-properties.h | 3 --
include/net/net.h| 1 -
net/net.c| 12 ++
qapi/net.json| 15
qemu-doc.texi| 9 -
qemu-options.hx | 29 ++-
8 files changed, 22 insertions(+), 130 deletions(-)
diff --git a/docs/qdev-device-use.txt b/docs/qdev-device-use.txt
index 8f188d1..98229b3 100644
--- a/docs/qdev-device-use.txt
+++ b/docs/qdev-device-use.txt
@@ -277,9 +277,6 @@ devices and ne2k_isa are.
Some PCI devices aren't available with -net nic, e.g. i82558a.
-To connect to a VLAN instead of an ordinary host part, replace
-netdev=NET-ID by vlan=VLAN.
-
=== Graphics Devices ===
Host and guest part of graphics devices have always been separate.
diff --git a/hw/core/qdev-properties-system.c b/hw/core/qdev-properties-system.c
index 1d3ba72..8b22fb5 100644
--- a/hw/core/qdev-properties-system.c
+++ b/hw/core/qdev-properties-system.c
@@ -321,86 +321,6 @@ const PropertyInfo qdev_prop_netdev = {
.set = set_netdev,
};
-/* --- vlan --- */
-
-static int print_vlan(DeviceState *dev, Property *prop, char *dest, size_t len)
-{
-NetClientState **ptr = qdev_get_prop_ptr(dev, prop);
-
-if (*ptr) {
-int id;
-if (!net_hub_id_for_client(*ptr, &id)) {
-return snprintf(dest, len, "%d", id);
-}
-}
-
-return snprintf(dest, len, "");
-}
-
-static void get_vlan(Object *obj, Visitor *v, const char *name, void *opaque,
- Error **errp)
-{
-DeviceState *dev = DEVICE(obj);
-Property *prop = opaque;
-NetClientState **ptr = qdev_get_prop_ptr(dev, prop);
-int32_t id = -1;
-
-if (*ptr) {
-int hub_id;
-if (!net_hub_id_for_client(*ptr, &hub_id)) {
-id = hub_id;
-}
-}
-
-visit_type_int32(v, name, &id, errp);
-}
-
-static void set_vlan(Object *obj, Visitor *v, const char *name, void *opaque,
- Error **errp)
-{
-DeviceState *dev = DEVICE(obj);
-Property *prop = opaque;
-NICPeers *peers_ptr = qdev_get_prop_ptr(dev, prop);
-NetClientState **ptr = &peers_ptr->ncs[0];
-Error *local_err = NULL;
-int32_t id;
-NetClientState *hubport;
-
-if (dev->realized) {
-qdev_prop_set_after_realize(dev, name, errp);
-return;
-}
-
-visit_type_int32(v, name, &id, &local_err);
-if (local_err) {
-error_propagate(errp, local_err);
-return;
-}
-if (id == -1) {
-*ptr = NULL;
-return;
-}
-if (*ptr) {
-error_set_from_qdev_prop_error(errp, -EINVAL, dev, prop, name);
-return;
-}
-
-hubport = net_hub_port_find(id);
-if (!hubport) {
-error_setg(errp, QERR_INVALID_PARAMETER_VALUE,
- name, prop->info->name);
-return;
-}
-*ptr = hubport;
-}
-
-const PropertyInfo qdev_prop_vlan = {
-.name = "int32",
-.description = "Integer VLAN id to connect to",
-.print = print_vlan,
-.get = get_vlan,
-.set = set_vlan,
-};
void qdev_prop_set_drive(DeviceState *dev, const char *name,
BlockBackend *value, Error **errp)
diff --git a/include/hw/qdev-properties.h b/include/hw/qdev-properties.h
index b2ad8e9..4f60cc8 100644
--- a/include/hw/qdev-properties.h
+++ b/include/hw/qdev-properties.h
@@ -29,7 +29,6 @@ extern const PropertyInfo qdev_prop_bios_chs_trans;
extern const PropertyInfo qdev_prop_fdc_drive_type;
extern const PropertyInfo qdev_prop_drive;
extern const PropertyInfo qdev_prop_netdev;
-extern const PropertyInfo qdev_prop_vlan;
extern const PropertyInfo qdev_prop_pci_devfn;
extern const PropertyInfo qdev_prop_blocksize;
extern const PropertyInfo qdev_prop_pci_host_devaddr;
@@ -195,8 +194,6 @@ extern const PropertyInfo qdev_prop_off_auto_pcibar;
DEFINE_PROP(_n, _s, _f, qdev_prop_string, char*)
#define DEFINE_PROP_NETDEV(_n, _s, _f) \
DEFINE_PROP(_n, _s, _f, qdev_prop_netdev, NICPeers)
-#define DEFINE_PROP_VLAN(_n, _s, _f) \
-DEFINE_PROP(_n, _s, _f, qdev_prop_vlan, NICPeers)
#define DEFINE_PROP_DRIVE(_n, _s, _f) \
DEFINE_PROP(_n, _s, _f, qdev_prop_drive, BlockBackend *)
#define DEFINE_PROP_MACADDR(_n, _s, _f) \
diff --git a/include/net/net.h b/include/net/net.h
index 1f7341e..1425960 100644
--- a/include/net/net.h
+++ b/include/net/net.h
@@ -37,7 +37,6 @@ typedef struct N
[Qemu-devel] [PATCH v4 2/3] net: Get rid of 'vlan' terminology and use 'hub' instead in the source files
'vlan' is very confusing since it does not mean something like IEEE
802.1Q, but rather emulated hubs, so let's switch to that terminology
instead.
Buglink: https://bugs.launchpad.net/qemu/+bug/658904
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Thomas Huth
---
net/hub.c | 7 +++
net/slirp.c | 8
net/tap.c | 4 ++--
3 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/net/hub.c b/net/hub.c
index 5e84a9a..78b671e 100644
--- a/net/hub.c
+++ b/net/hub.c
@@ -23,8 +23,7 @@
/*
* A hub broadcasts incoming packets to all its ports except the source port.
- * Hubs can be used to provide independent network segments, also confusingly
- * named the QEMU 'vlan' feature.
+ * Hubs can be used to provide independent emulated network segments.
*/
typedef struct NetHub NetHub;
@@ -345,10 +344,10 @@ void net_hub_check_clients(void)
}
}
if (has_host_dev && !has_nic) {
-warn_report("vlan %d with no nics", hub->id);
+warn_report("hub %d with no nics", hub->id);
}
if (has_nic && !has_host_dev) {
-warn_report("vlan %d is not connected to host network", hub->id);
+warn_report("hub %d is not connected to host network", hub->id);
}
}
}
diff --git a/net/slirp.c b/net/slirp.c
index 8991816..6922524 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -415,7 +415,7 @@ static SlirpState *slirp_lookup(Monitor *mon, const char
*hub_id,
if (hub_id) {
nc = net_hub_find_client_by_name(strtol(hub_id, NULL, 0), name);
if (!nc) {
-monitor_printf(mon, "unrecognized (vlan-id, stackname)
pair\n");
+monitor_printf(mon, "unrecognized (hub-id, stackname) pair\n");
return NULL;
}
} else {
@@ -870,9 +870,9 @@ void hmp_info_usernet(Monitor *mon, const QDict *qdict)
QTAILQ_FOREACH(s, &slirp_stacks, entry) {
int id;
-bool got_vlan_id = net_hub_id_for_client(&s->nc, &id) == 0;
-monitor_printf(mon, "VLAN %d (%s):\n",
- got_vlan_id ? id : -1,
+bool got_hub_id = net_hub_id_for_client(&s->nc, &id) == 0;
+monitor_printf(mon, "Hub %d (%s):\n",
+ got_hub_id ? id : -1,
s->nc.name);
slirp_connection_info(s->slirp, mon);
}
diff --git a/net/tap.c b/net/tap.c
index 2b3a36f..de05f20 100644
--- a/net/tap.c
+++ b/net/tap.c
@@ -766,10 +766,10 @@ int net_init_tap(const Netdev *netdev, const char *name,
queues = tap->has_queues ? tap->queues : 1;
vhostfdname = tap->has_vhostfd ? tap->vhostfd : NULL;
-/* QEMU vlans does not support multiqueue tap, in this case peer is set.
+/* QEMU hubs do not support multiqueue tap, in this case peer is set.
* For -netdev, peer is always NULL. */
if (peer && (tap->has_queues || tap->has_fds || tap->has_vhostfds)) {
-error_setg(errp, "Multiqueue tap cannot be used with QEMU vlans");
+error_setg(errp, "Multiqueue tap cannot be used with hubs");
return -1;
}
--
1.8.3.1
[Qemu-devel] [PATCH v4 0/3] net: Get rid of 'vlan'
The 'vlan' term caused a lot of confusion and misconfigurations in the past. The parameter has been marked as deprecated since QEMU v2.9.0, so it's now time to finally remove the parameter and use the better word "hub" in the remaining spots that actually mean the QEMU emulated hub feature. v4: - Some rewordings in qemu-doc.texi and qemu-options.hx according to Stefan's and Paolo's suggestions v3: - Some rewordings in qemu-doc and net.json according to Paolo's suggestions v2: - Added first patch to actually remove the deprecated 'vlan' parameter (instead of only updating the wording in the sources and docs) Thomas Huth (3): net: Remove the deprecated "vlan" parameter net: Get rid of 'vlan' terminology and use 'hub' instead in the source files net: Get rid of 'vlan' terminology and use 'hub' instead in the doc files docs/qdev-device-use.txt | 3 -- hw/core/qdev-properties-system.c | 80 include/hw/qdev-properties.h | 3 -- include/net/net.h| 1 - net/hub.c| 7 ++-- net/net.c| 12 ++ net/slirp.c | 8 ++-- net/tap.c| 4 +- qapi/net.json| 15 qemu-doc.texi| 51 - qemu-options.hx | 29 ++- 11 files changed, 54 insertions(+), 159 deletions(-) -- 1.8.3.1
Re: [Qemu-devel] [PATCH for-2.12] tcg/mips: Handle large offsets from target env to tlb_table
On 30 April 2018 at 18:44, Alex Bennée wrote: > Peter Maydell writes: >> An ideal long term approach would be to rearrange the CPU state >> so that the tlb_table was not so far along it, but this is tricky >> because it would move it from the "not cleared on CPU reset" part >> of the struct to the "cleared on CPU reset" part. > > Is that really a problem? Doesn't it mean we'll just reload the TLB > after a reset? It was the sort of "this subtly changes the semantics on all hosts for the sake of an issue that's mips-hosts-only" change that I didn't want to try to reason through and make very close to release when we didn't have a lot of time to test the results... thanks -- PMM
Re: [Qemu-devel] [PULL 4/5] usb-mtp: Introduce write support for MTP objects
Peter Maydell writes:
> On 27 February 2018 at 08:39, Gerd Hoffmann wrote:
>> From: Bandan Das
>>
>> Allow write operations on behalf of the initiator. The
>> precursor to write is the sending of the write metadata
>> that consists of the ObjectInfo dataset. This patch introduces
>> a flag that is set when the responder is ready to receive
>> write data based on a previous SendObjectInfo operation by
>> the initiator (The SendObjectInfo implementation is in a
>> later patch)
>>
>> Signed-off-by: Bandan Das
>> Message-id: 20180223164829.29683-5-...@redhat.com
>> Signed-off-by: Gerd Hoffmann
>
> Hi. Coverity (CID 1390604) complains here about a possible
> use-after-NULL-check:
>
>> @@ -1567,8 +1706,13 @@ static void usb_mtp_handle_data(USBDevice *dev,
>> USBPacket *p)
>> p->status = USB_RET_STALL;
>> return;
>> }
>> -usb_packet_copy(p, &container, sizeof(container));
>> -switch (le16_to_cpu(container.type)) {
>> +if (s->data_out && !s->data_out->first) {
>> +container_type = TYPE_DATA;
>
> Here we check s->data_out, so we might set container_type
> to TYPE_DATA with s->data_out == NULL...
Just to be sure, is it enough to replace the if with:
if (s->data !=NULL && !s->data->first) ?
Bandan
>> +} else {
>> +usb_packet_copy(p, &container, sizeof(container));
>> +container_type = le16_to_cpu(container.type);
>> +}
>> +switch (container_type) {
>> case TYPE_COMMAND:
>> if (s->data_in || s->data_out || s->result) {
>> trace_usb_mtp_stall(s->dev.addr, "transaction inflight");
>> @@ -1599,6 +1743,15 @@ static void usb_mtp_handle_data(USBDevice *dev,
>> USBPacket *p)
>>(cmd.argc > 4) ? cmd.argv[4] : 0);
>> usb_mtp_command(s, &cmd);
>> break;
>> +case TYPE_DATA:
>> +/* One of the previous transfers has already errored but the
>> + * responder is still sending data associated with it
>> + */
>> +if (s->result != NULL) {
>> +return;
>> +}
>> +usb_mtp_get_data(s, &container, p);
>
> ...but here we call usb_mtp_get_data(), which will always
> dereference s->data_out, and so will crash if it is NULL.
>
>> +break;
>> default:
>> /* not needed as long as the mtp device is read-only */
>> p->status = USB_RET_STALL;
>> --
>> 2.9.3
>
> thanks
> -- PMM
Re: [Qemu-devel] How to check if Vt-d is capable of posted-interrupt?
Add iommu mailing list since this question might be more related to iommu. On Mon, Apr 30, 2018 at 10:11 AM, Jintack Lim wrote: > Hi, > > I wonder how to check if Vt-d is capable of posted-interrupt? I'm > using Intel E5-2630 v3. > > I was once told that APICv and posted-interrupt capability always come > together. But it seems like my cpu support APICv > (/sys/module/kvm_intel/parameters/enable_apicv is Y), but > posted-interrupt capability is only shipped with the next generation > of the cpu (E5-2600 v4, which is Broadwell). > > What would be an easy way to check this? > > Thanks, > Jintack
Re: [Qemu-devel] [PATCH for-2.12] tcg/mips: Handle large offsets from target env to tlb_table
Peter Maydell writes: > The MIPS TCG target makes the assumption that the offset from the > target env pointer to the tlb_table is less than about 64K. This > used to be true, but gradual addition of features to the Arm > target means that it's no longer true there. This results in > the build-time assertion failing: > > In file included from /home/pm215/qemu/include/qemu/osdep.h:36:0, > from /home/pm215/qemu/tcg/tcg.c:28: > /home/pm215/qemu/tcg/mips/tcg-target.inc.c: In function ‘tcg_out_tlb_load’: > /home/pm215/qemu/include/qemu/compiler.h:90:36: error: static assertion > failed: "not expecting: offsetof(CPUArchState, tlb_table[NB_MMU_MODES - > 1][1]) > 0x7ff0 + 0x7fff" > #define QEMU_BUILD_BUG_MSG(x, msg) _Static_assert(!(x), msg) > ^ > /home/pm215/qemu/include/qemu/compiler.h:98:30: note: in expansion of macro > ‘QEMU_BUILD_BUG_MSG’ > #define QEMU_BUILD_BUG_ON(x) QEMU_BUILD_BUG_MSG(x, "not expecting: " #x) > ^ > /home/pm215/qemu/tcg/mips/tcg-target.inc.c:1236:9: note: in expansion of > macro ‘QEMU_BUILD_BUG_ON’ > QEMU_BUILD_BUG_ON(offsetof(CPUArchState, > ^ > /home/pm215/qemu/rules.mak:66: recipe for target 'tcg/tcg.o' failed > > An ideal long term approach would be to rearrange the CPU state > so that the tlb_table was not so far along it, but this is tricky > because it would move it from the "not cleared on CPU reset" part > of the struct to the "cleared on CPU reset" part. Is that really a problem? Doesn't it mean we'll just reload the TLB after a reset? -- Alex Bennée
Re: [Qemu-devel] release retrospective, next release timing, numbering
On 30.04.2018 13:21, Cornelia Huck wrote: > On Mon, 30 Apr 2018 11:33:12 +0100 > Daniel P. Berrangé wrote: [...] >> Given, that we have a clear deprecation process now, my view is that >> we should formally declare that major version numbers changes are >> meaningless. As soon as you try to assign special meaning to major >> version changes, you open the door to endless debate about whether >> a particular set of changes is meaningful enough to justify the >> major version change, leading to eventually 2.42. > > I agree. I agree with this, too. We've seen that in some v3.0 discussions during the last year. >> Two possible options >> >> a) Bump major version once a year, so we'll have 3.0, 3.1, 3.3, >> 4.0, 4.1, 4.2, 5.0, ...etc We missed the first release this >> year, so we would only have 3.0 and 3.1 this year. >> >> b) Bump major release when minor version gets double-digits. >> eg 3.0, 3.1, , 3.9, 3.9, 4.0, , 4.9, 5.0... It's just a matter of taste, but I think I'd prefer variant b). That will bump the major release approx. every three years which sounds like a good time frame for me. > If we bump the major version each year anyway, why not go the whole way > and use 2018.1, 2018.2, ... (or even .)? The nice thing > about that is that you can see at a glance when the release took place. ... or simply drop the first two digits and call them 18.1, 18.2, ...? Thomas
Re: [Qemu-devel] [PATCH 1/2] m68k: Fix floatx80_lognp1 (Coverity CID1390587)
On 30 April 2018 at 18:01, Laurent Vivier wrote:
> return the result of packFloatx80() instead of
> dropping it.
>
> Signed-off-by: Laurent Vivier
> ---
> target/m68k/softfloat.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/target/m68k/softfloat.c b/target/m68k/softfloat.c
> index dffb371c71..2c069a5efb 100644
> --- a/target/m68k/softfloat.c
> +++ b/target/m68k/softfloat.c
> @@ -334,7 +334,8 @@ floatx80 floatx80_lognp1(floatx80 a, float_status *status)
> if (aSign && aExp >= one_exp) {
> if (aExp == one_exp && aSig == one_sig) {
> float_raise(float_flag_divbyzero, status);
> -packFloatx80(aSign, floatx80_infinity.high,
> floatx80_infinity.low);
> +return packFloatx80(aSign, floatx80_infinity.high,
> +floatx80_infinity.low);
> }
> float_raise(float_flag_invalid, status);
> return floatx80_default_nan(status);
Reviewed-by: Peter Maydell
thanks
-- PMM
Re: [Qemu-devel] [PATCH 2/2] m68k: remove dead code (Coverity CID1390617)
On 30 April 2018 at 18:01, Laurent Vivier wrote: > floatx80_sin() and floatx80_cos() are derived from one > sincos() function. They have both unused code coming from > their common origin. Remove it. > > Signed-off-by: Laurent Vivier > --- > target/m68k/softfloat.c | 43 ++- > 1 file changed, 14 insertions(+), 29 deletions(-) Reviewed-by: Peter Maydell thanks -- PMM
[Qemu-devel] [PATCH 2/2] m68k: remove dead code (Coverity CID1390617)
floatx80_sin() and floatx80_cos() are derived from one
sincos() function. They have both unused code coming from
their common origin. Remove it.
Signed-off-by: Laurent Vivier
---
target/m68k/softfloat.c | 43 ++-
1 file changed, 14 insertions(+), 29 deletions(-)
diff --git a/target/m68k/softfloat.c b/target/m68k/softfloat.c
index 2c069a5efb..e41b07d042 100644
--- a/target/m68k/softfloat.c
+++ b/target/m68k/softfloat.c
@@ -1497,7 +1497,7 @@ floatx80 floatx80_sin(floatx80 a, float_status *status)
int32_t compact, l, n, j;
floatx80 fp0, fp1, fp2, fp3, fp4, fp5, x, invtwopi, twopi1, twopi2;
float32 posneg1, twoto63;
-flag adjn, endflag;
+flag endflag;
aSig = extractFloatx80Frac(a);
aExp = extractFloatx80Exp(a);
@@ -1515,8 +1515,6 @@ floatx80 floatx80_sin(floatx80 a, float_status *status)
return packFloatx80(aSign, 0, 0);
}
-adjn = 0;
-
user_rnd_mode = status->float_rounding_mode;
user_rnd_prec = status->floatx80_rounding_precision;
status->float_rounding_mode = float_round_nearest_even;
@@ -1591,14 +1589,8 @@ floatx80 floatx80_sin(floatx80 a, float_status *status)
status->float_rounding_mode = user_rnd_mode;
status->floatx80_rounding_precision = user_rnd_prec;
-if (adjn) {
-/* COSTINY */
-a = floatx80_sub(fp0, float32_to_floatx80(
- make_float32(0x0080), status), status);
-} else {
-/* SINTINY */
-a = floatx80_move(a, status);
-}
+/* SINTINY */
+a = floatx80_move(a, status);
float_raise(float_flag_inexact, status);
return a;
@@ -1616,7 +1608,7 @@ floatx80 floatx80_sin(floatx80 a, float_status *status)
status); /* FP0 IS R = (X-Y1)-Y2 */
sincont:
-if ((n + adjn) & 1) {
+if (n & 1) {
/* COSPOLY */
fp0 = floatx80_mul(fp0, fp0, status); /* FP0 IS S */
fp1 = floatx80_mul(fp0, fp0, status); /* FP1 IS T */
@@ -1629,7 +1621,7 @@ floatx80 floatx80_sin(floatx80 a, float_status *status)
xExp = extractFloatx80Exp(fp0);
xSig = extractFloatx80Frac(fp0);
-if (((n + adjn) >> 1) & 1) {
+if ((n >> 1) & 1) {
xSign ^= 1;
posneg1 = make_float32(0xBF80); /* -1 */
} else {
@@ -1681,7 +1673,7 @@ floatx80 floatx80_sin(floatx80 a, float_status *status)
xExp = extractFloatx80Exp(fp0);
xSig = extractFloatx80Frac(fp0);
-xSign ^= ((n + adjn) >> 1) & 1; /* X IS NOW R'= SGN*R */
+xSign ^= (n >> 1) & 1; /* X IS NOW R'= SGN*R */
fp0 = floatx80_mul(fp0, fp0, status); /* FP0 IS S */
fp1 = floatx80_mul(fp0, fp0, status); /* FP1 IS T */
@@ -1744,7 +1736,7 @@ floatx80 floatx80_cos(floatx80 a, float_status *status)
int32_t compact, l, n, j;
floatx80 fp0, fp1, fp2, fp3, fp4, fp5, x, invtwopi, twopi1, twopi2;
float32 posneg1, twoto63;
-flag adjn, endflag;
+flag endflag;
aSig = extractFloatx80Frac(a);
aExp = extractFloatx80Exp(a);
@@ -1762,8 +1754,6 @@ floatx80 floatx80_cos(floatx80 a, float_status *status)
return packFloatx80(0, one_exp, one_sig);
}
-adjn = 1;
-
user_rnd_mode = status->float_rounding_mode;
user_rnd_prec = status->floatx80_rounding_precision;
status->float_rounding_mode = float_round_nearest_even;
@@ -1837,15 +1827,10 @@ floatx80 floatx80_cos(floatx80 a, float_status *status)
status->float_rounding_mode = user_rnd_mode;
status->floatx80_rounding_precision = user_rnd_prec;
-if (adjn) {
-/* COSTINY */
-a = floatx80_sub(fp0, float32_to_floatx80(
- make_float32(0x0080), status),
- status);
-} else {
-/* SINTINY */
-a = floatx80_move(a, status);
-}
+/* COSTINY */
+a = floatx80_sub(fp0, float32_to_floatx80(
+ make_float32(0x0080), status),
+ status);
float_raise(float_flag_inexact, status);
return a;
@@ -1863,7 +1848,7 @@ floatx80 floatx80_cos(floatx80 a, float_status *status)
status); /* FP0 IS R = (X-Y1)-Y2 */
sincont:
-if ((n + adjn) & 1) {
+if ((n + 1) & 1) {
/* COSPOLY */
fp0 = floatx80_mul(fp0, fp0, status); /* FP0 IS S */
fp1 = floatx80_mul(fp0, fp0, status); /* FP1 IS T */
@@ -1876,7 +1861,7 @@ floatx80 floatx80_cos(floatx80 a, float_status *status)
xExp = extractFloatx80Exp(fp0);
xSig = extractFloatx80Frac(fp0);
-if (((n + adjn) >> 1) & 1) {
+
[Qemu-devel] [PATCH 1/2] m68k: Fix floatx80_lognp1 (Coverity CID1390587)
return the result of packFloatx80() instead of
dropping it.
Signed-off-by: Laurent Vivier
---
target/m68k/softfloat.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/target/m68k/softfloat.c b/target/m68k/softfloat.c
index dffb371c71..2c069a5efb 100644
--- a/target/m68k/softfloat.c
+++ b/target/m68k/softfloat.c
@@ -334,7 +334,8 @@ floatx80 floatx80_lognp1(floatx80 a, float_status *status)
if (aSign && aExp >= one_exp) {
if (aExp == one_exp && aSig == one_sig) {
float_raise(float_flag_divbyzero, status);
-packFloatx80(aSign, floatx80_infinity.high, floatx80_infinity.low);
+return packFloatx80(aSign, floatx80_infinity.high,
+floatx80_infinity.low);
}
float_raise(float_flag_invalid, status);
return floatx80_default_nan(status);
--
2.14.3
Re: [Qemu-devel] [PATCH 5/5] iotests: Let 216 make use of qemu-io's exit code
On 04/28/2018 09:41 AM, Max Reitz wrote:
As a showcase of how you can use qemu-io's exit code to determine
success or failure (same for qemu-img), this test is changed to use
qemu_io_silent() instead of qemu_io(), and to assert the exit code
instead of logging the filtered result.
One real advantage of this is that in case of an error, you get a
backtrace that helps you locate the issue in the test file quickly.
Signed-off-by: Max Reitz
---
tests/qemu-iotests/216 | 23 ---
tests/qemu-iotests/216.out | 17 ++---
2 files changed, 14 insertions(+), 26 deletions(-)
-qemu_img_pipe('create', '-f', iotests.imgfmt, base_img_path, '64M')
+assert qemu_img('create', '-f', iotests.imgfmt, base_img_path, '64M') == 0
Yeah, I can see how writing the setup for a test gets simpler when you
don't have to worry about logging and filtering the stuff that isn't the
heart of the test.
Reviewed-by: Eric Blake
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
Re: [Qemu-devel] [PATCH 4/5] iotests.py: Add qemu_io_silent
On 04/28/2018 09:41 AM, Max Reitz wrote: With qemu-io now returning a useful exit code, some tests may find it sufficient to just query that instead of logging (and filtering) the whole output. Signed-off-by: Max Reitz --- tests/qemu-iotests/iotests.py | 9 + 1 file changed, 9 insertions(+) Reviewed-by: Eric Blake -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: [Qemu-devel] [PATCH 3/5] qemu-io: Exit with error when a command failed
On 04/28/2018 09:41 AM, Max Reitz wrote:
Currently, qemu-io basically always returns success when it gets to
interactive mode (so once the whole command line has been parsed; even
before the commands on the command line are interpreted). That is not
very useful.
This patch makes qemu-io return failure when any of the executed
commands failed.
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1519617
Signed-off-by: Max Reitz
---
qemu-io.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
@@ -672,5 +683,10 @@ int main(int argc, char **argv)
blk_unref(qemuio_blk);
g_free(readline_state);
-return 0;
+
+if (ret < 0) {
+return 1;
+} else {
+return 0;
+}
Would spelling this EXIT_SUCCESS/EXIT_FAILURE make it any more legible?
But we aren't consistently using those anywhere else, so you aren't
making it worse by using 0/1.
Reviewed-by: Eric Blake
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
Re: [Qemu-devel] [Xen-devel] [PATCH 2/4] block/xen_disk: remove use of grant map/unmap
On Mon, Apr 30, 2018 at 01:01:37PM +0100, Paul Durrant wrote: > The grant copy operation was added to libxengnttab in Xen 4.8.0. If grant > copy is available then data from the guest will be copied rather than > mapped. > The xen_disk source can be significantly simplified by removing this now > redundant code. Hm, I know this is a PITA, but FreeBSD gntdev hasn't implemented the grant-copy operation yet. I could try to implement it, but I can't make any promises on the time ATM, since I'm quite busy. Thanks, Roger.
Re: [Qemu-devel] [PULL v1 0/5] Xilinx queue 2018-04-30
On 30 April 2018 at 16:08, Edgar E. Iglesias wrote: > From: "Edgar E. Iglesias" > > The following changes since commit 6f0c4706b35dead265509115ddbd2a8d1af516c1: > > Merge remote-tracking branch > 'remotes/kraxel/tags/usb-20180427-pull-request' into staging (2018-04-27 > 12:27:59 +0100) > > are available in the git repository at: > > g...@github.com:edgarigl/qemu.git > tags/edgar/xilinx-next-2018-04-30.for-upstream > > for you to fetch changes up to fce6a8eceb07e27f0cdea87427f4e560dfa0b1c8: > > target-microblaze: mmu: Make the TLBX MISS bit read-only (2018-04-30 > 16:43:20 +0200) > > > edgar/xilinx-next-2018-01.for-upstream > > > Edgar E. Iglesias (5): > target-microblaze: Respect MSR.PVR as read-only > target-microblaze: Fix trap checks for FPU insns > target-microblaze: Don't clobber the IMM reg for ld/st reversed > target-microblaze: mmu: Make TLBSX write-only > target-microblaze: mmu: Make the TLBX MISS bit read-only > > target/microblaze/mmu.c | 9 - > target/microblaze/translate.c | 6 ++ > 2 files changed, 10 insertions(+), 5 deletions(-) > > Edgar E. Iglesias (5): > target-microblaze: Respect MSR.PVR as read-only > target-microblaze: Fix trap checks for FPU insns > target-microblaze: Don't clobber the IMM reg for ld/st reversed > target-microblaze: mmu: Make TLBSX write-only > target-microblaze: mmu: Make the TLBX MISS bit read-only > > target/microblaze/mmu.c | 9 - > target/microblaze/translate.c | 6 ++ > 2 files changed, 10 insertions(+), 5 deletions(-) Applied, thanks. -- PMM
Re: [Qemu-devel] [RFC PATCH v2 11/19] replay: flush events when exitting
On 04/28/2018 07:37 AM, Pavel Dovgalyuk wrote: In the subject: s/exitting/exiting/ This patch adds events processing when emulation finishes instead of just cleaning the queue. Now the bdrv coroutines will be in consistent state when emulator closes. It allows correct polling of the block layer at exit. Signed-off-by: Pavel Dovgalyuk --- replay/replay-events.c | 14 +- replay/replay-internal.h |2 -- 2 files changed, 1 insertion(+), 15 deletions(-) -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: [Qemu-devel] [PATCH 2/2] iotests: Repairing error during snapshot deletion
On 04/28/2018 11:34 AM, Max Reitz wrote: This adds a test for an I/O error during snapshot deletion, and maybe more importantly, for how to repair the resulting image. If the snapshot has been deleted before the error occurs, the only negative result will be leaked clusters -- and those should be repairable with qemu-img check -r leaks. Signed-off-by: Max Reitz --- tests/qemu-iotests/217 | 89 ++ tests/qemu-iotests/217.out | 42 ++ tests/qemu-iotests/group | 1 + 3 files changed, 132 insertions(+) create mode 100755 tests/qemu-iotests/217 create mode 100644 tests/qemu-iotests/217.out + +# Internal snapshots are (currently) impossible with refcount_bits=1 +_unsupported_imgopts 'refcount_bits=1[^0-9]' + And even if they are made possible (by cloning clusters instead of incrementing refcounts), you STILL need a refcount > 1 to test the particular repair functionality just fixed. Up to you if you want to reword that comment a bit. Reviewed-by: Eric Blake -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: [Qemu-devel] [PATCH] trivial: Do not include pci.h if it is not necessary
On Mon, Apr 30, 2018 at 09:32:19AM +0200, Thomas Huth wrote: > There is no need to include pci.h in these files. > > Signed-off-by: Thomas Huth Reviewed-by: Michael S. Tsirkin > --- > include/hw/ppc/ppc4xx.h| 2 -- > include/hw/virtio/virtio-balloon.h | 1 - > include/hw/virtio/virtio-gpu.h | 1 - > 3 files changed, 4 deletions(-) > > diff --git a/include/hw/ppc/ppc4xx.h b/include/hw/ppc/ppc4xx.h > index cb0bb55..3a2a04c 100644 > --- a/include/hw/ppc/ppc4xx.h > +++ b/include/hw/ppc/ppc4xx.h > @@ -25,8 +25,6 @@ > #ifndef PPC4XX_H > #define PPC4XX_H > > -#include "hw/pci/pci.h" > - > /* PowerPC 4xx core initialization */ > PowerPCCPU *ppc4xx_init(const char *cpu_model, > clk_setup_t *cpu_clk, clk_setup_t *tb_clk, > diff --git a/include/hw/virtio/virtio-balloon.h > b/include/hw/virtio/virtio-balloon.h > index 1ea13bd..e0df352 100644 > --- a/include/hw/virtio/virtio-balloon.h > +++ b/include/hw/virtio/virtio-balloon.h > @@ -17,7 +17,6 @@ > > #include "standard-headers/linux/virtio_balloon.h" > #include "hw/virtio/virtio.h" > -#include "hw/pci/pci.h" > > #define TYPE_VIRTIO_BALLOON "virtio-balloon-device" > #define VIRTIO_BALLOON(obj) \ > diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h > index 22ac3c2..79bb3fb 100644 > --- a/include/hw/virtio/virtio-gpu.h > +++ b/include/hw/virtio/virtio-gpu.h > @@ -18,7 +18,6 @@ > #include "ui/qemu-pixman.h" > #include "ui/console.h" > #include "hw/virtio/virtio.h" > -#include "hw/pci/pci.h" > #include "qemu/log.h" > > #include "standard-headers/linux/virtio_gpu.h" > -- > 1.8.3.1
Re: [Qemu-devel] [PATCH 2/9] target/arm: Implement vector shifted FCVT for fp16
Richard Henderson writes:
> While we have some of the scalar paths for FCVT for fp16,
> we failed to decode the fp16 version of these instructions.
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/translate-a64.c | 65
> --
> 1 file changed, 46 insertions(+), 19 deletions(-)
>
> diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
> index c92e052686..e2d11998bd 100644
> --- a/target/arm/translate-a64.c
> +++ b/target/arm/translate-a64.c
> @@ -7120,19 +7120,28 @@ static void handle_simd_shift_fpint_conv(DisasContext
> *s, bool is_scalar,
> bool is_q, bool is_u,
> int immh, int immb, int rn, int rd)
> {
> -bool is_double = extract32(immh, 3, 1);
> int immhb = immh << 3 | immb;
> -int fracbits = (is_double ? 128 : 64) - immhb;
> -int pass;
> +int pass, size, fracbits;
> TCGv_ptr tcg_fpstatus;
> TCGv_i32 tcg_rmode, tcg_shift;
>
> -if (!extract32(immh, 2, 2)) {
> -unallocated_encoding(s);
> -return;
> -}
> -
> -if (!is_scalar && !is_q && is_double) {
> +if (immh & 0x8) {
> +size = MO_64;
> +if (!is_scalar && !is_q) {
> +unallocated_encoding(s);
> +return;
> +}
> +} else if (immh & 0x4) {
> +size = MO_32;
> +} else if (immh & 0x2) {
> +size = MO_16;
> +if (!arm_dc_feature(s, ARM_FEATURE_V8_FP16)) {
> +unallocated_encoding(s);
> +return;
> +}
> +} else {
> +/* Should have split out AdvSIMD modified immediate earlier. */
> +assert(immh == 1);
> unallocated_encoding(s);
> return;
> }
> @@ -7144,11 +7153,12 @@ static void handle_simd_shift_fpint_conv(DisasContext
> *s, bool is_scalar,
> assert(!(is_scalar && is_q));
>
> tcg_rmode = tcg_const_i32(arm_rmode_to_sf(FPROUNDING_ZERO));
> -tcg_fpstatus = get_fpstatus_ptr(false);
> +tcg_fpstatus = get_fpstatus_ptr(size == MO_16);
> gen_helper_set_rmode(tcg_rmode, tcg_rmode, tcg_fpstatus);
> +fracbits = (16 << size) - immhb;
> tcg_shift = tcg_const_i32(fracbits);
>
> -if (is_double) {
> +if (size == 3) {
> int maxpass = is_scalar ? 1 : 2;
>
> for (pass = 0; pass < maxpass; pass++) {
> @@ -7165,20 +7175,37 @@ static void handle_simd_shift_fpint_conv(DisasContext
> *s, bool is_scalar,
> }
> clear_vec_high(s, is_q, rd);
> } else {
> -int maxpass = is_scalar ? 1 : is_q ? 4 : 2;
> +void (*fn)(TCGv_i32, TCGv_i32, TCGv_i32, TCGv_ptr);
> +int maxpass = is_scalar ? 1 : (8 << is_q >> size);
brackets
> +
> +switch (size) {
> +case MO_16:
> +if (is_u) {
> +fn = gen_helper_vfp_toulh;
> +} else {
> +fn = gen_helper_vfp_toslh;
> +}
> +break;
> +case MO_32:
> +if (is_u) {
> +fn = gen_helper_vfp_touls;
> +} else {
> +fn = gen_helper_vfp_tosls;
> +}
> +break;
> +default:
> +g_assert_not_reached();
> +}
> +
> for (pass = 0; pass < maxpass; pass++) {
> TCGv_i32 tcg_op = tcg_temp_new_i32();
>
> -read_vec_element_i32(s, tcg_op, rn, pass, MO_32);
> -if (is_u) {
> -gen_helper_vfp_touls(tcg_op, tcg_op, tcg_shift,
> tcg_fpstatus);
> -} else {
> -gen_helper_vfp_tosls(tcg_op, tcg_op, tcg_shift,
> tcg_fpstatus);
> -}
> +read_vec_element_i32(s, tcg_op, rn, pass, size);
> +fn(tcg_op, tcg_op, tcg_shift, tcg_fpstatus);
> if (is_scalar) {
> write_fp_sreg(s, rd, tcg_op);
> } else {
> -write_vec_element_i32(s, tcg_op, rd, pass, MO_32);
> +write_vec_element_i32(s, tcg_op, rd, pass, size);
> }
> tcg_temp_free_i32(tcg_op);
> }
--
Alex Bennée
Re: [Qemu-devel] [PATCH 1/2] qcow2: Repair OFLAG_COPIED when fixing leaks
On 04/28/2018 11:34 AM, Max Reitz wrote: Repairing OFLAG_COPIED is usually safe because it is done after the refcounts have been repaired. Therefore, it we did not find anyone else referencing a data or L2 cluster, it makes no sense to not set OFLAG_COPIED -- and the other direction (clearing OFLAG_COPIED) is always safe, anyway, it may just induce leaks. Furthermore, if OFLAG_COPIED is actually consistent with a wrong (leaky) refcount, we will decrement the refcount with -r leaks, but OFLAG_COPIED will then be wrong. qemu-img check should not produce images that are more corrupted afterwards then they were before. Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1527085 Signed-off-by: Max Reitz --- block/qcow2-refcount.c | 25 + 1 file changed, 17 insertions(+), 8 deletions(-) Reviewed-by: Eric Blake -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: [Qemu-devel] [Xen-devel] [PATCH 2/4] block/xen_disk: remove use of grant map/unmap
> -Original Message- > From: Roger Pau Monne > Sent: 30 April 2018 16:12 > To: Paul Durrant > Cc: xen-de...@lists.xenproject.org; qemu-bl...@nongnu.org; qemu- > de...@nongnu.org; Anthony Perard ; Kevin > Wolf ; Stefano Stabellini ; Max > Reitz > Subject: Re: [Xen-devel] [PATCH 2/4] block/xen_disk: remove use of grant > map/unmap > > On Mon, Apr 30, 2018 at 01:01:37PM +0100, Paul Durrant wrote: > > The grant copy operation was added to libxengnttab in Xen 4.8.0. If grant > > copy is available then data from the guest will be copied rather than > > mapped. > > The xen_disk source can be significantly simplified by removing this now > > redundant code. > > Hm, I know this is a PITA, but FreeBSD gntdev hasn't implemented the > grant-copy operation yet. > > I could try to implement it, but I can't make any promises on the time > ATM, since I'm quite busy. > I guess we could carry a compat patch in QEMU that implements grant copy by doing a map/memcpy/unmap , but QEMU feels like the wrong place for that. I could try putting together a similar patch for the freebsd.c component of libxengnttab in the xen source rather than it simply failing with ENOSYS as it does now. Would either of those help? Cheers, Paul > Thanks, Roger.
Re: [Qemu-devel] [PULL 01/46] memfd: fix configure test
This one is needed to build QEMU 2.11.x on Ubuntu 18.04.
On Wed, 20 Dec 2017 18:14:13 +0100
Paolo Bonzini wrote:
> Recent glibc added memfd_create in sys/mman.h. This conflicts with
> the definition in util/memfd.c:
>
> /builddir/build/BUILD/qemu-2.11.0-rc1/util/memfd.c:40:12: error: static
> declaration of memfd_create follows non-static declaration
>
> Fix the configure test, and remove the sys/memfd.h inclusion since the
> file actually does not exist---it is a typo in the memfd_create(2) man
> page.
>
> Cc: Marc-André Lureau
> Signed-off-by: Paolo Bonzini
> ---
> configure| 2 +-
> util/memfd.c | 4 +---
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/configure b/configure
> index 9c8aa5a..99ccc17 100755
> --- a/configure
> +++ b/configure
> @@ -3923,7 +3923,7 @@ fi
> # check if memfd is supported
> memfd=no
> cat > $TMPC << EOF
> -#include
> +#include
>
> int main(void)
> {
> diff --git a/util/memfd.c b/util/memfd.c
> index 4571d1a..412e94a 100644
> --- a/util/memfd.c
> +++ b/util/memfd.c
> @@ -31,9 +31,7 @@
>
> #include "qemu/memfd.h"
>
> -#ifdef CONFIG_MEMFD
> -#include
> -#elif defined CONFIG_LINUX
> +#if defined CONFIG_LINUX && !defined CONFIG_MEMFD
> #include
> #include
>
Re: [Qemu-devel] [PATCH v6 1/2] Implement .hex file loader
> A malicious input file can control the following values:
> * record_index using whitespace (see "case default" below)
> * byte_count in range [0x00, 0xff]
> * our_checksum = 0 by choosing the right address field values
Oh, that is really a disaster...
Thanks for your review.
Su Hang
> -Original Messages-
> From: "Stefan Hajnoczi"
> Sent Time: 2018-04-30 22:23:40 (Monday)
> To: "Su Hang"
> Cc: j...@groklearning.com, j...@jms.id.au, qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] [PATCH v6 1/2] Implement .hex file loader
>
> On Thu, Apr 26, 2018 at 09:51:37PM +0800, Su Hang wrote:
> > if (arm_feature(&cpu->env, ARM_FEATURE_AARCH64) && kernel_size < 0) {
> > kernel_size = load_aarch64_image(info->kernel_filename,
> > info->loader_start, &entry, as);
> > is_linux = 1;
> > -} else if (kernel_size < 0) {
> > -/* 32-bit ARM */
> > +}
> > +if (kernel_size < 0) {
> > +/* 32-bit ARM binary file */
> > entry = info->loader_start + KERNEL_LOAD_ADDR;
> > -kernel_size = load_image_targphys_as(info->kernel_filename, entry,
> > - info->ram_size -
> > KERNEL_LOAD_ADDR,
> > - as);
> > +kernel_size =
> > +load_image_targphys_as(info->kernel_filename, entry,
> > + info->ram_size - KERNEL_LOAD_ADDR, as);
>
> These changes seem unnecessary.
>
> > +/* return 0 or -1 if error */
> > +static size_t parse_record(HexLine *line, uint8_t *our_checksum,
>
> size_t is unsigned, so returning -1 is not ideal. This function only
> needs to return success or failure. Please use bool instead.
>
> > +typedef struct {
> > +const char *filename;
> > +HexLine line;
> > +uint8_t *bin_buf;
> > +hwaddr *addr;
> > +size_t total_size;
>
> Please use int instead of size_t since this is the return value from
> load_image_hex_as().
>
> > +uint32_t next_address_to_write;
> > +uint32_t current_address;
> > +uint32_t current_rom_index;
> > +uint32_t rom_start_address;
> > +AddressSpace *as;
> > +} HexParser;
> > +
> > +/* return size or -1 if error */
> > +static size_t handle_record_type(HexParser *parser)
>
> Please use int instead of size_t (see above for reasons).
>
> > +{
> > +HexLine *line = &(parser->line);
> > +switch (line->record_type) {
> > +case DATA_RECORD:
> > +parser->current_address =
> > +(parser->next_address_to_write & 0x) | line->address;
> > +/* verify this is a contiguous block of memory */
> > +if (parser->current_address != parser->next_address_to_write) {
> > +if (parser->current_rom_index != 0) {
> > +rom_add_hex_blob_as(parser->filename, parser->bin_buf,
> > +parser->current_rom_index,
> > +parser->rom_start_address, parser->as);
> > +}
> > +parser->rom_start_address = parser->current_address;
> > +parser->current_rom_index = 0;
> > +}
> > +
> > +/* copy from line buffer to output bin_buf */
> > +memcpy(parser->bin_buf + parser->current_rom_index, line->data,
> > + line->byte_count);
> > +parser->current_rom_index += line->byte_count;
> > +parser->total_size += line->byte_count;
> > +/* save next address to write */
> > +parser->next_address_to_write =
> > +parser->current_address + line->byte_count;
> > +break;
> > +
> > +case EOF_RECORD:
> > +if (parser->current_rom_index != 0) {
> > +rom_add_hex_blob_as(parser->filename, parser->bin_buf,
> > +parser->current_rom_index,
> > +parser->rom_start_address, parser->as);
> > +}
> > +return parser->total_size;
> > +case EXT_SEG_ADDR_RECORD:
> > +case EXT_LINEAR_ADDR_RECORD:
> > +if (line->byte_count != 2 && line->address != 0) {
> > +return -1;
> > +}
> > +
> > +if (parser->current_rom_index != 0) {
> > +rom_add_hex_blob_as(parser->filename, parser->bin_buf,
> > +parser->current_rom_index,
> > +parser->rom_start_address, parser->as);
> > +}
> > +
> > +/* save next address to write,
> > + * in case of non-contiguous block of memory */
> > +parser->next_address_to_write =
> > +line->record_type == EXT_SEG_ADDR_RECORD
> > +? ((line->data[0] << 12) | (line->data[1] << 4))
> > +: ((line->data[0] << 24) | (line->data[1] << 16));
> > +parser->rom_start_address = parser->next_address_to_write;
> > +parser->current_rom_index = 0;
> > +break;
> > +
> > +case START_SEG_ADDR_RECORD
Re: [Qemu-devel] [Xen-devel] [PATCH 2/4] block/xen_disk: remove use of grant map/unmap
> -Original Message- > From: Roger Pau Monne > Sent: 30 April 2018 16:28 > To: Paul Durrant > Cc: xen-de...@lists.xenproject.org; qemu-bl...@nongnu.org; qemu- > de...@nongnu.org; Anthony Perard ; Kevin > Wolf ; Stefano Stabellini ; Max > Reitz > Subject: Re: [Xen-devel] [PATCH 2/4] block/xen_disk: remove use of grant > map/unmap > > On Mon, Apr 30, 2018 at 04:16:52PM +0100, Paul Durrant wrote: > > > -Original Message- > > > From: Roger Pau Monne > > > Sent: 30 April 2018 16:12 > > > To: Paul Durrant > > > Cc: xen-de...@lists.xenproject.org; qemu-bl...@nongnu.org; qemu- > > > de...@nongnu.org; Anthony Perard ; > Kevin > > > Wolf ; Stefano Stabellini ; > Max > > > Reitz > > > Subject: Re: [Xen-devel] [PATCH 2/4] block/xen_disk: remove use of > grant > > > map/unmap > > > > > > On Mon, Apr 30, 2018 at 01:01:37PM +0100, Paul Durrant wrote: > > > > The grant copy operation was added to libxengnttab in Xen 4.8.0. If > grant > > > > copy is available then data from the guest will be copied rather than > > > > mapped. > > > > The xen_disk source can be significantly simplified by removing this > now > > > > redundant code. > > > > > > Hm, I know this is a PITA, but FreeBSD gntdev hasn't implemented the > > > grant-copy operation yet. > > > > > > I could try to implement it, but I can't make any promises on the time > > > ATM, since I'm quite busy. > > > > > > > I guess we could carry a compat patch in QEMU that implements grant copy > by doing a map/memcpy/unmap , but QEMU feels like the wrong place for > that. I could try putting together a similar patch for the freebsd.c component > of libxengnttab in the xen source rather than it simply failing with ENOSYS as > it does now. Would either of those help? > > Maybe this could be implemented in gnttab_core.c, so it can also be > used by MiniOS and Linux versions not supporting the copy ioctl as a > fallback? That sounds like a reasonable idea. I'll put something together so that it can go in early in 4.12. Paul > > Roger.
Re: [Qemu-devel] [Xen-devel] [PATCH 2/4] block/xen_disk: remove use of grant map/unmap
On Mon, Apr 30, 2018 at 04:16:52PM +0100, Paul Durrant wrote: > > -Original Message- > > From: Roger Pau Monne > > Sent: 30 April 2018 16:12 > > To: Paul Durrant > > Cc: xen-de...@lists.xenproject.org; qemu-bl...@nongnu.org; qemu- > > de...@nongnu.org; Anthony Perard ; Kevin > > Wolf ; Stefano Stabellini ; Max > > Reitz > > Subject: Re: [Xen-devel] [PATCH 2/4] block/xen_disk: remove use of grant > > map/unmap > > > > On Mon, Apr 30, 2018 at 01:01:37PM +0100, Paul Durrant wrote: > > > The grant copy operation was added to libxengnttab in Xen 4.8.0. If grant > > > copy is available then data from the guest will be copied rather than > > > mapped. > > > The xen_disk source can be significantly simplified by removing this now > > > redundant code. > > > > Hm, I know this is a PITA, but FreeBSD gntdev hasn't implemented the > > grant-copy operation yet. > > > > I could try to implement it, but I can't make any promises on the time > > ATM, since I'm quite busy. > > > > I guess we could carry a compat patch in QEMU that implements grant copy by > doing a map/memcpy/unmap , but QEMU feels like the wrong place for that. I > could try putting together a similar patch for the freebsd.c component of > libxengnttab in the xen source rather than it simply failing with ENOSYS as > it does now. Would either of those help? Maybe this could be implemented in gnttab_core.c, so it can also be used by MiniOS and Linux versions not supporting the copy ioctl as a fallback? Roger.
[Qemu-devel] [Bug 1766841] Re: QEMU 2.12 Running Problem in Windows 7 Installation
Both messages are warnings – QEMU will work nevertheless. The first warning can be fixed as the message says (that needs an additional installation of Cygwin for gdk-pixbuf-query-loaders). It is also suppressed if there is an empty file loaders.cache. Newer installers (for example those from today) will create such an empty file automatically. I don't get the second warning. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1766841 Title: QEMU 2.12 Running Problem in Windows 7 Installation Status in QEMU: Confirmed Bug description: QEMU Version: 2.12 (Binary installer qemu-w64-setup-20180424.exe from Stefan Weil's website so I am not sure I should report it to Weil by email or by this bug report system.) Host System: Windows 7 64bit Guest System: 9front 6350 (Codename“CONTENTS, MAINTAINED, STABLE”, Release 2018/02/02) QEMU Command: qemu-system-x86_64 -usb -device usb-mouse -hda plan9.qcow2.img -cdrom 9front-6350.iso -boot d QEMU warning: (qemu-system-x86_64.exe:8844): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file 'D:\qemu\lib\gdk-pixbuf-2.0\2.10.0\loaders.cache': No such file or directory This likely means that your installation is broken. Try running the command gdk-pixbuf-query-loaders > D:\qemu\lib\gdk-pixbuf-2.0\2.10.0\loaders.cache to make things work again for the time being. (qemu-system-x86_64.exe:8844): Gtk-WARNING **: Could not find the icon 'window-minimize-symbolic-ltr'. The 'hicolor' theme was not found either, perhaps you need to install it. You can get a copy from: http://icon-theme.freedesktop.org/releases To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1766841/+subscriptions
[Qemu-devel] [PULL v1 5/5] target-microblaze: mmu: Make the TLBX MISS bit read-only
From: "Edgar E. Iglesias"
Make the TLBX MISS bit read-only.
Reviewed-by: Alistair Francis
Reviewed-by: Richard Henderson
Signed-off-by: Edgar E. Iglesias
---
target/microblaze/mmu.c | 4
1 file changed, 4 insertions(+)
diff --git a/target/microblaze/mmu.c b/target/microblaze/mmu.c
index 8391811900..9d5e6aa8a5 100644
--- a/target/microblaze/mmu.c
+++ b/target/microblaze/mmu.c
@@ -273,6 +273,10 @@ void mmu_write(CPUMBState *env, uint32_t rn, uint32_t v)
env->mmu.regs[rn] = v;
}
break;
+case MMU_R_TLBX:
+/* Bit 31 is read-only. */
+env->mmu.regs[rn] = deposit32(env->mmu.regs[rn], 0, 31, v);
+break;
case MMU_R_TLBSX:
{
struct microblaze_mmu_lookup lu;
--
2.14.1
Re: [Qemu-devel] [PATCH 2/5] qemu-io: Let command functions return error code
On 2018-04-30 17:08, Eric Blake wrote: > On 04/28/2018 09:41 AM, Max Reitz wrote: >> This is basically what everything else in the qemu code base does, so we >> can do it here, too. >> >> Signed-off-by: Max Reitz >> --- >> include/qemu-io.h | 4 +- >> qemu-io-cmds.c | 346 >> -- >> qemu-io.c | 34 -- >> 3 files changed, 227 insertions(+), 157 deletions(-) >> >> diff --git a/include/qemu-io.h b/include/qemu-io.h >> index 06cdfbf660..380724ad59 100644 >> --- a/include/qemu-io.h >> +++ b/include/qemu-io.h >> @@ -22,7 +22,7 @@ >> #define CMD_FLAG_GLOBAL ((int)0x8000) /* don't iterate "args" */ >> -typedef void (*cfunc_t)(BlockBackend *blk, int argc, char **argv); >> +typedef int (*cfunc_t)(BlockBackend *blk, int argc, char **argv); > > Quite a bit of churn on the definition here; squashing 1 and 2 might > make for a smaller patch. But I agree that doing it this way (2 > separate patches) forces us to audit (with the compiler's help) that all > callers are caught and adjusted to the new semantics. > > However, a comment before the typedef would be useful, so that writing a > new command knows what semantics it must provide. It can be as simple as: > > /* Implement a qemu-io command. > * Operate on @blk using @argc/@argv as the command's arguments, and > * return 0 on success or negative errno on failure. > */ Yep, will do. > With a comment added, > Reviewed-by: Eric Blake Thanks! Max signature.asc Description: OpenPGP digital signature
[Qemu-devel] [PULL v1 3/5] target-microblaze: Don't clobber the IMM reg for ld/st reversed
From: "Edgar E. Iglesias" Do not clobber the IMM register on reversed load/stores. Reviewed-by: Richard Henderson Signed-off-by: Edgar E. Iglesias --- target/microblaze/translate.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/target/microblaze/translate.c b/target/microblaze/translate.c index ec12fed49d..100883e2cc 100644 --- a/target/microblaze/translate.c +++ b/target/microblaze/translate.c @@ -952,7 +952,6 @@ static void dec_load(DisasContext *dc) tcg_gen_sub_tl(low, tcg_const_tl(3), low); tcg_gen_andi_tl(t, t, ~3); tcg_gen_or_tl(t, t, low); -tcg_gen_mov_tl(env_imm, t); tcg_temp_free(low); break; } @@ -1104,7 +1103,6 @@ static void dec_store(DisasContext *dc) tcg_gen_sub_tl(low, tcg_const_tl(3), low); tcg_gen_andi_tl(t, t, ~3); tcg_gen_or_tl(t, t, low); -tcg_gen_mov_tl(env_imm, t); tcg_temp_free(low); break; } -- 2.14.1
[Qemu-devel] [PULL v1 2/5] target-microblaze: Fix trap checks for FPU insns
From: "Edgar E. Iglesias"
Fix trap checks for FPU insns when extended FPU insns are enabled.
Reviewed-by: Alistair Francis
Reviewed-by: Richard Henderson
Signed-off-by: Edgar E. Iglesias
---
target/microblaze/translate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/microblaze/translate.c b/target/microblaze/translate.c
index f739751930..ec12fed49d 100644
--- a/target/microblaze/translate.c
+++ b/target/microblaze/translate.c
@@ -1412,7 +1412,7 @@ static void dec_fpu(DisasContext *dc)
if ((dc->tb_flags & MSR_EE_FLAG)
&& (dc->cpu->env.pvr.regs[2] & PVR2_ILL_OPCODE_EXC_MASK)
- && (dc->cpu->cfg.use_fpu != 1)) {
+ && !dc->cpu->cfg.use_fpu) {
tcg_gen_movi_tl(cpu_SR[SR_ESR], ESR_EC_ILLEGAL_OP);
t_gen_raise_exception(dc, EXCP_HW_EXCP);
return;
--
2.14.1
[Qemu-devel] [Bug 1766841] Re: QEMU 2.12 Running Problem in Windows 7 Installation
** Changed in: qemu Assignee: (unassigned) => Stefan Weil (ubuntu-weilnetz) ** Changed in: qemu Status: New => Confirmed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1766841 Title: QEMU 2.12 Running Problem in Windows 7 Installation Status in QEMU: Confirmed Bug description: QEMU Version: 2.12 (Binary installer qemu-w64-setup-20180424.exe from Stefan Weil's website so I am not sure I should report it to Weil by email or by this bug report system.) Host System: Windows 7 64bit Guest System: 9front 6350 (Codename“CONTENTS, MAINTAINED, STABLE”, Release 2018/02/02) QEMU Command: qemu-system-x86_64 -usb -device usb-mouse -hda plan9.qcow2.img -cdrom 9front-6350.iso -boot d QEMU warning: (qemu-system-x86_64.exe:8844): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file 'D:\qemu\lib\gdk-pixbuf-2.0\2.10.0\loaders.cache': No such file or directory This likely means that your installation is broken. Try running the command gdk-pixbuf-query-loaders > D:\qemu\lib\gdk-pixbuf-2.0\2.10.0\loaders.cache to make things work again for the time being. (qemu-system-x86_64.exe:8844): Gtk-WARNING **: Could not find the icon 'window-minimize-symbolic-ltr'. The 'hicolor' theme was not found either, perhaps you need to install it. You can get a copy from: http://icon-theme.freedesktop.org/releases To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1766841/+subscriptions
[Qemu-devel] [PULL v1 0/5] Xilinx queue 2018-04-30
From: "Edgar E. Iglesias" The following changes since commit 6f0c4706b35dead265509115ddbd2a8d1af516c1: Merge remote-tracking branch 'remotes/kraxel/tags/usb-20180427-pull-request' into staging (2018-04-27 12:27:59 +0100) are available in the git repository at: g...@github.com:edgarigl/qemu.git tags/edgar/xilinx-next-2018-04-30.for-upstream for you to fetch changes up to fce6a8eceb07e27f0cdea87427f4e560dfa0b1c8: target-microblaze: mmu: Make the TLBX MISS bit read-only (2018-04-30 16:43:20 +0200) edgar/xilinx-next-2018-01.for-upstream Edgar E. Iglesias (5): target-microblaze: Respect MSR.PVR as read-only target-microblaze: Fix trap checks for FPU insns target-microblaze: Don't clobber the IMM reg for ld/st reversed target-microblaze: mmu: Make TLBSX write-only target-microblaze: mmu: Make the TLBX MISS bit read-only target/microblaze/mmu.c | 9 - target/microblaze/translate.c | 6 ++ 2 files changed, 10 insertions(+), 5 deletions(-) Edgar E. Iglesias (5): target-microblaze: Respect MSR.PVR as read-only target-microblaze: Fix trap checks for FPU insns target-microblaze: Don't clobber the IMM reg for ld/st reversed target-microblaze: mmu: Make TLBSX write-only target-microblaze: mmu: Make the TLBX MISS bit read-only target/microblaze/mmu.c | 9 - target/microblaze/translate.c | 6 ++ 2 files changed, 10 insertions(+), 5 deletions(-) -- 2.14.1
[Qemu-devel] [PULL v1 4/5] target-microblaze: mmu: Make TLBSX write-only
From: "Edgar E. Iglesias"
Make TLBSX write-only and guest-error log reads from it.
Reviewed-by: Alistair Francis
Reviewed-by: Richard Henderson
Signed-off-by: Edgar E. Iglesias
---
target/microblaze/mmu.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/target/microblaze/mmu.c b/target/microblaze/mmu.c
index a0f06758f8..8391811900 100644
--- a/target/microblaze/mmu.c
+++ b/target/microblaze/mmu.c
@@ -182,7 +182,7 @@ done:
uint32_t mmu_read(CPUMBState *env, uint32_t rn)
{
unsigned int i;
-uint32_t r;
+uint32_t r = 0;
if (env->mmu.c_mmu < 2 || !env->mmu.c_mmu_tlb_access) {
qemu_log_mask(LOG_GUEST_ERROR, "MMU access on MMU-less system\n");
@@ -211,6 +211,9 @@ uint32_t mmu_read(CPUMBState *env, uint32_t rn)
}
r = env->mmu.regs[rn];
break;
+case MMU_R_TLBSX:
+qemu_log_mask(LOG_GUEST_ERROR, "TLBSX is write-only.\n");
+break;
default:
r = env->mmu.regs[rn];
break;
--
2.14.1
[Qemu-devel] [PULL v1 1/5] target-microblaze: Respect MSR.PVR as read-only
From: "Edgar E. Iglesias" Respect MSR.PVR as read-only. We were wrongly overwriting the PVR bit. Reviewed-by: Richard Henderson Signed-off-by: Edgar E. Iglesias --- target/microblaze/translate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/microblaze/translate.c b/target/microblaze/translate.c index 7628b0e25b..f739751930 100644 --- a/target/microblaze/translate.c +++ b/target/microblaze/translate.c @@ -424,7 +424,7 @@ static inline void msr_write(DisasContext *dc, TCGv v) /* PVR bit is not writable. */ tcg_gen_andi_tl(t, v, ~MSR_PVR); tcg_gen_andi_tl(cpu_SR[SR_MSR], cpu_SR[SR_MSR], MSR_PVR); -tcg_gen_or_tl(cpu_SR[SR_MSR], cpu_SR[SR_MSR], v); +tcg_gen_or_tl(cpu_SR[SR_MSR], cpu_SR[SR_MSR], t); tcg_temp_free(t); } -- 2.14.1
Re: [Qemu-devel] [PATCH 2/5] qemu-io: Let command functions return error code
On 04/28/2018 09:41 AM, Max Reitz wrote: This is basically what everything else in the qemu code base does, so we can do it here, too. Signed-off-by: Max Reitz --- include/qemu-io.h | 4 +- qemu-io-cmds.c| 346 -- qemu-io.c | 34 -- 3 files changed, 227 insertions(+), 157 deletions(-) diff --git a/include/qemu-io.h b/include/qemu-io.h index 06cdfbf660..380724ad59 100644 --- a/include/qemu-io.h +++ b/include/qemu-io.h @@ -22,7 +22,7 @@ #define CMD_FLAG_GLOBAL ((int)0x8000) /* don't iterate "args" */ -typedef void (*cfunc_t)(BlockBackend *blk, int argc, char **argv); +typedef int (*cfunc_t)(BlockBackend *blk, int argc, char **argv); Quite a bit of churn on the definition here; squashing 1 and 2 might make for a smaller patch. But I agree that doing it this way (2 separate patches) forces us to audit (with the compiler's help) that all callers are caught and adjusted to the new semantics. However, a comment before the typedef would be useful, so that writing a new command knows what semantics it must provide. It can be as simple as: /* Implement a qemu-io command. * Operate on @blk using @argc/@argv as the command's arguments, and * return 0 on success or negative errno on failure. */ With a comment added, Reviewed-by: Eric Blake -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: [Qemu-devel] Large patch set advice
On 30 April 2018 at 15:44, Warner Losh wrote: > The testing aspect has me intrigued. How hard would it be to add testing > done for bsd-user to your upstream tests? Before this project, I've only > ever been a qemu user, and even then only around the edges so I'm not > familiar with what's available. For the sake of argument, you can assume > FreeBSD has its own testbed we use, some useful subset of which could be > leveraged into an extended unit test. The problem we've traditionally had is that when you're building and testing qemu on host architecture A, you can't guarantee to have a suitable cross building environment for architecture B so that you can build the test guest executables you want to run under QEMU to test whether qemu-B works. (For linux-user we're currently looking at using docker to provide consistent working cross environments, but that is work-in-progress.) > Finally, another poster suggested that delete and repopulate would be an > option. While I haven't made any final decisions on whether I want to go > that way, I'd like to know from Peter if he would accept things that way. I > think it may be easier for me to submit something like that, but on the > other hand the boiling the patches down even from 300 to 190 (where the work > stands at the moment) has identified some interesting issues I need to chase > down (mostly relating to either inappropriate for upstreaming patches mixed > in, or relating to what looks like a mismerge a few months ago due to git + > long-lived-branch + merges having... I'll be nice and say 'challenges when > changes collide'). If we definitely don't care about the current functionality of upstream for any of the BSDs (and it sounds like we don't -- thanks for looking into that), then I think the main concern is "what is easiest to code review". Which approach gives the most digestible patches for code review probably depends on how much of the existing code and structure remains after all the changes; that's a judgement call you're probably in a better position to make. Either way I would still like to see patches that are each of a reasonable size and provide coherent chunks of functionality. thanks -- PMM
Re: [Qemu-devel] [PATCH] memory.h: Improve IOMMU related documentation
On 30/04/2018 15:34, Peter Maydell wrote: >> */ >> IOMMUTLBEntry (*translate)(IOMMUMemoryRegion *iommu, hwaddr addr, >> IOMMUAccessFlags flag); > A question I just thought of -- how long is the IOMMUTLBEntry I get > back guaranteed to be valid for? For instance if I'm in an RCU > critical section can I assume it won't become invalid before I > leave the critical section? Or must I always register an IOMMU > notifier before I call translate? I'm guessing not the latter > because flatview_do_translate() does not, but is the guarantee > only RCU-critical section or while-holding-big-QEMU-lock or > something else? The only pointer inside is to the target AddressSpace, which (see address_space_destroy) is safe to access inside either of those condition. In practice we use the former. Paolo
Re: [Qemu-devel] [PATCH 1/5] qemu-io: Drop command functions' return values
On 04/28/2018 09:41 AM, Max Reitz wrote: For qemu-io, a function returns an integer with two possible values: 0 for "qemu-io may continue execution", or 1 for "qemu-io should exit". However, there is only a single command that returns 1, and that is "quit". So let's turn this case into a global variable instead so we can make better use of the return value in a later patch. Signed-off-by: Max Reitz --- include/qemu-io.h | 6 +- qemu-io-cmds.c| 294 +- qemu-io.c | 36 +++ 3 files changed, 157 insertions(+), 179 deletions(-) Reviewed-by: Eric Blake -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: [Qemu-devel] [PATCH v6 05/11] qapi: introduce new cmd option "allowed-in-preconfig"
On 04/27/2018 10:51 PM, Peter Xu wrote: QTAILQ_INIT(&qmp_cap_negotiation_commands); qmp_register_command(&qmp_cap_negotiation_commands, "qmp_capabilities", - qmp_marshal_qmp_capabilities, QCO_NO_OPTIONS); + qmp_marshal_qmp_capabilities, + QCO_ALLOWED_IN_PRECONFIG); ...why are we still special-casing the registration of qmp_capabilities here... My understanding is that we have two lists: QmpCommandList qmp_commands, qmp_cap_negotiation_commands; And here it only registers with qmp_commands list via: qmp_init_marshal(&qmp_commands); But not for the other one, which is explicitly registered at [1]. So it seems that [1] is still needed? Ah, that makes sense. I overlooked the difference in list name in the first parameter to qmp_register_command(), since that line was not changed in the diff. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: [Qemu-devel] Large patch set advice
On Thu, Apr 26, 2018 at 2:11 AM, Peter Maydell wrote: > On 25 April 2018 at 20:57, Warner Losh wrote: > > I’ve foolishly volunteered to rebase all the changes that the bad-user > > mode folks have done to a recent master rev to get these changes > upstreamed. > > A number of people have been working on this for a long time. It’s > possible > > now to run almost any FreeBSD binary from all the architectures. We use > it > > to do ‘native’ builds of tens of thousands of packages in a chroot (so > > building FreeBSD/arm packages on a FreeBSD amd64 box). The diffs are > quite > > large (on the order of 42k lines), so I anticipate some bumps in moving > > this stuff upstream. > > So, first up, thanks for agreeing to do this. It sounds from your > mail like you're already pretty well aware of the usual pitfalls > with this kind of work, and I don't really have much to add that's > QEMU specific that nobody else has said already. > > One question I do have is about the other BSDs: bsd-user at least > in theory is supposed to support freebsd, netbsd and openbsd. > Your patchsets should fix freebsd, but do you know what the status > is of netbsd and openbsd? Upstream we do compiletest but no runtime > testing; I think last time I tried it they didn't work very well, > but it would be worth checking with the other BSDs downstream to > see if they're using bsd-user and to make sure we don't break anything > that is currently working for netbsd/openbsd... > I've made inquiries. People are aware of the sbruno branch I'm working to merge. The consensus is that for NetBSD and OpenBSD both the current upstream code as well as the current sbruno branch code's status is totally broken. The sbruno branch people have said looks interesting, but doesn't materially change what's working. The testing aspect has me intrigued. How hard would it be to add testing done for bsd-user to your upstream tests? Before this project, I've only ever been a qemu user, and even then only around the edges so I'm not familiar with what's available. For the sake of argument, you can assume FreeBSD has its own testbed we use, some useful subset of which could be leveraged into an extended unit test. Finally, another poster suggested that delete and repopulate would be an option. While I haven't made any final decisions on whether I want to go that way, I'd like to know from Peter if he would accept things that way. I think it may be easier for me to submit something like that, but on the other hand the boiling the patches down even from 300 to 190 (where the work stands at the moment) has identified some interesting issues I need to chase down (mostly relating to either inappropriate for upstreaming patches mixed in, or relating to what looks like a mismerge a few months ago due to git + long-lived-branch + merges having... I'll be nice and say 'challenges when changes collide'). Thanks for all the advice so far and not giving me too much grief over my epic typos :). Warner
Re: [Qemu-devel] [PATCH qemu] qom: Document qom/device-list-properties implementation specific
Hi, This series failed build test on s390x host. Please find the details below. Type: series Message-id: 20180430065235.577-1-...@ozlabs.ru Subject: [Qemu-devel] [PATCH qemu] qom: Document qom/device-list-properties implementation specific === TEST SCRIPT BEGIN === #!/bin/bash # Testing script will be invoked under the git checkout with # HEAD pointing to a commit that has the patches applied on top of "base" # branch set -e echo "=== ENV ===" env echo "=== PACKAGES ===" rpm -qa echo "=== TEST BEGIN ===" CC=$HOME/bin/cc INSTALL=$PWD/install BUILD=$PWD/build echo -n "Using CC: " realpath $CC mkdir -p $BUILD $INSTALL SRC=$PWD cd $BUILD $SRC/configure --cc=$CC --prefix=$INSTALL make -j4 # XXX: we need reliable clean up # make check -j4 V=1 make install === TEST SCRIPT END === Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384 From https://github.com/patchew-project/qemu * [new tag] patchew/20180430065235.577-1-...@ozlabs.ru -> patchew/20180430065235.577-1-...@ozlabs.ru Switched to a new branch 'test' 248f79db68 qom: Document qom/device-list-properties implementation specific === OUTPUT BEGIN === === ENV === LANG=en_US.UTF-8 XDG_SESSION_ID=162768 USER=fam PWD=/var/tmp/patchew-tester-tmp-mmfx1cds/src HOME=/home/fam SHELL=/bin/sh SHLVL=2 PATCHEW=/home/fam/patchew/patchew-cli -s http://patchew.org --nodebug LOGNAME=fam DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1012/bus XDG_RUNTIME_DIR=/run/user/1012 PATH=/usr/bin:/bin _=/usr/bin/env === PACKAGES === gpg-pubkey-873529b8-54e386ff glibc-debuginfo-common-2.24-10.fc25.s390x fedora-release-26-1.noarch dejavu-sans-mono-fonts-2.35-4.fc26.noarch xemacs-filesystem-21.5.34-22.20170124hgf412e9f093d4.fc26.noarch bash-4.4.12-7.fc26.s390x libSM-1.2.2-5.fc26.s390x libmpc-1.0.2-6.fc26.s390x libaio-0.3.110-7.fc26.s390x libverto-0.2.6-7.fc26.s390x perl-Scalar-List-Utils-1.48-1.fc26.s390x iptables-libs-1.6.1-2.fc26.s390x tcl-8.6.6-2.fc26.s390x libxshmfence-1.2-4.fc26.s390x expect-5.45-23.fc26.s390x perl-Thread-Queue-3.12-1.fc26.noarch perl-encoding-2.19-6.fc26.s390x keyutils-1.5.10-1.fc26.s390x gmp-devel-6.1.2-4.fc26.s390x enchant-1.6.0-16.fc26.s390x python-gobject-base-3.24.1-1.fc26.s390x python3-enchant-1.6.10-1.fc26.noarch python-lockfile-0.11.0-6.fc26.noarch python2-pyparsing-2.1.10-3.fc26.noarch python2-lxml-4.1.1-1.fc26.s390x librados2-10.2.7-2.fc26.s390x trousers-lib-0.3.13-7.fc26.s390x libdatrie-0.2.9-4.fc26.s390x libsoup-2.58.2-1.fc26.s390x passwd-0.79-9.fc26.s390x bind99-libs-9.9.10-3.P3.fc26.s390x python3-rpm-4.13.0.2-1.fc26.s390x systemd-233-7.fc26.s390x virglrenderer-0.6.0-1.20170210git76b3da97b.fc26.s390x s390utils-ziomon-1.36.1-3.fc26.s390x s390utils-osasnmpd-1.36.1-3.fc26.s390x libXrandr-1.5.1-2.fc26.s390x libglvnd-glx-1.0.0-1.fc26.s390x texlive-ifxetex-svn19685.0.5-33.fc26.2.noarch texlive-psnfss-svn33946.9.2a-33.fc26.2.noarch texlive-dvipdfmx-def-svn40328-33.fc26.2.noarch texlive-natbib-svn20668.8.31b-33.fc26.2.noarch texlive-xdvi-bin-svn40750-33.20160520.fc26.2.s390x texlive-cm-svn32865.0-33.fc26.2.noarch texlive-beton-svn15878.0-33.fc26.2.noarch texlive-fpl-svn15878.1.002-33.fc26.2.noarch texlive-mflogo-svn38628-33.fc26.2.noarch texlive-texlive-docindex-svn41430-33.fc26.2.noarch texlive-luaotfload-bin-svn34647.0-33.20160520.fc26.2.noarch texlive-koma-script-svn41508-33.fc26.2.noarch texlive-pst-tree-svn24142.1.12-33.fc26.2.noarch texlive-breqn-svn38099.0.98d-33.fc26.2.noarch texlive-xetex-svn41438-33.fc26.2.noarch gstreamer1-plugins-bad-free-1.12.3-1.fc26.s390x xorg-x11-font-utils-7.5-33.fc26.s390x ghostscript-fonts-5.50-36.fc26.noarch libXext-devel-1.3.3-5.fc26.s390x libusbx-devel-1.0.21-2.fc26.s390x libglvnd-devel-1.0.0-1.fc26.s390x emacs-25.3-3.fc26.s390x alsa-lib-devel-1.1.4.1-1.fc26.s390x kbd-2.0.4-2.fc26.s390x dconf-0.26.0-2.fc26.s390x mc-4.8.19-5.fc26.s390x doxygen-1.8.13-9.fc26.s390x dpkg-1.18.24-1.fc26.s390x libtdb-1.3.13-1.fc26.s390x python2-pynacl-1.1.1-1.fc26.s390x perl-Filter-1.58-1.fc26.s390x python2-pip-9.0.1-11.fc26.noarch dnf-2.7.5-2.fc26.noarch bind-license-9.11.2-1.P1.fc26.noarch libtasn1-4.13-1.fc26.s390x cpp-7.3.1-2.fc26.s390x pkgconf-1.3.12-2.fc26.s390x python2-fedora-0.10.0-1.fc26.noarch cmake-filesystem-3.10.1-11.fc26.s390x python3-requests-kerberos-0.12.0-1.fc26.noarch libmicrohttpd-0.9.59-1.fc26.s390x GeoIP-GeoLite-data-2018.01-1.fc26.noarch python2-libs-2.7.14-7.fc26.s390x libidn2-2.0.4-3.fc26.s390x p11-kit-devel-0.23.10-1.fc26.s390x perl-Errno-1.25-396.fc26.s390x libdrm-2.4.90-2.fc26.s390x sssd-common-1.16.1-1.fc26.s390x boost-random-1.63.0-11.fc26.s390x urw-fonts-2.4-24.fc26.noarch ccache-3.3.6-1.fc26.s390x glibc-debuginfo-2.24-10.fc25.s390x dejavu-fonts-common-2.35-4.fc26.noarch bind99-license-9.9.10-3.P3.fc26.noarch ncurses-libs-6.0-8.20170212.fc26.s390x libpng-1.6.28-2.fc26.s390x libICE-1.0.9-9.fc26.s390x perl-Text-ParseWords-3.30-366.fc26.noarch libtool-ltdl-2.4.6-17.fc26.s390x libselinux-utils-2.6-7.fc26.s390x userspace-rcu-0.9.3-2.fc26.s390x perl-Class-Inspector-1.31-3.fc26.noarch keyutils-libs-devel-1.5.
Re: [Qemu-devel] release retrospective, next release timing, numbering
On Mon, Apr 30, 2018 at 04:23:59PM +0200, Greg Kurz wrote: > On Fri, 27 Apr 2018 16:51:03 +0100 > Peter Maydell wrote: > > > Hi; I usually let people forget about releases for a month or > > so before bringing this topic up, but: > > > > (1) do we want to call the next release 2.13, or something else? > > There's no particular reason to bump to 3.0 except some combination of > > * if we keep going like this we'll get up to 2.42, which starts to > >get silly > > * Linus-style "avoid being too predictable" > > * triskaidekaphobia > > but maybe we should anyway? > > > > Do we care for machine versions to stick to QEMU versions ? I ask, > because we've already added a pseries-2.13 machine type (in master > since David's latest pull req). No big deal though if we have to > turn it into pseries-3.0 I guess... We don't promise machine ABI compat for git master snapshots, so renaming is fine provided it is done before release. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [Qemu-devel] release retrospective, next release timing, numbering
On 30 April 2018 at 15:23, Greg Kurz wrote: > On Fri, 27 Apr 2018 16:51:03 +0100 > Peter Maydell wrote: > >> Hi; I usually let people forget about releases for a month or >> so before bringing this topic up, but: >> >> (1) do we want to call the next release 2.13, or something else? >> There's no particular reason to bump to 3.0 except some combination of >> * if we keep going like this we'll get up to 2.42, which starts to >>get silly >> * Linus-style "avoid being too predictable" >> * triskaidekaphobia >> but maybe we should anyway? >> > > Do we care for machine versions to stick to QEMU versions ? I ask, > because we've already added a pseries-2.13 machine type (in master > since David's latest pull req). No big deal though if we have to > turn it into pseries-3.0 I guess... Yeah, we'd just bump that to pseries-3.0. (We should probably have some more formal process for ensuring that all our versioned machines get a version for the new release at some point before rc0. We've been close to forgetting for virt once or twice.) thanks -- PMM
Re: [Qemu-devel] [PATCH] memory.h: Improve IOMMU related documentation
On Mon, 30 Apr 2018 14:35:20 +0100 Peter Maydell wrote: > On 30 April 2018 at 14:08, Paolo Bonzini wrote: > > On 30/04/2018 14:57, Peter Maydell wrote: > >> On 30 April 2018 at 13:54, Paolo Bonzini wrote: > >>> On 30/04/2018 14:24, Peter Maydell wrote: > -/* Set this up to provide customized IOMMU replay function */ > +/* Set this up to provide customized IOMMU replay function. > + * Optional method. > + */ > void (*replay)(IOMMUMemoryRegion *iommu, IOMMUNotifier *notifier); > >>> > >>> replay is needed if you want to support IOMMU notifiers. After > >>> memory_region_register_iommu_notifier you're only notified about future > >>> changes to the mappings; memory_region_iommu_replay calls the replay > >>> method so that the IOMMUNotifier is called for each existing mapping. > >> > >> Is it then unrelated to record-and-replay ? That's what I guessed > >> it was for... Also, some IOMMUs (eg spapr_iommu.c) seem to support > >> notifiers but don't implement it. > > > > Yes, it's completely unrelated. I have no idea why spapr_iommu.c > > doesn't need it, so I am CCing the sPAPR and VFIO experts... > > There does seem to be a default implementation in > memory_region_iommu_replay(), maybe that is sufficient for spapr? AIUI, the default implementation is used by spapr, it was added here: commit a788f227ef7bd2912fcaacdfe13d13ece2998149 Author: David Gibson Date: Wed Sep 30 12:13:55 2015 +1000 memory: Allow replay of IOMMU mapping notifications When we have guest visible IOMMUs, we allow notifiers to be registered which will be informed of all changes to IOMMU mappings. This is used by vfio to keep the host IOMMU mappings in sync with guest IOMMU mappings. However, unlike with a memory region listener, an iommu notifier won't be told about any mappings which already exist in the (guest) IOMMU at the time it is registered. This can cause problems if hotplugging a VFIO device onto a guest bus which had existing guest IOMMU mappings, but didn't previously have an VFIO devices (and hence no host IOMMU mappings). This adds a memory_region_iommu_replay() function to handle this case. It replays any existing mappings in an IOMMU memory region to a specified notifier. Because the IOMMU memory region doesn't internally remember the granularity of the guest IOMMU it has a small hack where the caller must specify a granularity at which to replay mappings. If there are finer mappings in the guest IOMMU these will be reported in the iotlb structures passed to the notifier which it must handle (probably causing it to flag an error). This isn't new - the VFIO iommu notifier must already handle notifications about guest IOMMU mappings too short for it to represent in the host IOMMU. Signed-off-by: David Gibson Reviewed-by: Laurent Vivier Acked-by: Paolo Bonzini Signed-off-by: Alex Williamson VT-d emulation then needed its own replay and that hook was later added here: commit faa362e3cc94bf739a89b457693e3fbd7a4b95c4 Author: Peter Xu Date: Fri Apr 7 18:59:11 2017 +0800 memory: add MemoryRegionIOMMUOps.replay() callback Originally we have one memory_region_iommu_replay() function, which is the default behavior to replay the translations of the whole IOMMU region. However, on some platform like x86, we may want our own replay logic for IOMMU regions. This patch adds one more hook for IOMMUOps for the callback, and it'll override the default if set. Reviewed-by: David Gibson Reviewed-by: Eric Auger Reviewed-by: \"Michael S. Tsirkin\" Signed-off-by: Peter Xu Message-Id: <1491562755-23867-6-git-send-email-pet...@redhat.com> Signed-off-by: Eduardo Habkost Thanks, Alex
Re: [Qemu-devel] [RFC PATCH v2 00/19] reverse debugging
I'll try to reproduce it next week. Отправлено с помощью BlueMail На 30 Апр 2018 г., 17:20, в 17:20, Ciro Santilli написал:п>Did you manage to reproduce and solve the savevm and loadvm problems I >mentioned at: >http://lists.nongnu.org/archive/html/qemu-devel/2018-04/msg05219.html >? > >I still observe them on the current patch. > >On Sat, Apr 28, 2018 at 1:36 PM, Pavel Dovgalyuk > wrote: >> GDB remote protocol supports reverse debugging of the targets. >> It includes 'reverse step' and 'reverse continue' operations. >> The first one finds the previous step of the execution, >> and the second one is intended to stop at the last breakpoint that >> would happen when the program is executed normally. >> >> Reverse debugging is possible in the replay mode, when at least >> one snapshot was created at the record or replay phase. >> QEMU can use these snapshots for travelling back in time with GDB. >> >> Running the execution in replay mode allows using GDB reverse >debugging >> commands: >> - reverse-stepi (or rsi): Steps one instruction to the past. >>QEMU loads on of the prior snapshots and proceeds to the desired >>instruction forward. When that step is reaches, execution stops. >> - reverse-continue (or rc): Runs execution "backwards". >>QEMU tries to find breakpoint or watchpoint by loaded prior >snapshot >>and replaying the execution. Then QEMU loads snapshots again and >>replays to the latest breakpoint. When there are no breakpoints in >>the examined section of the execution, QEMU finds one more >snapshot >>and tries again. After the first snapshot is processed, execution >>stops at this snapshot. >> >> The set of patches include the following modifications: >> - gdbstub update for reverse debugging support >> - functions that automatically perform reverse step and reverse >>continue operations >> - hmp/qmp commands for manipulating the replay process >> - improvement of the snapshotting for saving the execution step >>in the snapshot parameters >> - other record/replay fixes >> >> The patches are available in the repository: >> https://github.com/ispras/qemu/tree/rr-180428 >> >> v2 changes: >> - documented reverse debugging >> - fixed start vmstate loading in record mode >> - documented qcow2 changes (as suggested by Eric Blake) >> - made icount SnapshotInfo field optional (as suggested by Eric >Blake) >> - renamed qmp commands (as suggested by Eric Blake) >> - minor changes >> >> --- >> >> Pavel Dovgalyuk (19): >> block: implement bdrv_snapshot_goto for blkreplay >> replay: disable default snapshot for record/replay >> replay: update docs for record/replay with block devices >> replay: don't drain/flush bdrv queue while RR is working >> replay: finish record/replay before closing the disks >> qcow2: introduce icount field for snapshots >> migration: introduce icount field for snapshots >> replay: introduce info hmp/qmp command >> replay: introduce breakpoint at the specified step >> replay: implement replay-seek command to proceed to the desired >step >> replay: flush events when exitting >> timer: remove replay clock probe in deadline calculation >> replay: refine replay-time module >> translator: fix breakpoint processing >> replay: flush rr queue before loading the vmstate >> gdbstub: add reverse step support in replay mode >> gdbstub: add reverse continue support in replay mode >> replay: describe reverse debugging in docs/replay.txt >> replay: allow loading any snapshots before recording >> >> >> accel/tcg/translator.c|8 + >> block/blkreplay.c |8 + >> block/io.c| 22 +++ >> block/qapi.c | 17 ++- >> block/qcow2-snapshot.c|9 + >> block/qcow2.h |2 >> blockdev.c| 10 ++ >> cpus.c| 19 ++- >> docs/interop/qcow2.txt|4 + >> docs/replay.txt | 45 +++ >> exec.c|6 + >> gdbstub.c | 50 +++- >> hmp-commands-info.hx | 14 ++ >> hmp-commands.hx | 30 + >> hmp.h |3 >> include/block/snapshot.h |1 >> include/sysemu/replay.h | 18 +++ >> migration/savevm.c| 15 +- >> qapi/block-core.json |5 + >> qapi/block.json |3 >> qapi/misc.json| 68 +++ >> replay/Makefile.objs |3 >> replay/replay-debugging.c | 287 >+ >> replay/replay-events.c| 14 -- >> replay/replay-internal.h | 10 +- >> replay/replay-snapshot.c | 17 ++- >> replay/replay-time.c | 27 ++-- >> replay/replay.c | 22 +++ >> stubs/replay.c| 10 ++ >> util/qemu-timer.c | 11 -- >> vl.c | 18 ++- >> 31 files changed, 695 insertions(+), 81 deletions(-) >> cr
Re: [Qemu-devel] release retrospective, next release timing, numbering
On Fri, 27 Apr 2018 16:51:03 +0100 Peter Maydell wrote: > Hi; I usually let people forget about releases for a month or > so before bringing this topic up, but: > > (1) do we want to call the next release 2.13, or something else? > There's no particular reason to bump to 3.0 except some combination of > * if we keep going like this we'll get up to 2.42, which starts to >get silly > * Linus-style "avoid being too predictable" > * triskaidekaphobia > but maybe we should anyway? > Do we care for machine versions to stick to QEMU versions ? I ask, because we've already added a pseries-2.13 machine type (in master since David's latest pull req). No big deal though if we have to turn it into pseries-3.0 I guess... > (2) release timing: > * usual schedule would give us a next release mid-to-late August > * unless I can persuade Stefan to do the release management this >cycle we might need to wind that in by a couple of weeks so >it's definitely done by the middle of August, to avoid a clash >with a personal commitment > * so probably hardfreeze 10th July, softfreeze 3rd July > > (3) retrospective, lessons learned &c > * please remember that if every single submaintainer submits >a pull request on the morning of an RC, it is physically >not possible for me to process all those pulls in time to >tag the RC that day. We had several RCs which got delayed >by a day because of this; please try to submit earlier >rather than later... > * provide your opinions here ? > > thanks > -- PMM >
Re: [Qemu-devel] [PATCH v6 1/2] Implement .hex file loader
On Thu, Apr 26, 2018 at 09:51:37PM +0800, Su Hang wrote:
> if (arm_feature(&cpu->env, ARM_FEATURE_AARCH64) && kernel_size < 0) {
> kernel_size = load_aarch64_image(info->kernel_filename,
> info->loader_start, &entry, as);
> is_linux = 1;
> -} else if (kernel_size < 0) {
> -/* 32-bit ARM */
> +}
> +if (kernel_size < 0) {
> +/* 32-bit ARM binary file */
> entry = info->loader_start + KERNEL_LOAD_ADDR;
> -kernel_size = load_image_targphys_as(info->kernel_filename, entry,
> - info->ram_size -
> KERNEL_LOAD_ADDR,
> - as);
> +kernel_size =
> +load_image_targphys_as(info->kernel_filename, entry,
> + info->ram_size - KERNEL_LOAD_ADDR, as);
These changes seem unnecessary.
> +/* return 0 or -1 if error */
> +static size_t parse_record(HexLine *line, uint8_t *our_checksum,
size_t is unsigned, so returning -1 is not ideal. This function only
needs to return success or failure. Please use bool instead.
> +typedef struct {
> +const char *filename;
> +HexLine line;
> +uint8_t *bin_buf;
> +hwaddr *addr;
> +size_t total_size;
Please use int instead of size_t since this is the return value from
load_image_hex_as().
> +uint32_t next_address_to_write;
> +uint32_t current_address;
> +uint32_t current_rom_index;
> +uint32_t rom_start_address;
> +AddressSpace *as;
> +} HexParser;
> +
> +/* return size or -1 if error */
> +static size_t handle_record_type(HexParser *parser)
Please use int instead of size_t (see above for reasons).
> +{
> +HexLine *line = &(parser->line);
> +switch (line->record_type) {
> +case DATA_RECORD:
> +parser->current_address =
> +(parser->next_address_to_write & 0x) | line->address;
> +/* verify this is a contiguous block of memory */
> +if (parser->current_address != parser->next_address_to_write) {
> +if (parser->current_rom_index != 0) {
> +rom_add_hex_blob_as(parser->filename, parser->bin_buf,
> +parser->current_rom_index,
> +parser->rom_start_address, parser->as);
> +}
> +parser->rom_start_address = parser->current_address;
> +parser->current_rom_index = 0;
> +}
> +
> +/* copy from line buffer to output bin_buf */
> +memcpy(parser->bin_buf + parser->current_rom_index, line->data,
> + line->byte_count);
> +parser->current_rom_index += line->byte_count;
> +parser->total_size += line->byte_count;
> +/* save next address to write */
> +parser->next_address_to_write =
> +parser->current_address + line->byte_count;
> +break;
> +
> +case EOF_RECORD:
> +if (parser->current_rom_index != 0) {
> +rom_add_hex_blob_as(parser->filename, parser->bin_buf,
> +parser->current_rom_index,
> +parser->rom_start_address, parser->as);
> +}
> +return parser->total_size;
> +case EXT_SEG_ADDR_RECORD:
> +case EXT_LINEAR_ADDR_RECORD:
> +if (line->byte_count != 2 && line->address != 0) {
> +return -1;
> +}
> +
> +if (parser->current_rom_index != 0) {
> +rom_add_hex_blob_as(parser->filename, parser->bin_buf,
> +parser->current_rom_index,
> +parser->rom_start_address, parser->as);
> +}
> +
> +/* save next address to write,
> + * in case of non-contiguous block of memory */
> +parser->next_address_to_write =
> +line->record_type == EXT_SEG_ADDR_RECORD
> +? ((line->data[0] << 12) | (line->data[1] << 4))
> +: ((line->data[0] << 24) | (line->data[1] << 16));
> +parser->rom_start_address = parser->next_address_to_write;
> +parser->current_rom_index = 0;
> +break;
> +
> +case START_SEG_ADDR_RECORD:
START_SEG_ADDR_RECORD is x86-specific and not implemented by this patch
(the address is given in CS:IP real-mode addressing format and you would
need to calculate the linear address). Please return an error if this
record type is encountered.
> +case START_LINEAR_ADDR_RECORD:
Please check that byte_count == 4 and address == 0.
> +*(parser->addr) = (line->data[0] << 24) | (line->data[1] << 16) |
> + (line->data[2] << 8) | (line->data[3]);
Please name the field start_addr so its purpose is clear.
> +break;
> +
> +default:
> +return -1;
> +}
> +
> +return parser->total_size;
> +}
> +
> +/* return size or -1 if error */
> +static size_t parse_hex_blob(const char *filename, hwaddr *
Re: [Qemu-devel] [RFC PATCH v2 00/19] reverse debugging
Did you manage to reproduce and solve the savevm and loadvm problems I mentioned at: http://lists.nongnu.org/archive/html/qemu-devel/2018-04/msg05219.html ? I still observe them on the current patch. On Sat, Apr 28, 2018 at 1:36 PM, Pavel Dovgalyuk wrote: > GDB remote protocol supports reverse debugging of the targets. > It includes 'reverse step' and 'reverse continue' operations. > The first one finds the previous step of the execution, > and the second one is intended to stop at the last breakpoint that > would happen when the program is executed normally. > > Reverse debugging is possible in the replay mode, when at least > one snapshot was created at the record or replay phase. > QEMU can use these snapshots for travelling back in time with GDB. > > Running the execution in replay mode allows using GDB reverse debugging > commands: > - reverse-stepi (or rsi): Steps one instruction to the past. >QEMU loads on of the prior snapshots and proceeds to the desired >instruction forward. When that step is reaches, execution stops. > - reverse-continue (or rc): Runs execution "backwards". >QEMU tries to find breakpoint or watchpoint by loaded prior snapshot >and replaying the execution. Then QEMU loads snapshots again and >replays to the latest breakpoint. When there are no breakpoints in >the examined section of the execution, QEMU finds one more snapshot >and tries again. After the first snapshot is processed, execution >stops at this snapshot. > > The set of patches include the following modifications: > - gdbstub update for reverse debugging support > - functions that automatically perform reverse step and reverse >continue operations > - hmp/qmp commands for manipulating the replay process > - improvement of the snapshotting for saving the execution step >in the snapshot parameters > - other record/replay fixes > > The patches are available in the repository: > https://github.com/ispras/qemu/tree/rr-180428 > > v2 changes: > - documented reverse debugging > - fixed start vmstate loading in record mode > - documented qcow2 changes (as suggested by Eric Blake) > - made icount SnapshotInfo field optional (as suggested by Eric Blake) > - renamed qmp commands (as suggested by Eric Blake) > - minor changes > > --- > > Pavel Dovgalyuk (19): > block: implement bdrv_snapshot_goto for blkreplay > replay: disable default snapshot for record/replay > replay: update docs for record/replay with block devices > replay: don't drain/flush bdrv queue while RR is working > replay: finish record/replay before closing the disks > qcow2: introduce icount field for snapshots > migration: introduce icount field for snapshots > replay: introduce info hmp/qmp command > replay: introduce breakpoint at the specified step > replay: implement replay-seek command to proceed to the desired step > replay: flush events when exitting > timer: remove replay clock probe in deadline calculation > replay: refine replay-time module > translator: fix breakpoint processing > replay: flush rr queue before loading the vmstate > gdbstub: add reverse step support in replay mode > gdbstub: add reverse continue support in replay mode > replay: describe reverse debugging in docs/replay.txt > replay: allow loading any snapshots before recording > > > accel/tcg/translator.c|8 + > block/blkreplay.c |8 + > block/io.c| 22 +++ > block/qapi.c | 17 ++- > block/qcow2-snapshot.c|9 + > block/qcow2.h |2 > blockdev.c| 10 ++ > cpus.c| 19 ++- > docs/interop/qcow2.txt|4 + > docs/replay.txt | 45 +++ > exec.c|6 + > gdbstub.c | 50 +++- > hmp-commands-info.hx | 14 ++ > hmp-commands.hx | 30 + > hmp.h |3 > include/block/snapshot.h |1 > include/sysemu/replay.h | 18 +++ > migration/savevm.c| 15 +- > qapi/block-core.json |5 + > qapi/block.json |3 > qapi/misc.json| 68 +++ > replay/Makefile.objs |3 > replay/replay-debugging.c | 287 > + > replay/replay-events.c| 14 -- > replay/replay-internal.h | 10 +- > replay/replay-snapshot.c | 17 ++- > replay/replay-time.c | 27 ++-- > replay/replay.c | 22 +++ > stubs/replay.c| 10 ++ > util/qemu-timer.c | 11 -- > vl.c | 18 ++- > 31 files changed, 695 insertions(+), 81 deletions(-) > create mode 100644 replay/replay-debugging.c > > -- > Pavel Dovgalyuk
Re: [Qemu-devel] [PATCH v2 for 2.13] migration: Don't activate block devices if using -S
"Dr. David Alan Gilbert (git)" wrote:
> From: "Dr. David Alan Gilbert"
>
> Activating the block devices causes the locks to be taken on
> the backing file. If we're running with -S and the destination libvirt
> hasn't started the destination with 'cont', it's expecting the locks are
> still untaken.
I will try to change the naming, because we have:
- don't activate block device
- and we stop calling bdrv_invalidate_cache_all
i.e. behind the scenes bdrv_invalidate_cache activates a block device,
not bad O:-)
> Don't activate the block devices if we're not going to autostart the VM;
> 'cont' already will do that anyway. This change is tied to the new
> migration capability 'late-block-activate' that defaults to off, keeping
> the old behaviour by default.
I have read the old discussion, and we have:
- current patch (not call bdrv_invalidate_cache() at bottom_handler)
- kevin approach: create two commands
activate_devices/deactivate_devices and make libvirt use them correctly
I am not really sure which one is better, but as the patch author is
Dave
> bz: https://bugzilla.redhat.com/show_bug.cgi?id=1560854
> Signed-off-by: Dr. David Alan Gilbert
> ---
> migration/migration.c | 34 +++---
> qapi/migration.json | 6 +-
> 2 files changed, 32 insertions(+), 8 deletions(-)
Reviewed-by: Juan Quintela
> +# @late-block-activate: If enabled, the destination will not activate block
> +# devices (and thus take locks) immediately at the end of
> migration.
> +# (since 2.13)
> +#
> # Since: 1.2
> ##
> { 'enum': 'MigrationCapability',
>'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks',
> 'compress', 'events', 'postcopy-ram', 'x-colo', 'release-ram',
> 'block', 'return-path', 'pause-before-switchover', 'x-multifd',
> - 'dirty-bitmaps' ] }
> + 'dirty-bitmaps', 'late-block-activate' ] }
>
> ##
> # @MigrationCapabilityStatus:
Just wondering, is there a way to enable a capability for 2.13 and
newer, and not activate it for older versions? I *think* that this
feature should be on in new releases, and off by default with old
machine types. But I haven't through long enough to know what needs to
be changed.
Later, Juan.
[Qemu-devel] How to check if Vt-d is capable of posted-interrupt?
Hi, I wonder how to check if Vt-d is capable of posted-interrupt? I'm using Intel E5-2630 v3. I was once told that APICv and posted-interrupt capability always come together. But it seems like my cpu support APICv (/sys/module/kvm_intel/parameters/enable_apicv is Y), but posted-interrupt capability is only shipped with the next generation of the cpu (E5-2600 v4, which is Broadwell). What would be an easy way to check this? Thanks, Jintack
Re: [Qemu-devel] [PATCH v13 20/30] sdbus: add trace events
On Fri, Apr 27, 2018 at 12:55:21PM +0100, Peter Maydell wrote:
> On 13 February 2018 at 04:07, Philippe Mathieu-Daudé wrote:
> > Signed-off-by: Philippe Mathieu-Daudé
> > Reviewed-by: Alistair Francis
>
> > @@ -39,6 +45,7 @@ int sdbus_do_command(SDBus *sdbus, SDRequest *req,
> > uint8_t *response)
> > {
> > SDState *card = get_card(sdbus);
> >
> > +trace_sdbus_command(sdbus_name(sdbus), req->cmd, req->arg, req->crc);
> > if (card) {
> > SDCardClass *sc = SD_CARD_GET_CLASS(card);
>
> Hi -- as a result of this trace event being added, we now get
> warnings from Coverity that it might use uninitialized data
> (CID1386074, CID1390571, CID1386072, CID1386076). This is because not
> all of our SD
> controllers bother to initialize req->crc, because up til now
> nothing in the SD code looks at it. (I think at least bcm2835_sdhost.c
> sdhci.c and ssi-sd.c do this).
>
> Could you have a look at this, please? I think there are
> three plausible lines of approach:
>
> (1) just don't bother to trace the CRC field
> (2) make bcm2835_sdhost.c, sdhci.c, ssi-sd.c set crc to 0 like
> omap and pxa2xx already do
Hi,
Philippe, any opinion here?
Otherwise I suggest we do #2 right away to avoid the warnings
until someone cares enough to implement #3...
Cheers,
Edgar
> (3) "proper" implementation of CRC, so that an sd controller
> can either (a) mark the SDRequest as "no CRC" and have
> sd_req_crc_validate() always pass, or (b) mark the SDRequest
> as having a CRC and have sd_req_crc_validate() actually
> do the check which it currently stubs out with "return 0"
>
> (3 is because it doesn't seem very sensible to spend time
> calculating a CRC just to test it against a CRC calculated
> a little bit later on; but we don't really want to drop the
> CRC stuff entirely because on some controllers like
> milkymist-memcard.c the CRC byte comes from the guest and
> we'd ideally like to check it.)
>
> I don't have a strong preference for which of 1/2/3 we do.
>
> PS: CID1005332 is the coverity issue for "sd_req_crc_validate
> stubs out its check code with 'return 0' leaving a line of
> unreachable code".
>
> thanks
> -- PMM
Re: [Qemu-devel] [PATCH v1 1/2] xlnx-zdma: Add a model of the Xilinx ZynqMP generic DMA
On Sun, Apr 29, 2018 at 02:43:28AM +0200, Francisco Iglesias wrote: > Add a model of the generic DMA found on Xilinx ZynqMP. Hi Francisco, I think we need to look at the VMStateDescription, some state seems to be missing... Cheers, Edgar > > Signed-off-by: Francisco Iglesias > Signed-off-by: Edgar E. Iglesias > --- > hw/dma/Makefile.objs | 1 + > hw/dma/xlnx-zdma.c | 833 > + > include/hw/dma/xlnx-zdma.h | 84 + > 3 files changed, 918 insertions(+) > create mode 100644 hw/dma/xlnx-zdma.c > create mode 100644 include/hw/dma/xlnx-zdma.h > > diff --git a/hw/dma/Makefile.objs b/hw/dma/Makefile.objs > index c2afecbf73..79affecc39 100644 > --- a/hw/dma/Makefile.objs > +++ b/hw/dma/Makefile.objs > @@ -10,6 +10,7 @@ common-obj-$(CONFIG_ETRAXFS) += etraxfs_dma.o > common-obj-$(CONFIG_STP2000) += sparc32_dma.o > obj-$(CONFIG_XLNX_ZYNQMP) += xlnx_dpdma.o > obj-$(CONFIG_XLNX_ZYNQMP_ARM) += xlnx_dpdma.o > +common-obj-$(CONFIG_XLNX_ZYNQMP_ARM) += xlnx-zdma.o > > obj-$(CONFIG_OMAP) += omap_dma.o soc_dma.o > obj-$(CONFIG_PXA2XX) += pxa2xx_dma.o > diff --git a/hw/dma/xlnx-zdma.c b/hw/dma/xlnx-zdma.c > new file mode 100644 > index 00..7955a6116d > --- /dev/null > +++ b/hw/dma/xlnx-zdma.c > @@ -0,0 +1,833 @@ > +/* > + * QEMU model of the ZynqMP generic DMA > + * > + * Copyright (c) 2014 Xilinx Inc. > + * Copyright (c) 2018 FEIMTECH AB > + * > + * Written by Edgar E. Iglesias , > + *Francisco Iglesias > + * > + * 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/dma/xlnx-zdma.h" > +#include "qemu/bitops.h" > +#include "qemu/log.h" > +#include "qapi/error.h" > + > +#ifndef XLNX_ZDMA_ERR_DEBUG > +#define XLNX_ZDMA_ERR_DEBUG 0 > +#endif > + > +REG32(ZDMA_ERR_CTRL, 0x0) > +FIELD(ZDMA_ERR_CTRL, APB_ERR_RES, 0, 1) > +REG32(ZDMA_CH_ISR, 0x100) > +FIELD(ZDMA_CH_ISR, DMA_PAUSE, 11, 1) > +FIELD(ZDMA_CH_ISR, DMA_DONE, 10, 1) > +FIELD(ZDMA_CH_ISR, AXI_WR_DATA, 9, 1) > +FIELD(ZDMA_CH_ISR, AXI_RD_DATA, 8, 1) > +FIELD(ZDMA_CH_ISR, AXI_RD_DST_DSCR, 7, 1) > +FIELD(ZDMA_CH_ISR, AXI_RD_SRC_DSCR, 6, 1) > +FIELD(ZDMA_CH_ISR, IRQ_DST_ACCT_ERR, 5, 1) > +FIELD(ZDMA_CH_ISR, IRQ_SRC_ACCT_ERR, 4, 1) > +FIELD(ZDMA_CH_ISR, BYTE_CNT_OVRFL, 3, 1) > +FIELD(ZDMA_CH_ISR, DST_DSCR_DONE, 2, 1) > +FIELD(ZDMA_CH_ISR, SRC_DSCR_DONE, 1, 1) > +FIELD(ZDMA_CH_ISR, INV_APB, 0, 1) > +REG32(ZDMA_CH_IMR, 0x104) > +FIELD(ZDMA_CH_IMR, DMA_PAUSE, 11, 1) > +FIELD(ZDMA_CH_IMR, DMA_DONE, 10, 1) > +FIELD(ZDMA_CH_IMR, AXI_WR_DATA, 9, 1) > +FIELD(ZDMA_CH_IMR, AXI_RD_DATA, 8, 1) > +FIELD(ZDMA_CH_IMR, AXI_RD_DST_DSCR, 7, 1) > +FIELD(ZDMA_CH_IMR, AXI_RD_SRC_DSCR, 6, 1) > +FIELD(ZDMA_CH_IMR, IRQ_DST_ACCT_ERR, 5, 1) > +FIELD(ZDMA_CH_IMR, IRQ_SRC_ACCT_ERR, 4, 1) > +FIELD(ZDMA_CH_IMR, BYTE_CNT_OVRFL, 3, 1) > +FIELD(ZDMA_CH_IMR, DST_DSCR_DONE, 2, 1) > +FIELD(ZDMA_CH_IMR, SRC_DSCR_DONE, 1, 1) > +FIELD(ZDMA_CH_IMR, INV_APB, 0, 1) > +REG32(ZDMA_CH_IEN, 0x108) > +FIELD(ZDMA_CH_IEN, DMA_PAUSE, 11, 1) > +FIELD(ZDMA_CH_IEN, DMA_DONE, 10, 1) > +FIELD(ZDMA_CH_IEN, AXI_WR_DATA, 9, 1) > +FIELD(ZDMA_CH_IEN, AXI_RD_DATA, 8, 1) > +FIELD(ZDMA_CH_IEN, AXI_RD_DST_DSCR, 7, 1) > +FIELD(ZDMA_CH_IEN, AXI_RD_SRC_DSCR, 6, 1) > +FIELD(ZDMA_CH_IEN, IRQ_DST_ACCT_ERR, 5, 1) > +FIELD(ZDMA_CH_IEN, IRQ_SRC_ACCT_ERR, 4, 1) > +FIELD(ZDMA_CH_IEN, BYTE_CNT_OVRFL, 3, 1) > +FIELD(ZDMA_CH_IEN, DST_DSCR_DONE, 2, 1) > +FIELD(ZDMA_CH_IEN, SRC_DSCR_DONE, 1, 1) > +FIELD(ZDMA_CH_IEN, INV_APB, 0, 1) > +REG32(ZDMA_CH_IDS, 0x10c) > +FIELD(ZDMA_CH_IDS, DMA_PAUSE, 11, 1) > +FIELD(ZDMA_CH_IDS, DMA_DONE, 10, 1) > +FIELD(ZDMA_CH_IDS, AXI_WR_DATA, 9, 1) > +FIELD(ZDMA_CH_IDS, AXI_RD_DATA, 8, 1) > +FIELD(ZDMA_CH_IDS, AXI_RD_DST_DSCR, 7, 1) > +FIELD(ZDMA_CH_
Re: [Qemu-devel] [PATCH v2 0/5] checkpatch: backport UTF-8 fixes and MAINTAINERS check
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20180430124651.10340-1-stefa...@redhat.com
Subject: [Qemu-devel] [PATCH v2 0/5] checkpatch: backport UTF-8 fixes and
MAINTAINERS check
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done
exit $failed
=== TEST SCRIPT END ===
Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
t [tag update]patchew/20180421163957.29872-1-mre...@redhat.com ->
patchew/20180421163957.29872-1-mre...@redhat.com
* [new tag] patchew/20180430124651.10340-1-stefa...@redhat.com
-> patchew/20180430124651.10340-1-stefa...@redhat.com
Switched to a new branch 'test'
19015a6f3e checkpatch: reduce MAINTAINERS update message frequency
7fb20f970d checkpatch: emit a warning on file add/move/delete
9303812d85 checkpatch: ignore email headers better
f7cec089ae checkpatch: check utf-8 content from a commit log when it's missing
from charset
d6a1291e63 checkpatch: add a --strict check for utf-8 in commit logs
=== OUTPUT BEGIN ===
Checking PATCH 1/5: checkpatch: add a --strict check for utf-8 in commit logs...
WARNING: line over 80 characters
#101: FILE: scripts/checkpatch.pl:1420:
+ WARN("8-bit UTF-8 used in possible commit log\n" .
$herecurr);
total: 0 errors, 1 warnings, 66 lines checked
Your patch has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Checking PATCH 2/5: checkpatch: check utf-8 content from a commit log when it's
missing from charset...
Checking PATCH 3/5: checkpatch: ignore email headers better...
Checking PATCH 4/5: checkpatch: emit a warning on file add/move/delete...
WARNING: line over 80 characters
#46: FILE: scripts/checkpatch.pl:1397:
+($line =~ /\{\s*([\w\/\.\-]*)\s*\=\>\s*([\w\/\.\-]*)\s*\}/
&&
ERROR: line over 90 characters
#49: FILE: scripts/checkpatch.pl:1400:
+ WARN("added, moved or deleted file(s), does MAINTAINERS
need updating?\n" . $herecurr);
total: 1 errors, 1 warnings, 24 lines checked
Your patch has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Checking PATCH 5/5: checkpatch: reduce MAINTAINERS update message frequency...
=== OUTPUT END ===
Test command exited with code: 1
---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@redhat.com
[Qemu-devel] KVM call for 2018 - 05 - 08
Hi Please, send any topic that you are interested in covering. At the end of Monday 07, I will send an email with the agenda or the cancellation of the call, so hurry up. Call details: By popular demand, a google calendar public entry with it https://www.google.com/calendar/embed?src=dG9iMXRqcXAzN3Y4ZXZwNzRoMHE4a3BqcXNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ (Let me know if you have any problems with the calendar entry. I just gave up about getting right at the same time CEST, CET, EDT and DST). If you need phone number details, contact me privately Thanks, Juan.
Re: [Qemu-devel] [PATCH] memory.h: Improve IOMMU related documentation
On 30 April 2018 at 14:08, Paolo Bonzini wrote: > On 30/04/2018 14:57, Peter Maydell wrote: >> On 30 April 2018 at 13:54, Paolo Bonzini wrote: >>> On 30/04/2018 14:24, Peter Maydell wrote: -/* Set this up to provide customized IOMMU replay function */ +/* Set this up to provide customized IOMMU replay function. + * Optional method. + */ void (*replay)(IOMMUMemoryRegion *iommu, IOMMUNotifier *notifier); >>> >>> replay is needed if you want to support IOMMU notifiers. After >>> memory_region_register_iommu_notifier you're only notified about future >>> changes to the mappings; memory_region_iommu_replay calls the replay >>> method so that the IOMMUNotifier is called for each existing mapping. >> >> Is it then unrelated to record-and-replay ? That's what I guessed >> it was for... Also, some IOMMUs (eg spapr_iommu.c) seem to support >> notifiers but don't implement it. > > Yes, it's completely unrelated. I have no idea why spapr_iommu.c > doesn't need it, so I am CCing the sPAPR and VFIO experts... There does seem to be a default implementation in memory_region_iommu_replay(), maybe that is sufficient for spapr? thanks -- PMM
