[Qemu-devel] Large patch set advice

Greetings, 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

[Qemu-devel] [Bug 1766896] Re: qemu-system-arm segfault in arm_v7m_mmu_idx_for_secstate

Yes; cortex-m3 will only work on machine types that are expecting it (ie which instantiate the M profile NVIC interrupt controller, which is really an integral part of the CPU). We should catch this case and make QEMU exit with a more helpful message. -- You received this bug notification

Re: [Qemu-devel] [PATCH 5/6] qapi: extract CpuInfoCommon to mitigate schema duplication

On 04/25/2018 08:20 AM, Laszlo Ersek wrote: > ... > > and people would ask themselves ever after, "are there some common > fields in there that we could extract ... hmmm, @props and @arch, okay, > maybe, maybe not, grey area". Let's do it now and save them the thinking. No, CpuInfo is slated

Re: [Qemu-devel] [PATCH 3/6] qapi: add SysEmuTarget to "common.json"

On 04/25/2018 02:05 PM, Laszlo Ersek wrote: + 'x86_64', 'xtensa', 'xtensaeb' ] } >>> >>> x86_64 doesn't match our typical conventions of preferring '-' over '_'; >>> also, wikipedia mentions both spellings but under the page name >>> 'x86-64'. Is it worth switching that enum

Re: [Qemu-devel] [RFC PATCH 10/17] replay: implement replay_seek command to proceed to the desired step

On 04/25/2018 07:46 AM, Pavel Dovgalyuk wrote: > This patch adds hmp/qmp command replay_seek which proceeds the execution > to the specified step. > It automatically loads nearest snapshot and replays the execution to find > the desired step. > > Signed-off-by: Pavel Dovgalyuk

Re: [Qemu-devel] [RFC PATCH 09/17] replay: introduce breakpoint at the specified step

On 04/25/2018 07:46 AM, Pavel Dovgalyuk wrote: > This patch introduces replay_break qmp and hmp commands. > These commands allow stopping at the specified instruction. > It may be useful for debugging when there are some known > events that should be investigated. > The commands have one argument

Re: [Qemu-devel] [RFC PATCH 08/17] replay: introduce info hmp/qmp command

On 04/25/2018 07:46 AM, Pavel Dovgalyuk wrote: > This patch introduces 'info replay' monitor command and > corresponding qmp request. > These commands request the current record/replay mode, replay log file name, > and the execution step (number or recorded/replayed instructions). > >

Re: [Qemu-devel] [PATCH 3/6] qapi: add SysEmuTarget to "common.json"

On 04/25/18 14:54, Daniel P. Berrangé wrote: > On Tue, Apr 24, 2018 at 06:11:05PM -0500, Eric Blake wrote: >> On 04/24/2018 04:45 PM, Laszlo Ersek wrote: >>> We'll soon need an enumeration type that lists all the softmmu targets >>> that QEMU (the project) supports. Introduce @SysEmuTarget to >>>

Re: [Qemu-devel] [RFC PATCH 07/17] qcow2: introduce icount field for snapshots

On 04/25/2018 07:46 AM, Pavel Dovgalyuk wrote: > This patch introduces the icount field for saving within the snapshot. > It is required for navigation between the snapshots in record/replay mode. > > Signed-off-by: Pavel Dovgalyuk > --- > block/qcow2-snapshot.c |9

Re: [Qemu-devel] [RFC PATCH 06/17] migration: introduce icount field for snapshots

On 04/25/2018 07:46 AM, Pavel Dovgalyuk wrote: > Saving icount as a parameters of the snapshot allows navigation between > them in the execution replay scenario. > This information can be used for finding a specific snapshot for rewinding > the recorded execution to the specific moment of the

Re: [Qemu-devel] [PATCH 0/8] block: more byte-based cleanups: vectored I/O

On 04/25/2018 01:19 PM, Eric Blake wrote: > In my continuing quest to nuke pointless sector-based interfaces, > here's another round of cleanups. I spent some time on qcow, > then was appalled at how long iotests took to prove that it did > not regress; so for parallels, replication, and vhdx,

[Qemu-devel] [PATCH 8/8] block: Removed unused sector-based vectored I/O

We are gradually moving away from sector-based interfaces, towards byte-based. Now that all callers of vectored I/O have been converted to use our preferred byte-based bdrv_co_p{read,write}v(), we can delete the unused bdrv_co_{read,write}v(). Furthermore, this gets rid of the signature

Re: [Qemu-devel] [PATCH v5 5/5] qcow2: Avoid memory over-allocation on compressed images

On 04/25/2018 10:00 AM, Max Reitz wrote: > On 2018-04-24 00:33, Eric Blake wrote: >> When reading a compressed image, we were allocating s->cluster_data >> to 32*cluster_size + 512 (possibly over 64 megabytes, for an image >> with 2M clusters). Let's check out the history: >> >> >> So, it's time

[Qemu-devel] [PATCH 1/8] parallels: Switch to byte-based calls

We are gradually moving away from sector-based interfaces, towards byte-based. Make the change for the last few sector-based calls into the block layer from the parallels driver. Ideally, the parallels driver should switch to doing everything byte-based, but that's a more invasive change that

[Qemu-devel] [PATCH 7/8] vhdx: Switch to byte-based calls

We are gradually moving away from sector-based interfaces, towards byte-based. Make the change for the last few sector-based calls into the block layer from the vhdx driver. Ideally, the vhdx driver should switch to doing everything byte-based, but that's a more invasive change that requires a

[Qemu-devel] [PATCH 2/8] qcow: Switch get_cluster_offset to be byte-based

We are gradually moving away from sector-based interfaces, towards byte-based. Make the change for the internal helper function get_cluster_offset(), by changing n_start and n_end to by byte offsets rather than sector indices within the cluster being allocated. A later patch will then switch the

[Qemu-devel] [PATCH 3/8] qcow: Switch qcow_co_readv to byte-based calls

We are gradually moving away from sector-based interfaces, towards byte-based. Make the change for the internals of the qcow driver read function, by iterating over offset/bytes instead of sector_num/nb_sectors, and repurposing index_in_cluster and n to be bytes instead of sectors. A later patch

[Qemu-devel] [PATCH 5/8] qcow: Switch to a byte-based driver

We are gradually moving away from sector-based interfaces, towards byte-based. The qcow driver is now ready to fully utilize the byte-based callback interface, as long as we override the default alignment to still be 512 (needed at least for encryption, but easier to do everywhere than to audit

[Qemu-devel] [PATCH 4/8] qcow: Switch qcow_co_writev to byte-based calls

We are gradually moving away from sector-based interfaces, towards byte-based. Make the change for the internals of the qcow driver write function, by iterating over offset/bytes instead of sector_num/nb_sectors, and repurposing index_in_cluster and n to be bytes instead of sectors. A later

[Qemu-devel] [PATCH 6/8] replication: Switch to byte-based calls

We are gradually moving away from sector-based interfaces, towards byte-based. Make the change for the last few sector-based calls into the block layer from the replication driver. Ideally, the replication driver should switch to doing everything byte-based, but that's a more invasive change

[Qemu-devel] [PATCH 0/8] block: more byte-based cleanups: vectored I/O

Based-on: <20180424192506.149089-1-ebl...@redhat.com> ([PATCH v2 0/6] block: byte-based AIO read/write) Based-on: <20180424220157.177385-1-ebl...@redhat.com> ([PATCH] block: Merge .bdrv_co_writev{, _flags} in drivers) My quest continues. I spent some time pruning qcow down as far as possible

[Qemu-devel] [Bug 1766904] Re: Creating high hdd load (with constant fsyncs) on a SATA disk leads to freezes and errors in guest dmesg

Relevant bits appear to be: -M pc-i1440fx-2.8 -cpu IvyBridge -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -device ahci,id=sata0,bus=pci.0,addr=0x7 -drive file=/home/user/data/work/virt-images/myvm.local.qcow2,format=qcow2,if=none,id=drive-sata0-0-0 -device

Re: [Qemu-devel] [PATCH] acpi/nvdimm: remove forward name references

>> > Good to know, thanks. > > I have made a big mistake. I was comparing the resulting SSDT of this patch > to an SSDT > Generated by a much older version of kvm/qemu. The latest kvm/qemu upstream > builds > the SSDT with the operation region contained inside of methods. This should > resolve

Re: [Qemu-devel] [PATCH v5 4/5] qcow2: Don't allow overflow during cluster allocation

On 04/25/2018 09:44 AM, Max Reitz wrote: > On 2018-04-24 00:33, Eric Blake wrote: >> Our code was already checking that we did not attempt to >> allocate more clusters than what would fit in an INT64 (the >> physical maximimum if we can access a full off_t's worth of s/maximimum/maximum/ >>

[Qemu-devel] [PATCH 0/8] block: more byte-based cleanups: vectored I/O

In my continuing quest to nuke pointless sector-based interfaces, here's another round of cleanups. I spent some time on qcow, then was appalled at how long iotests took to prove that it did not regress; so for parallels, replication, and vhdx, I'll leave any further cleanups within those files

Re: [Qemu-devel] Filtering files passing through MTP devices

What would be a simpler way to do this so that the guest machine would still be able to recognize the USB drive? Right now we're triggering a script whenever udev recognizes that a USB drive is plugged in. The script copies the allowed files to a certain folder. The guest has a cron job that

Re: [Qemu-devel] [PATCH 5/6] qapi: extract CpuInfoCommon to mitigate schema duplication

Laszlo Ersek writes: > On 04/25/18 09:06, Markus Armbruster wrote: >> Laszlo Ersek writes: >> >>> @CpuInfo and @CpuInfoFast duplicate the following four fields: @qom-path, >>> @thread-id, @props and @arch. From these, extract the first three to a >>>

[Qemu-devel] [Bug 1766896] [NEW] qemu-system-arm segfault in arm_v7m_mmu_idx_for_secstate

Public bug reported: Attempting to emulate some baremetal ARM cortex-M* firmware with gdb causes a segfault every time. qemu invocation: qemu-system-arm -machine none -cpu cortex-m3 -nographic -monitor null -serial null -s -S -device loader,file=firmware.elf qemu seems to startup fine with

[Qemu-devel] [Bug 1766896] Re: qemu-system-arm segfault in arm_v7m_mmu_idx_for_secstate

follow-up to IRC discussions with stsquad and danpb : the problem is "-machine none" which prevents all the data structures from being initialized properly. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

Re: [Qemu-devel] [PATCH v3 00/10] migration: improve and cleanup compression

* guangrong.x...@gmail.com (guangrong.x...@gmail.com) wrote: > From: Xiao Guangrong > Queued. > Changelog in v3: > Following changes are from Peter's review: > 1) use comp_param[i].file and decomp_param[i].compbuf to indicate if >the thread is properly init'd or

Re: [Qemu-devel] [PATCH v3 03/46] configure: add support for --cross-cc-FOO

On 24 April 2018 at 16:23, Alex Bennée wrote: > This allows us to specify cross compilers for our guests. This is > useful for building test images/programs. Currently we re-run the > compile test for each target. I couldn't think of a way to cache the > value for a given

Re: [Qemu-devel] [PATCH v2 0/6] postcopy block time calculation + ppc32 build fix

* Dr. David Alan Gilbert (dgilb...@redhat.com) wrote: > * Alexey Perevalov (a.pereva...@samsung.com) wrote: > > V1-V2 > > accidentally appeared __nocheck after rebase > > this patch set also rebased after latest pull request > > > > This patch set includes patches which were reverted by

Re: [Qemu-devel] [PATCH] acpi/nvdimm: remove forward name references

> -Original Message- > From: Igor Mammedov [mailto:imamm...@redhat.com] > Sent: Wednesday, April 25, 2018 8:32 AM > To: Michael S. Tsirkin > Cc: Schmauss, Erik ; qemu-devel@nongnu.org; Xiao > Guangrong ; Williams,

Re: [Qemu-devel] [PATCH v3 03/46] configure: add support for --cross-cc-FOO

On 04/24/2018 12:23 PM, Alex Bennée wrote: > This allows us to specify cross compilers for our guests. This is > useful for building test images/programs. Currently we re-run the > compile test for each target. I couldn't think of a way to cache the > value for a given arch without getting messier

Re: [Qemu-devel] [PATCH 03/10] intel-iommu: add iommu lock

On Wed, Apr 25, 2018 at 12:51:22 +0800, Peter Xu wrote: > Add a per-iommu big lock to protect IOMMU status. Currently the only > thing to be protected is the IOTLB cache, since that can be accessed > even without BQL, e.g., in IO dataplane. Is the added lock going to protect anything else beyond

Re: [Qemu-devel] Filtering files passing through MTP devices

Omer Katz writes: > We're connecting USB drives that we want the guests to copy files from. > The user should only be allowed to copy certain files into the system. > The same thing goes for copying files to the USB drive. We only allow > certain files to be exported from

Re: [Qemu-devel] [RFC for-2.13 0/7] spapr: Clean up pagesize handling

On Fri, 2018-04-20 at 20:21 +1000, David Gibson wrote: > On Fri, Apr 20, 2018 at 11:31:10AM +0200, Andrea Bolognani wrote: > > Is the 16 MiB page size available for both POWER8 and POWER9? > > No. That's a big part of what makes this such a mess. HPT has 16MiB > and 16GiB hugepages, RPT has

Re: [Qemu-devel] [PATCH v3 2/3] pc-bios/s390-ccw/net: Use diag308 to reset machine before jumping to the OS

On 04/25/2018 05:36 PM, Thomas Huth wrote: > On 25.04.2018 14:44, Christian Borntraeger wrote: >> >> >> On 04/25/2018 02:41 PM, Christian Borntraeger wrote: >>> You load from address 0. >>> >>> On 04/25/2018 02:34 PM, Thomas Huth wrote: On 25.04.2018 14:18, Christian Borntraeger wrote:

[Qemu-devel] [Bug 1766896] Re: qemu-system-arm segfault in arm_v7m_mmu_idx_for_secstate

You also did not specify any amount of RAM with the -m parameter and the "none" machine does not have any RAM by default. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1766896 Title:

[Qemu-devel] [Bug 1763536] Re: go build fails under qemu-ppc64le-static (qemu-user)

Thanks for the update, I will test that version and report back ( it may be a few days) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1763536 Title: go build fails under qemu-ppc64le-static

Re: [Qemu-devel] [RFC PATCH] hw/core: expand description of null-machine

On 25.04.2018 17:33, Alex Bennée wrote: > People following old instructions for QEMU get the message "No machine > specified, and there is no default" and run -machine help to pick a > new machine. Lay people might consider the null-machine to be such a > basic starting point but they won't get

Re: [Qemu-devel] [PATCH v3 1/3] pc-bios/s390-ccw/net: Split up net_load() into init, load and uninit parts

On 04/25/2018 05:08 AM, Thomas Huth wrote: When we want to support pxelinux-style network booting later, we've got to do several TFTP transfers - and we do not want to apply for a new IP address via DHCP each time. So split up net_load into three parts: 1. net_init(), which initializes

Re: [Qemu-devel] [PATCH v3 2/3] pc-bios/s390-ccw/net: Use diag308 to reset machine before jumping to the OS

On 04/25/2018 05:36 PM, Thomas Huth wrote: > On 25.04.2018 14:44, Christian Borntraeger wrote: >> >> >> On 04/25/2018 02:41 PM, Christian Borntraeger wrote: >>> You load from address 0. >>> >>> On 04/25/2018 02:34 PM, Thomas Huth wrote: On 25.04.2018 14:18, Christian Borntraeger wrote:

Re: [Qemu-devel] [PATCH 07/13] Change references to serial_hds[] to serial_hd()

On 25 April 2018 at 15:54, Philippe Mathieu-Daudé wrote: > Hi Peter, > > On 04/20/2018 11:52 AM, Peter Maydell wrote: >> Change all the uses of serial_hds[] to go via the new >> serial_hd() function. Code change produced with: >> find hw -name '*.[ch]' | xargs sed -i -e >>

Re: [Qemu-devel] [PATCH v3 45/46] tests/Makefile.include: add [build|clean|check]-tcg targets

Philippe Mathieu-Daudé writes: > On 04/24/2018 08:13 PM, Philippe Mathieu-Daudé wrote: >> On 04/24/2018 12:24 PM, Alex Bennée wrote: >>> This will ensure all linux-user targets build their guest test >>> programs and ensure check-tcg will run the respective tests. >>> >>>

Re: [Qemu-devel] [PATCH v3 2/3] pc-bios/s390-ccw/net: Use diag308 to reset machine before jumping to the OS

On 25.04.2018 14:44, Christian Borntraeger wrote: > > > On 04/25/2018 02:41 PM, Christian Borntraeger wrote: >> You load from address 0. >> >> On 04/25/2018 02:34 PM, Thomas Huth wrote: >>> On 25.04.2018 14:18, Christian Borntraeger wrote: On 04/25/2018 11:08 AM, Thomas Huth wrote:

Re: [Qemu-devel] [PATCH v3 0/3] ipmi: Fix vmstate transfer

Hi, This series seems to have some coding style problems. See output below for more information: Type: series Message-id: 1524670052-28373-1-git-send-email-miny...@acm.org Subject: [Qemu-devel] [PATCH v3 0/3] ipmi: Fix vmstate transfer === TEST SCRIPT BEGIN === #!/bin/bash BASE=base n=1

[Qemu-devel] [RFC PATCH] hw/core: expand description of null-machine

People following old instructions for QEMU get the message "No machine specified, and there is no default" and run -machine help to pick a new machine. Lay people might consider the null-machine to be such a basic starting point but they won't get far. This leads to confusion, see

Re: [Qemu-devel] [PATCH] acpi/nvdimm: remove forward name references

On Wed, 25 Apr 2018 17:17:04 +0300 "Michael S. Tsirkin" wrote: > On Wed, Apr 25, 2018 at 03:49:38PM +0200, Igor Mammedov wrote: > > On Tue, 24 Apr 2018 21:06:37 +0300 > > "Michael S. Tsirkin" wrote: > > > > > On Tue, Apr 24, 2018 at 05:47:58PM +,

[Qemu-devel] [PATCH v3 3/3] ipmi: Use proper struct reference for BT vmstate

From: Corey Minyard The vmstate for isa_ipmi_bt was referencing into the bt structure, instead create a bt structure separate and use that. The version 1 of the BT transfer was fairly broken, if a migration occured during an IPMI operation, it is likely the migration would

[Qemu-devel] [PATCH v3 2/3] ipmi: Use proper struct reference for KCS vmstate

From: Corey Minyard The vmstate for isa_ipmi_kcs was referencing into the kcs structure, instead create a kcs structure separate and use that. There were also some issues in the state transfer. The inlen field was not being transferred, so if a transaction was in process

[Qemu-devel] [PATCH v3 1/3] vmstate: Add a VSTRUCT type

From: Corey Minyard The VMS_STRUCT has no way to specify which version of a structure to use. Add a type and a new field to allow the specific version of a structure to be used. Signed-off-by: Corey Minyard --- include/migration/vmstate.h | 45

[Qemu-devel] [PATCH v3 0/3] ipmi: Fix vmstate transfer

I was going to just re-send the previous versions of these, but after looking I realized it would have the same misuse of vmstate_register(), and I didn't have a way to work around it. I had already done the VMSTATE_VSTRUCT work earlier, so I merged that in. Changes from v2: * Added

Re: [Qemu-devel] [PATCH v3 3/3] pc-dimm: factor out address space logic into MemoryDevice code

On Wed, 25 Apr 2018 09:56:49 -0400 (EDT) Pankaj Gupta wrote: > > > > > > > > > > > >> + > > > > > >> +memory_region_add_subregion(>mr, addr - hpms->base, > > > > > >> mr); > > > > > > missing vmstate registration? > > > > > > > > > > Missed this one: To be

Re: [Qemu-devel] [PATCH 09/13] hw/char/exynos4210_uart.c: Remove unneeded handling of NULL chardev

Hi Thomas, On 04/25/2018 12:05 PM, Thomas Huth wrote: > On 20.04.2018 16:52, Peter Maydell wrote: >> The handling of NULL chardevs in exynos4210_uart_create() is now >> all unnecessary: we don't need to create 'null' chardevs, and we >> don't need to enforce a bounds check on serial_hd(). >> >>

[Qemu-devel] [Bug 1766904] Re: Creating high hdd load (with constant fsyncs) on a SATA disk leads to freezes and errors in guest dmesg

Copying command line into bug so we don't lose it: LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=spice /usr/bin/kvm -name guest=myvm.local,debug- threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-3-myvm.local

[Qemu-devel] [Bug 1766904] Re: Creating high hdd load (with constant fsyncs) on a SATA disk leads to freezes and errors in guest dmesg

** Description changed: After upgrading from qemu 2.10.0+dfsg-2 to 2.12~rc3+dfsg-2 (on debian sid host), centos 7 guest started to show freezes and ata errors in dmesg during hdd workloads with writing many small files and repeated fsyncs. Host kernel 4.15.0-3-amd64. Guest kernel

Re: [Qemu-devel] [PATCH 13/13] vl.c: new function max_serial_hds()

On 20.04.2018 16:52, Peter Maydell wrote: > Create a new function max_serial_hds() which returns the number of > serial ports defined by the user. This is needed only by spapr. > > This allows us to remove the MAX_SERIAL_PORTS define. > > Signed-off-by: Peter Maydell >

Re: [Qemu-devel] [PATCH 12/13] vl.c: Remove compile time limit on number of serial ports

On 20.04.2018 16:52, Peter Maydell wrote: > Instead of having a fixed sized global serial_hds[] array, > use a local dynamically reallocated one, so we don't have > a compile time limit on how many serial ports a system has. > > Signed-off-by: Peter Maydell > --- >

[Qemu-devel] [Bug 1766904] [NEW] Creating high hdd load (with constant fsyncs) on a SATA disk leads to freezes and errors in guest dmesg

Public bug reported: After upgrading from qemu 2.10.0+dfsg-2 to 2.12~rc3+dfsg-2 (on debian sid host), centos 7 guest started to show freezes and ata errors in dmesg during hdd workloads with writing many small files and repeated fsyncs. Host kernel 4.15.0-3-amd64. Guest kernel

Re: [Qemu-devel] [PATCH v5 5/5] qcow2: Avoid memory over-allocation on compressed images

On 2018-04-24 00:33, Eric Blake wrote: > When reading a compressed image, we were allocating s->cluster_data > to 32*cluster_size + 512 (possibly over 64 megabytes, for an image > with 2M clusters). Let's check out the history: > > Back when qcow2 was first written, we used s->cluster_data for >

Re: [Qemu-devel] [RFC v2 1/2] virtio: add pmem driver

> > On Wed, Apr 25, 2018 at 04:54:13PM +0530, Pankaj Gupta wrote: > > diff --git a/include/uapi/linux/virtio_ids.h > > b/include/uapi/linux/virtio_ids.h > > index 6d5c3b2..5ebd049 100644 > > --- a/include/uapi/linux/virtio_ids.h > > +++ b/include/uapi/linux/virtio_ids.h > > @@ -43,5 +43,6 @@ > >

Re: [Qemu-devel] [PATCH 10/13] serial-isa: Use MAX_ISA_SERIAL_PORTS instead of MAX_SERIAL_PORTS

On 20.04.2018 16:52, Peter Maydell wrote: > The ISA serial port handling in serial-isa.c imposes a limit > of 4 serial ports. This is because we only know of 4 IO port > and IRQ settings for them, and is unrelated to the generic > MAX_SERIAL_PORTS limit, though they happen to both be set at > 4

Re: [Qemu-devel] [PATCH 09/13] hw/char/exynos4210_uart.c: Remove unneeded handling of NULL chardev

On 04/20/2018 11:52 AM, Peter Maydell wrote: > The handling of NULL chardevs in exynos4210_uart_create() is now > all unnecessary: we don't need to create 'null' chardevs, and we > don't need to enforce a bounds check on serial_hd(). > > Signed-off-by: Peter Maydell

Re: [Qemu-devel] [PATCH v2 3/9] block: Add BDRV_REQ_WRITE_UNCHANGED flag

On 2018-04-25 16:33, Eric Blake wrote: > On 04/21/2018 08:29 AM, Max Reitz wrote: >> This flag signifies that a write request will not change the visible >> disk content. With this flag set, it is sufficient to have the >> BLK_PERM_WRITE_UNCHANGED permission instead of BLK_PERM_WRITE. >> >>

Re: [Qemu-devel] [PATCH 07/13] Change references to serial_hds[] to serial_hd()

Hi Peter, On 04/20/2018 11:52 AM, Peter Maydell wrote: > Change all the uses of serial_hds[] to go via the new > serial_hd() function. Code change produced with: > find hw -name '*.[ch]' | xargs sed -i -e > 's/serial_hds\[\([^]]*\)\]/serial_hd(\1)/g' > > Signed-off-by: Peter Maydell

Re: [Qemu-devel] [PATCH v11 16/17] hw/arm/smmuv3: IOTLB emulation

Hi Peter, On 04/17/2018 02:55 PM, Peter Maydell wrote: > On 12 April 2018 at 08:38, Eric Auger wrote: >> We emulate a TLB cache of size SMMU_IOTLB_MAX_SIZE=256. >> It is implemented as a hash table whose key is a combination >> of the 16b asid and 48b IOVA. >> >> Entries

Re: [Qemu-devel] [PATCH 09/13] hw/char/exynos4210_uart.c: Remove unneeded handling of NULL chardev

On 20.04.2018 16:52, Peter Maydell wrote: > The handling of NULL chardevs in exynos4210_uart_create() is now > all unnecessary: we don't need to create 'null' chardevs, and we > don't need to enforce a bounds check on serial_hd(). > > Signed-off-by: Peter Maydell > ---

Re: [Qemu-devel] [PATCH v5 4/5] qcow2: Don't allow overflow during cluster allocation

On 2018-04-24 00:33, Eric Blake wrote: > Our code was already checking that we did not attempt to > allocate more clusters than what would fit in an INT64 (the > physical maximimum if we can access a full off_t's worth of > data). But this does not catch smaller limits enforced by > various spots

Re: [Qemu-devel] [PATCH 05/13] hw/xtensa/xtfpga.c: Don't create "null" chardevs for serial devices

On 20.04.2018 16:52, Peter Maydell wrote: > Following commit 12051d82f004024, UART devices should handle > being passed a NULL pointer chardev, so we don't need to > create "null" backends in board code. Remove the code that > does this and updates serial_hds[]. > > Signed-off-by: Peter Maydell

Re: [Qemu-devel] [PATCH 08/13] Remove checks on MAX_SERIAL_PORTS that are just bounds checks

On 04/20/2018 11:52 AM, Peter Maydell wrote: > Remove checks on MAX_SERIAL_PORTS that were just checking whether > they were within bounds for the serial_hds[] array and falling > back to NULL if not. This isn't needed with the serial_hd() > function, which returns NULL for all indexes beyond what

Re: [Qemu-devel] [RFC v2] qemu: Add virtio pmem device

> > On 04/25/2018 06:24 AM, Pankaj Gupta wrote: > > This patch adds virtio-pmem Qemu device. > > > > This device presents memory address range > > information to guest which is backed by file > > backend type. It acts like persistent memory > > device for KVM guest. Guest can perform read > >

Re: [Qemu-devel] [PATCH 03/13] hw/mips/boston.c: Don't create "null" chardevs for serial devices

On 20.04.2018 16:52, Peter Maydell wrote: > Following commit 12051d82f004024, UART devices should handle > being passed a NULL pointer chardev, so we don't need to > create "null" backends in board code. Remove the code that > does this and updates serial_hds[]. > > Signed-off-by: Peter Maydell

Re: [Qemu-devel] [RFC v2] qemu: Add virtio pmem device

> > Hi, > > > > Compile failures are because Qemu 'Memory-Device changes' are not yet > > in qemu master. As mentioned in Qemu patch message patch is > > dependent on 'Memeory-device' patches by 'David Hildenbrand'. > > > On 04/25/2018 06:24 AM, Pankaj Gupta wrote: > > This PV device code is

Re: [Qemu-devel] [PATCH v2 0/9] block: Add COR filter driver

On 04/25/2018 07:18 AM, Max Reitz wrote: > On 2018-04-21 15:29, Max Reitz wrote: >> This series adds a copy-on-read block filter driver which works by >> simply setting the BDRV_REQ_COPY_ON_READ flag on write requests (and >> otherwise just passing everything through). >> > > Thanks for the

Re: [Qemu-devel] [PATCH 08/13] Remove checks on MAX_SERIAL_PORTS that are just bounds checks

On 20.04.2018 16:52, Peter Maydell wrote: > Remove checks on MAX_SERIAL_PORTS that were just checking whether > they were within bounds for the serial_hds[] array and falling > back to NULL if not. This isn't needed with the serial_hd() > function, which returns NULL for all indexes beyond what

Re: [Qemu-devel] [PATCH 06/13] vl.c: Provide accessor function serial_hd() for serial_hds[] array

On 20.04.2018 16:52, Peter Maydell wrote: > Provide an accessor function serial_hd() to return the Chardev > (if any) associated with the numbered serial port. This will > be used to replace direct accesses to the serial_hds[] array, > so that calling code doesn't need to care about the size of >

Re: [Qemu-devel] [RFC v2 1/2] virtio: add pmem driver

On Wed, Apr 25, 2018 at 04:54:13PM +0530, Pankaj Gupta wrote: > diff --git a/include/uapi/linux/virtio_ids.h b/include/uapi/linux/virtio_ids.h > index 6d5c3b2..5ebd049 100644 > --- a/include/uapi/linux/virtio_ids.h > +++ b/include/uapi/linux/virtio_ids.h > @@ -43,5 +43,6 @@ > #define

[Qemu-devel] [PATCH v2 2/5] migration: create a dedicated connection for rdma return path

If start a RDMA migration with postcopy enabled, the source qemu establish a dedicated connection for return path. Signed-off-by: Lidong Chen Signed-off-by: Dr. David Alan Gilbert --- migration/rdma.c | 94

Re: [Qemu-devel] [PATCH 04/13] hw/mips/mips_malta: Don't create "null" chardevs for serial devices

On 20.04.2018 16:52, Peter Maydell wrote: > Following commit 12051d82f004024, UART devices should handle > being passed a NULL pointer chardev, so we don't need to > create "null" backends in board code. Remove the code that > does this and updates serial_hds[]. > > Signed-off-by: Peter Maydell

Re: [Qemu-devel] [PATCH 07/13] Change references to serial_hds[] to serial_hd()

On 20.04.2018 16:52, Peter Maydell wrote: > Change all the uses of serial_hds[] to go via the new > serial_hd() function. Code change produced with: > find hw -name '*.[ch]' | xargs sed -i -e > 's/serial_hds\[\([^]]*\)\]/serial_hd(\1)/g' > > Signed-off-by: Peter Maydell

Re: [Qemu-devel] [PATCH 0/6] qapi: introduce the SysEmuTarget enumeration

On 04/25/2018 07:26 AM, Laszlo Ersek wrote: > On 04/25/18 00:03, no-re...@patchew.org wrote: >> 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. >

[Qemu-devel] [PATCH v2 1/5] migration: disable RDMA WRITE after postcopy started

RDMA WRITE operations are performed with no notification to the destination qemu, then the destination qemu can not wakeup. This patch disable RDMA WRITE after postcopy started. Signed-off-by: Lidong Chen --- migration/qemu-file.c | 8 ++-- migration/rdma.c |

Re: [Qemu-devel] [PATCH 17/19] uninorth: create new uninorth device

On 04/25/2018 03:58 AM, Mark Cave-Ayland wrote: > On 25/04/18 07:34, David Gibson wrote: >> On Wed, Apr 25, 2018 at 07:06:03AM +0100, Mark Cave-Ayland wrote: >>> On 06/04/18 06:33, Mark Cave-Ayland wrote: On 25/03/18 22:11, Mark Cave-Ayland wrote: > Just to follow up on this, I spent

Re: [Qemu-devel] [RFC v2 2/2] pmem: device flush over VIRTIO

> > On Wed, Apr 25, 2018 at 4:24 AM, Pankaj Gupta wrote: > > This patch adds functionality to perform > > flush from guest to hosy over VIRTIO > > when 'ND_REGION_VIRTIO'flag is set on > > nd_negion. Flag is set by 'virtio-pmem' > > driver. > > > > Signed-off-by: Pankaj

Re: [Qemu-devel] [PATCH 01/13] hw/char/serial: Allow disconnected chardevs

On 20.04.2018 16:52, Peter Maydell wrote: > Currently the serial.c realize code has an explicit check that it is not > connected to a disconnected backend (ie one with a NULL chardev). > This isn't what we want -- you should be able to create a serial device > even if it isn't attached to

Re: [Qemu-devel] [PATCH 02/13] hw/arm/fsl-imx*: Don't create "null" chardevs for serial devices

On 20.04.2018 16:52, Peter Maydell wrote: > Following commit 12051d82f004024, UART devices should handle > being passed a NULL pointer chardev, so we don't need to > create "null" backends in board code. Remove the code that > does this and updates serial_hds[]. > > (fsl-imx7.c was already

Re: [Qemu-devel] [PATCH v11 11/17] target/arm/kvm: Translate the MSI doorbell in kvm_arch_fixup_msi_route

Hi Peter, On 04/17/2018 01:02 PM, Peter Maydell wrote: > On 12 April 2018 at 08:38, Eric Auger wrote: >> In case the MSI is translated by an IOMMU we need to fixup the >> MSI route with the translated address. >> >> Signed-off-by: Eric Auger >>

[Qemu-devel] [PATCH v2 5/5] migration: Stop rdma yielding during incoming postcopy

During incoming postcopy, the destination qemu will invoke qemu_rdma_wait_comp_channel in a seprate thread. So does not use rdma yield, and poll the completion channel fd instead. Signed-off-by: Lidong Chen --- migration/rdma.c | 4 +++- 1 file changed, 3 insertions(+),

Re: [Qemu-devel] [RFC v2 1/2] virtio: add pmem driver

[ adding Jeff directly since he has also been looking at infrastructure to track when MAP_SYNC should be disabled ] On Wed, Apr 25, 2018 at 7:21 AM, Dan Williams wrote: > On Wed, Apr 25, 2018 at 4:24 AM, Pankaj Gupta wrote: >> This patch adds

Re: [Qemu-devel] [PATCH v2 3/9] block: Add BDRV_REQ_WRITE_UNCHANGED flag

On 04/21/2018 08:29 AM, Max Reitz wrote: > This flag signifies that a write request will not change the visible > disk content. With this flag set, it is sufficient to have the > BLK_PERM_WRITE_UNCHANGED permission instead of BLK_PERM_WRITE. > > Signed-off-by: Max Reitz >

Re: [Qemu-devel] [PATCH 02/13] hw/arm/fsl-imx*: Don't create "null" chardevs for serial devices

On 20.04.2018 16:52, Peter Maydell wrote: > Following commit 12051d82f004024, UART devices should handle > being passed a NULL pointer chardev, so we don't need to > create "null" backends in board code. Remove the code that > does this and updates serial_hds[]. ... maybe drop the "updates

[Qemu-devel] [PATCH v2 3/5] migration: remove unnecessary variables len in QIOChannelRDMA

Because qio_channel_rdma_writev and qio_channel_rdma_readv maybe invoked by different threads concurrently, this patch removes unnecessary variables len in QIOChannelRDMA and use local variable instead. Signed-off-by: Lidong Chen --- migration/rdma.c | 15 +++

Re: [Qemu-devel] [RFC v2] qemu: Add virtio pmem device

On 04/25/2018 06:24 AM, Pankaj Gupta wrote: > This patch adds virtio-pmem Qemu device. > > This device presents memory address range > information to guest which is backed by file > backend type. It acts like persistent memory > device for KVM guest. Guest can perform read > and persistent

Re: [Qemu-devel] [PATCH 06/13] vl.c: Provide accessor function serial_hd() for serial_hds[] array

On 04/20/2018 11:52 AM, Peter Maydell wrote: > Provide an accessor function serial_hd() to return the Chardev > (if any) associated with the numbered serial port. This will > be used to replace direct accesses to the serial_hds[] array, > so that calling code doesn't need to care about the size of

Re: [Qemu-devel] [PATCH v3 39/46] tests/tcg: enable building for m68k

On 04/24/2018 12:23 PM, Alex Bennée wrote: > As before, using Debian SID compilers. > > Signed-off-by: Alex Bennée > --- > tests/docker/Makefile.include | 1 + > tests/docker/dockerfiles/debian-m68k-cross.docker | 12 >

[Qemu-devel] [PATCH v2 0/5] Enable postcopy RDMA live migration

The RDMA QIOChannel does not support bi-directional communication, so when RDMA live migration with postcopy enabled, the source qemu return path get qemu file error. These patches implement bi-directional communication for RDMA QIOChannel and disable the RDMA WRITE during the postcopy phase.

[Qemu-devel] [PATCH v2 4/5] migration: implement bi-directional RDMA QIOChannel

This patch implements bi-directional RDMA QIOChannel. Because different threads may access RDMAQIOChannel concurrently, this patch use RCU to protect it. Signed-off-by: Lidong Chen --- migration/rdma.c | 162 +-- 1

[Qemu-devel] [PATCH v12 16/17] hw/arm/smmuv3: IOTLB emulation

We emulate a TLB cache of size SMMU_IOTLB_MAX_SIZE=256. It is implemented as a hash table whose key is a combination of the 16b asid and 48b IOVA. Entries are invalidated on TLB invalidation commands, either globally, or per asid, or per asid/iova. Signed-off-by: Eric Auger

Re: [Qemu-devel] [RFC v2 2/2] pmem: device flush over VIRTIO

On Wed, Apr 25, 2018 at 4:24 AM, Pankaj Gupta wrote: > This patch adds functionality to perform > flush from guest to hosy over VIRTIO > when 'ND_REGION_VIRTIO'flag is set on > nd_negion. Flag is set by 'virtio-pmem' > driver. > > Signed-off-by: Pankaj Gupta

<    1   2   3   4   >