Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces)

John Snow writes: > On 04/18/2017 07:57 AM, Gerd Hoffmann wrote: >> Hi, >> Just like -device is a general way to plug in devices, replacing multiple special ways (-net, -drive, -usb, ...), we could use a general way to configure onboard devices. >>> >>> I

Re: [Qemu-devel] Jailhouse on Ultrascale+ (ZCU102)

On 2017-04-19 05:48, Constantin Petra wrote: > Hello, > > I have tried the same binaries on a ZCU102 board and it seems to work. > Cannot be sure though, the board is remote and I don't have access to > the secondary UART as I understand it would be required for the uart-demo. You can always

[Qemu-devel] [Bug 946043] Re: Serial Named Pipe Unrecognized Windows 7

[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/946043 Title: Serial

Re: [Qemu-devel] [PATCH v9 1/9] memory: add section range info for IOMMU notifier

On Tue, Apr 18, 2017 at 02:30:54PM -0300, Eduardo Habkost wrote: > On Tue, Apr 18, 2017 at 06:20:11PM +0300, Marcel Apfelbaum wrote: > > On 04/10/2017 10:09 AM, Peter Xu wrote: > > > On Mon, Apr 10, 2017 at 02:39:22PM +1000, David Gibson wrote: > > > > On Fri, Apr 07, 2017 at 06:59:07PM +0800,

Re: [Qemu-devel] [PATCH v9 1/9] memory: add section range info for IOMMU notifier

On Tue, Apr 18, 2017 at 09:55:11PM +1000, David Gibson wrote: > On Tue, Apr 18, 2017 at 05:56:37PM +0800, Peter Xu wrote: > > On Tue, Apr 11, 2017 at 11:56:54AM +1000, David Gibson wrote: > > > On Mon, Apr 10, 2017 at 03:09:50PM +0800, Peter Xu wrote: > > > > On Mon, Apr 10, 2017 at 02:39:22PM

Re: [Qemu-devel] 答复: [PATCH 0/5] mc146818rtc: fix Windows VM clock faster

On 04/13/2017 05:38 PM, Hailiang Zhang wrote: On 2017/4/13 17:35, Xiao Guangrong wrote: On 04/13/2017 05:29 PM, Hailiang Zhang wrote: On 2017/4/13 17:18, Xiao Guangrong wrote: On 04/13/2017 05:05 PM, Zhanghailiang wrote: Hi, -邮件原件- 发件人: kvm-ow...@vger.kernel.org

Re: [Qemu-devel] [RFC v2 3/6] pci: Rename and change signatures of pci_bus_new() & related functions

On Wed, Apr 19, 2017 at 10:29:26AM +1000, David Gibson wrote: > On Tue, Apr 18, 2017 at 07:17:21PM -0300, Eduardo Habkost wrote: > > pci_bus_new*() and pci_register_bus() work only when the 'parent' > > argument is a PCI_HOST_BRIDGE object. Rename them to reflect that they > > are meant to

[Qemu-devel] [PATCH v3] char: Fix removing wrong GSource that be found by fd_in_tag

We use fd_in_tag to find a GSource, fd_in_tag is return value of g_source_attach(GSource *source, GMainContext *context), the return value is unique only in the same context, so we may get the same values with different 'context' parameters. It is no problem to find the right fd_in_tag by using

Re: [Qemu-devel] [PATCH v2] char: Fix removing wrong GSource that be found by fd_in_tag

On 2017/4/18 16:11, Marc-André Lureau wrote: Hi - Original Message - We use fd_in_tag to find a GSource, fd_in_tag is return value of g_source_attach(GSource *source, GMainContext *context), the return value is unique only in the same context, so we may get the same values with

Re: [Qemu-devel] [PATCH] char: Fix removing wrong GSource that be found by fd_in_tag

On 2017/4/18 21:36, Eric Blake wrote: On 04/14/2017 05:10 AM, Marc-André Lureau wrote: Hi - Original Message - We use fd_in_tag to find a GSource, fd_in_tag is return value of g_source_attach(GSource *source, GMainContext *context), the return value is unique only in the same context,

Re: [Qemu-devel] [RFC v2 3/6] pci: Rename and change signatures of pci_bus_new() & related functions

On Tue, Apr 18, 2017 at 07:17:21PM -0300, Eduardo Habkost wrote: > pci_bus_new*() and pci_register_bus() work only when the 'parent' > argument is a PCI_HOST_BRIDGE object. Rename them to reflect that they > are meant to initialize a bus that's in a PCI host bridge. > > The new function names

Re: [Qemu-devel] [RFC v2 1/6] pci: Inline pci_host_bus_register() inside pci_bus_init()

On Tue, Apr 18, 2017 at 07:17:19PM -0300, Eduardo Habkost wrote: 1;4601;0c> There's no need for a separate function just to append an item to > pci_host_bridges. > > Cc: "Michael S. Tsirkin" > Cc: Marcel Apfelbaum > Signed-off-by: Eduardo Habkost

Re: [Qemu-devel] [RFC v2 2/6] pci: Move pci_bus_init() logic to pci_bus_new_inplace()

On Tue, Apr 18, 2017 at 07:17:20PM -0300, Eduardo Habkost wrote: > Instead of having 3 separate functions, just make pci_bus_new() a > wrapper that allocates the object and calls pci_bus_new_inplace(). > > Cc: "Michael S. Tsirkin" > Cc: Marcel Apfelbaum >

Re: [Qemu-devel] [RFC v2 4/6] pci: Manually simplify QOM casts at pci_host_bus_init*() calls

On Tue, Apr 18, 2017 at 07:17:22PM -0300, Eduardo Habkost wrote: > Those redundant casts were not detected by the Coccinelle patch because > there are multiple variables and casts involved. Fix them manually. > > Cc: "Michael S. Tsirkin" > Cc: Alexander Graf >

Re: [Qemu-devel] [PATCH v5] qga: Add `guest-get-timezone` command

Quoting Vinzenz 'evilissimo' Feenstra (2017-03-23 06:39:13) > From: Vinzenz Feenstra > > Adds a new command `guest-get-timezone` reporting the currently > configured timezone on the system. The information on what timezone is > currently is configured is useful in case of

[Qemu-devel] [RFC v2 6/6] pci: Remove unnecessary PCIBus variables

"phb->bus" is a short expression, there's no need for an extra variable just to hold its value. Generated using the following Coccinelle patch: @@ identifier b; identifier phb; typedef PCIBus; @@ -PCIBus *b; ... when != b -b = phb->bus; <... -b

[Qemu-devel] [RFC v2 4/6] pci: Manually simplify QOM casts at pci_host_bus_init*() calls

Those redundant casts were not detected by the Coccinelle patch because there are multiple variables and casts involved. Fix them manually. Cc: "Michael S. Tsirkin" Cc: Alexander Graf Cc: David Gibson Cc: Aurelien Jarno

[Qemu-devel] [RFC v2 2/6] pci: Move pci_bus_init() logic to pci_bus_new_inplace()

Instead of having 3 separate functions, just make pci_bus_new() a wrapper that allocates the object and calls pci_bus_new_inplace(). Cc: "Michael S. Tsirkin" Cc: Marcel Apfelbaum Signed-off-by: Eduardo Habkost --- hw/pci/pci.c | 39

[Qemu-devel] [RFC v2 5/6] pci: Set phb->bus inside pci_host_bus_init_inplace()

Every single caller of pci_host_bus_init*() sets phb->bus to point to 'bus'. Do that inside pci_bus_new_inplace() to avoid code duplication and make it harder to break. Generated using the following Coccinelle patch: @@ identifier b; expression phb; expression list ARGS; @@

[Qemu-devel] [RFC v2 3/6] pci: Rename and change signatures of pci_bus_new() & related functions

pci_bus_new*() and pci_register_bus() work only when the 'parent' argument is a PCI_HOST_BRIDGE object. Rename them to reflect that they are meant to initialize a bus that's in a PCI host bridge. The new function names are: * pci_host_bus_init() (replacing pci_bus_new()) *

[Qemu-devel] [RFC v2 1/6] pci: Inline pci_host_bus_register() inside pci_bus_init()

There's no need for a separate function just to append an item to pci_host_bridges. Cc: "Michael S. Tsirkin" Cc: Marcel Apfelbaum Signed-off-by: Eduardo Habkost --- hw/pci/pci.c | 11 +++ 1 file changed, 3 insertions(+), 8

[Qemu-devel] [RFC v2 0/6] pci: Refactor PCI root bus creation code

Changes v1 -> v2: * Original series subject: "pci: Type-safety and phb->bus initialization cleanup" * In addition to changing function signatures, also rename the functions to pci_host_bus_init*() * Inline pci_bus_init() and pci_host_bus_register() inside their callers * Remove unnecessary

Re: [Qemu-devel] [Qemu-block] [PATCH 16/17] block: Make bdrv_is_allocated() byte-based

On 04/11/2017 06:29 PM, Eric Blake wrote: > We are gradually moving away from sector-based interfaces, towards > byte-based. In the common case, allocation is unlikely to ever use > values that are not naturally sector-aligned, but it is possible > that byte-based values will let us be more

Re: [Qemu-devel] [PATCH v2] i386: Allow cpuid bit override

Quoting Eric Blake (2017-04-18 16:19:10) > On 04/18/2017 04:01 PM, Michael Roth wrote: > > >>> @@ -3706,8 +3707,17 @@ static void x86_cpu_get_bit_prop(Object *obj, > >>> Visitor *v, const char *name, > >>> X86CPU *cpu = X86_CPU(obj); > >>> BitProperty *fp = opaque; > >>> uint32_t

[Qemu-devel] [PATCH v1.5 06.5/31] fixup! block: Convert bdrv_get_block_status() to bytes

[adjust a paragraph of the original commit message] ... Note that we have an inherent limitation in the BDRV_BLOCK_* return values: BDRV_BLOCK_OFFSET_VALID can only return the start of a sector, even if we later relax the interface to query for the status starting at an intermediate byte; document

Re: [Qemu-devel] [PATCH v2] i386: Allow cpuid bit override

On 04/18/2017 04:01 PM, Michael Roth wrote: >>> @@ -3706,8 +3707,17 @@ static void x86_cpu_get_bit_prop(Object *obj, >>> Visitor *v, const char *name, >>> X86CPU *cpu = X86_CPU(obj); >>> BitProperty *fp = opaque; >>> uint32_t f = cpu->env.features[fp->w]; >>> +uint32_t ff =

Re: [Qemu-devel] [Qemu-block] [RFC] Proposed qcow2 extension: subcluster allocation

On 04/18/2017 02:22 PM, Kevin Wolf wrote: > Am 14.04.2017 um 06:17 hat Denis V. Lunev geschrieben: >> [skipped...] >> >>> Hi Denis, >>> >>> I've read this entire thread now and I really like Berto's summary which >>> I think is one of the best recaps of existing qcow2 problems and this >>>

Re: [Qemu-devel] [PATCH v2] i386: Allow cpuid bit override

Quoting Michael Roth (2017-04-18 16:01:20) > Quoting Eduardo Habkost (2017-04-13 12:36:25) > > On Tue, Mar 28, 2017 at 01:27:06PM +0200, Alexander Graf wrote: > > > KVM has a feature bitmap of CPUID bits that it knows works for guests. > > > QEMU removes bits that are not part of that bitmap

Re: [Qemu-devel] [PATCH v2] i386: Allow cpuid bit override

Quoting Eduardo Habkost (2017-04-13 12:36:25) > On Tue, Mar 28, 2017 at 01:27:06PM +0200, Alexander Graf wrote: > > KVM has a feature bitmap of CPUID bits that it knows works for guests. > > QEMU removes bits that are not part of that bitmap automatically on VM > > start. > > > > However, some

Re: [Qemu-devel] [PATCH 13/31] file-posix: Switch to .bdrv_co_block_status()

On 04/17/2017 08:33 PM, Eric Blake wrote: > We are gradually moving away from sector-based interfaces, towards > byte-based. Update the file protocol driver accordingly. > > Signed-off-by: Eric Blake > --- > block/file-posix.c | 47

Re: [Qemu-devel] virtio-scsi limits

On Tue, Apr 18, 2017 at 06:17:03PM +0100, Richard W.M. Jones wrote: > On Tue, Apr 18, 2017 at 05:30:52PM +0200, Paolo Bonzini wrote: > > > When I changed libguestfs to use LUNs instead of targets (target=0 > > > unit=i), I got a peculiar bug. It looks like there is some kind of > > > race when

Re: [Qemu-devel] [PATCH 00/31] make bdrv_get_block_status byte-based

On 04/17/2017 08:33 PM, Eric Blake wrote: > There are patches floating around to add NBD_CMD_BLOCK_STATUS, > but NBD wants to report status on byte granularity (even if the > reporting will probably be naturally aligned to sectors or even > much higher levels). I've therefore started the task of

[Qemu-devel] [Bug 1681688] Re: qemu live migration failed

** Changed in: qemu Status: Incomplete => 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/1681688 Title: qemu live migration failed Status in QEMU: Confirmed Bug description:

Re: [Qemu-devel] [PATCH 19/19] monitor: remove monitor parameter from save_vmstate

"Dr. David Alan Gilbert" wrote: > https://lists.nongnu.org/archive/html/qemu-devel/2017-03/msg03927.html Damn thing. And I did it by hand (not that it was very difficult). Added bonus is that I have already changed load_vmstate on the same patch. Will post them on next

Re: [Qemu-devel] [PATCH 02/12] migration: Don't lose errno across aio context changes

Eric Blake wrote: > set_drity_tracking() was assuming that the errno value set by > bdrv_create_dirty_bitmap() would not be corrupted by either > blk_get_aio_context() or aio_context_release(). Rather than > audit whether this assumption is safe, rewrite the code to just >

[Qemu-devel] [Bug 1682093] Re: aarch64-softmmu "bad ram pointer" crash

** Changed in: qemu Status: New => Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1682093 Title: aarch64-softmmu "bad ram pointer" crash Status in QEMU: Invalid Bug description:

[Qemu-devel] [Bug 1681688] Re: qemu live migration failed

** Changed in: qemu Status: New => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1681688 Title: qemu live migration failed Status in QEMU: Incomplete Bug description: qemu

[Qemu-devel] [PATCH v3 for-2.10] qemu-iotests: _cleanup_qemu must be called on exit

For the tests that use the common.qemu functions for running a QEMU process, _cleanup_qemu must be called in the exit function. If it is not, if the qemu process aborts, then not all of the droppings are cleaned up (e.g. pidfile, fifos). This updates those tests that did not have a cleanup in

Re: [Qemu-devel] [PATCH v2 for-2.10 1/1] qemu-iotests: _cleanup_qemu must be called on exit

On Tue, Apr 18, 2017 at 02:39:12PM -0500, Eric Blake wrote: > On 04/18/2017 02:31 PM, Jeff Cody wrote: > > On Tue, Apr 18, 2017 at 01:44:43PM -0500, Eric Blake wrote: > >> On 04/18/2017 12:45 PM, Jeff Cody wrote: > >>> For the tests that use the common.qemu functions for running a QEMU > >>>

Re: [Qemu-devel] [PATCH v2 for-2.10 1/1] qemu-iotests: _cleanup_qemu must be called on exit

On 04/18/2017 02:31 PM, Jeff Cody wrote: > On Tue, Apr 18, 2017 at 01:44:43PM -0500, Eric Blake wrote: >> On 04/18/2017 12:45 PM, Jeff Cody wrote: >>> For the tests that use the common.qemu functions for running a QEMU >>> process, _cleanup_qemu must be called in the exit function. >>> >>> If it

Re: [Qemu-devel] [PATCH v2 for-2.10 1/1] qemu-iotests: _cleanup_qemu must be called on exit

On Tue, Apr 18, 2017 at 01:44:43PM -0500, Eric Blake wrote: > On 04/18/2017 12:45 PM, Jeff Cody wrote: > > For the tests that use the common.qemu functions for running a QEMU > > process, _cleanup_qemu must be called in the exit function. > > > > If it is not, if the qemu process aborts, then not

Re: [Qemu-devel] [PATCH 4/5] migration: Disable hotplug/unplug during migration

Eric Blake wrote: > On 04/06/2017 08:13 AM, Juan Quintela wrote: >> Until we have reviewed what can/can't be hotplug during migration, > > s/hotplug/hotplugged/ > >> disable it. We can enable it later for the things that we know that >> work. For instance, memory hotplug

Re: [Qemu-devel] [PATCH] timer.h: Provide monotonic time for ARM guests

On Tue, Apr 18, 2017 at 5:56 AM, Paolo Bonzini wrote: > > > On 17/04/2017 20:55, Pranith Kumar wrote: +/* ARM does not have a user-space readble cycle counter available. + * This is a compromise to get monotonically increasing time. + */ +static inline

[Qemu-devel] [PATCH] timer.h: Provide better monotonic time

Tested and confirmed that the stretch i386 debian qcow2 image on a raspberry pi 2 works. Fixes: LP#: 893208 Signed-off-by: Pranith Kumar --- include/qemu/timer.h | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)

Re: [Qemu-devel] [PATCH 48/54] ram: Use page number instead of an address for the bitmap operations

"Dr. David Alan Gilbert" wrote: > * Juan Quintela (quint...@redhat.com) wrote: >> We use an unsigned long for the page number. Notice that our bitmaps >> already got that for the index, so we have that limit. >> >> Signed-off-by: Juan Quintela > > see

Re: [Qemu-devel] [PATCH 10/19] migration: Remove use of old MigrationParams

* Juan Quintela (quint...@redhat.com) wrote: > We have change in the previous patch to use migration capabilities for > it. Notice that we continue using the old command line flags from > migrate command from the time being. Remove the set_params method as > now it is empty. > > Signed-off-by:

Re: [Qemu-devel] CUSE-TPM : Win 10 reports TPM device doesn't have sufficient resources

You may want to try it from this version:[1] https://github.com/stefanberger/qemu-tpm/tree/v2.8.0+tpm - Original message - From: anshul makkar To: Cc: Stefan Berger/Watson/IBM@IBMUS Subject: CUSE-TPM : Win

Re: [Qemu-devel] [PATCH v2 for-2.10 1/1] qemu-iotests: _cleanup_qemu must be called on exit

On 04/18/2017 12:45 PM, Jeff Cody wrote: > For the tests that use the common.qemu functions for running a QEMU > process, _cleanup_qemu must be called in the exit function. > > If it is not, if the qemu process aborts, then not all of the droppings > are cleaned up (e.g. pidfile, fifos). > >

Re: [Qemu-devel] [PATCH 02/19] migration: They are called vmstate_foo, move them to vmstate.c

* Juan Quintela (quint...@redhat.com) wrote: > Signed-off-by: Juan Quintela > --- > migration/savevm.c | 17 - > migration/vmstate.c | 16 > 2 files changed, 16 insertions(+), 17 deletions(-) OK, but it's a little odd, savevm.c still has

Re: [Qemu-devel] [PATCH RESEND v4 4/4] HMP: Introduce msr_get and msr_set HMP commands

On Tue, Apr 18, 2017 at 09:39:46AM +0200, Julian Kirsch wrote: > Add two new x86-specific HMP commands to read/write model specific > registers (MSRs) of the current CPU. > > Signed-off-by: Julian Kirsch [...] > @@ -651,3 +653,77 @@ void hmp_info_io_apic(Monitor *mon, const

Re: [Qemu-devel] [PATCH 40/54] ram: Remove compression_switch and inline its logic

Peter Xu wrote: > On Thu, Apr 06, 2017 at 03:08:59PM +0200, Juan Quintela wrote: >> We can calculate its value, so not create a varible for it. >> >> Signed-off-by: Juan Quintela >> >> -- >> >> After Peter and Dave review, I dropped the variable and

Re: [Qemu-devel] [PATCH RESEND v4 1/4] X86: Move rdmsr/wrmsr functionality to standalone functions

On Tue, Apr 18, 2017 at 05:38:01PM +0200, Paolo Bonzini wrote: > > > On 18/04/2017 17:28, Eduardo Habkost wrote: > > Hi, > > > > A few comments below: > > > > On Tue, Apr 18, 2017 at 09:39:43AM +0200, Julian Kirsch wrote: > >> Add two new functions to provide read/write access to model

[Qemu-devel] [ANNOUNCE] QEMU 2.9.0-rc5 is now available

Hello, On behalf of the QEMU Team, I'd like to announce the availability of the sixth release candidate for the QEMU 2.9 release. This release is meant for testing purposes and should not be used in a production environment. http://download.qemu-project.org/qemu-2.9.0-rc5.tar.xz

Re: [Qemu-devel] [PATCH 19/19] monitor: remove monitor parameter from save_vmstate

* Juan Quintela (quint...@redhat.com) wrote: > load_vmstate() already use error_report, so be consistent. > > Signed-off-by: Juan Quintela See https://lists.nongnu.org/archive/html/qemu-devel/2017-03/msg03927.html Dave > --- > include/sysemu/sysemu.h | 2 +- >

Re: [Qemu-devel] [RFC] Proposed qcow2 extension: subcluster allocation

On 04/18/2017 02:52 PM, Alberto Garcia wrote: > On Thu 13 Apr 2017 05:17:21 PM CEST, Denis V. Lunev wrote: >> On 04/13/2017 06:04 PM, Alberto Garcia wrote: >>> On Thu 13 Apr 2017 03:30:43 PM CEST, Denis V. Lunev wrote: Yes, block size should be increased. I perfectly in agreement with

[Qemu-devel] [PATCH v2 for-2.10 1/1] qemu-iotests: _cleanup_qemu must be called on exit

For the tests that use the common.qemu functions for running a QEMU process, _cleanup_qemu must be called in the exit function. If it is not, if the qemu process aborts, then not all of the droppings are cleaned up (e.g. pidfile, fifos). This updates those tests that did not have a cleanup in

Re: [Qemu-devel] DMG chunk size independence

On Tue, Apr 18, 2017 at 10:35 PM, John Snow wrote: > >> >> I could be wrong, but that's my hunch. >> >> Maybe you can cache the state of the INFLATE process such that once you >> fill the cache with data, we can simply resume the INFLATE procedure >> when the

[Qemu-devel] CUSE-TPM : Win 10 reports TPM device doesn't have sufficient resources

Hi, I am using CUSE-TPM based on https://github.com/stefanberger/qemu-tpmbranch: 2.4.1+tpm https://github.com/stefanberger/swtpm https://github.com/ts468/seabios-tpm I am facing an issue where WIndows 10 guest device manager reports TPM status as @ The device status is "The device

Re: [Qemu-devel] QEMU build breakage on ARM against Xen 4.9 caused by libxendevicemodel

On Tue, 18 Apr 2017, Paul Durrant wrote: > > -Original Message- > > From: Stefano Stabellini [mailto:sstabell...@kernel.org] > > Sent: 15 April 2017 01:40 > > To: Stefano Stabellini > > Cc: Paul Durrant ; qemu-devel@nongnu.org; > > Anthony

Re: [Qemu-devel] [PATCH for-2.10 1/1] qemu-iotests: _cleanup_qemu must be called on exit

On 04/18/2017 12:31 PM, Jeff Cody wrote: > For the tests that use the common.qemu functions for running a QEMU > process, _cleanup_qemu must be called in the exit function. > > If it is not, if the qemu process aborts, then not all of the droppings > are cleaned up (e.g. pidfile, fifos). > >

[Qemu-devel] [PATCH for-2.10 1/1] qemu-iotests: _cleanup_qemu must be called on exit

For the tests that use the common.qemu functions for running a QEMU process, _cleanup_qemu must be called in the exit function. If it is not, if the qemu process aborts, then not all of the droppings are cleaned up (e.g. pidfile, fifos). This updates those tests that did not have a cleanup in

Re: [Qemu-devel] [PATCH v9 1/9] memory: add section range info for IOMMU notifier

On Tue, Apr 18, 2017 at 06:20:11PM +0300, Marcel Apfelbaum wrote: > On 04/10/2017 10:09 AM, Peter Xu wrote: > > On Mon, Apr 10, 2017 at 02:39:22PM +1000, David Gibson wrote: > > > On Fri, Apr 07, 2017 at 06:59:07PM +0800, Peter Xu wrote: > > > > In this patch, IOMMUNotifier.{start|end} are

Re: [Qemu-devel] [Xen-devel] [PATCH] configure: introduce --enable-xen-fb-backend

On Tue, 18 Apr 2017, Juergen Gross wrote: > On 14/04/17 19:52, Stefano Stabellini wrote: > > On Fri, 14 Apr 2017, Juergen Gross wrote: > >> On 14/04/17 08:06, Oleksandr Andrushchenko wrote: > >>> On 04/14/2017 03:12 AM, Stefano Stabellini wrote: > On Tue, 11 Apr 2017, Oleksandr Andrushchenko

Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces)

On 04/18/2017 07:57 AM, Gerd Hoffmann wrote: > Hi, > >>> Just like -device is a general way to plug in devices, replacing >>> multiple special ways (-net, -drive, -usb, ...), we could use a general >>> way to configure onboard devices. >> >> I looked at the -device implementation to see if

Re: [Qemu-devel] [Qemu-block] [PATCH for-2.10?] block: Do not unref bs->file on error in BD's open

On Thu, Apr 13, 2017 at 05:43:34PM +0200, Max Reitz wrote: > The block layer takes care of removing the bs->file child if the block > driver's bdrv_open()/bdrv_file_open() implementation fails. The block > driver therefore does not need to do so, and indeed should not unless it > sets bs->file to

Re: [Qemu-devel] virtio-scsi limits

On Tue, Apr 18, 2017 at 05:30:52PM +0200, Paolo Bonzini wrote: > > When I changed libguestfs to use LUNs instead of targets (target=0 > > unit=i), I got a peculiar bug. It looks like there is some kind of > > race when enumerating the device, where /sys is populated before the > > device is

Re: [Qemu-devel] qemu and own disk driver writing questions

On Thu, Apr 13, 2017 at 01:57:17PM +0300, Vasiliy Tolstov wrote: > Hi! If i want to develop some sort of qemu network block driver to own > storage. I can write qemu driver or tcmu / scst userspace driver and > attach to qemu block device (i'm use linux) > So in theory what path have minimal

Re: [Qemu-devel] DMG chunk size independence

On 04/18/2017 06:21 AM, Ashijeet Acharya wrote: > > On Tue, Apr 18, 2017 at 01:59 John Snow > wrote: > > > > On 04/15/2017 04:38 AM, Ashijeet Acharya wrote: > > Hi, > > > > Some of you are already aware but for the benefit of the

Re: [Qemu-devel] [PATCH v17 1/2] virtio-crypto: Add virtio crypto device specification

On Thu, Apr 13, 2017 at 05:11:13PM +0800, Gonglei wrote: More grammar fixes and the reasoning behind my suggestions. I've only reviewed 1/3rd of this patch so far. > The virtio crypto device is a virtual crypto device (ie. hardware > crypto accelerator card). Currently, the virtio crypto device

Re: [Qemu-devel] Hight Processor time of Socket communciation

On 18 April 2017 at 17:19, Jiahuan Zhang wrote: > Dear QEMU developers, > I am measuring the processor time for guest-host communication via socket. > The guest app is to write a 5M image to a serial device. > The serial deivce is redirected to the socket in the command

[Qemu-devel] Hight Processor time of Socket communciation

Dear QEMU developers, I am measuring the processor time for guest-host communication via socket. The guest app is to write a 5M image to a serial device. The serial deivce is redirected to the socket in the command line. The host app is to receive the data via socket until the peer closes the

Re: [Qemu-devel] [PATCH] hw: make *_exit functions return void

On Sun, 16 Apr 2017 20:26:01 +0800 Zihan Yang wrote: > According to the second suggestion listed on Dead code Removal > of BiteSizedTasks, I modify some *_exit functions to make them > return void. Some *_exit and *_exitfn functions that already > return void

Re: [Qemu-devel] [RFC for-3.0 0/4] block: Add qcow2-rust block driver

Hi, This series failed automatic build test. Please find the testing commands and their output below. If you have docker installed, you can probably reproduce it locally. Type: series Message-id: 20170401155751.14322-1-mre...@redhat.com Subject: [Qemu-devel] [RFC for-3.0 0/4] block: Add

Re: [Qemu-devel] [RFC for-3.0 0/4] block: Add qcow2-rust block driver

woot! Happy birthday! On Tue, Apr 18, 2017 at 7:58 PM Max Reitz wrote: > The issues of using C are well understood and nobody likes it. Let's use > a better language. C++ is not a better language, Rust is. Everybody > loves Rust. Rust is good. Rust is hip. It will attract

Re: [Qemu-devel] [RFC for-3.0 0/4] block: Add qcow2-rust block driver

Hi, This series seems to have some coding style problems. See output below for more information: Type: series Message-id: 20170401155751.14322-1-mre...@redhat.com Subject: [Qemu-devel] [RFC for-3.0 0/4] block: Add qcow2-rust block driver === TEST SCRIPT BEGIN === #!/bin/bash BASE=base n=1

Re: [Qemu-devel] [RFC for-3.0 0/4] block: Add qcow2-rust block driver

Hi, This series failed build test on s390x host. Please find the details below. Type: series Message-id: 20170401155751.14322-1-mre...@redhat.com Subject: [Qemu-devel] [RFC for-3.0 0/4] block: Add qcow2-rust block driver === TEST SCRIPT BEGIN === #!/bin/bash # Testing script will be invoked

Re: [Qemu-devel] [PATCH 2/2] net/socket: Improve -net socket error reporting

Mao Zhongyi writes: > When -net socket fails, it first reports a specific error, then > a generic one, like this: > > $ qemu-system-x86_64 -net socket, > qemu-system-x86_64: -net socket: exactly one of fd=, listen=, connect=, > mcast= or udp= is required >

[Qemu-devel] [RFC for-3.0 4/4] block/qcow2-rust: Register block driver

The rust qcow2 driver is now actually MUCH BETTER than the LEGACY CROOKED qcow2 driver, so let's not beat around the bush and just register it as a block driver. Has always been my opinion, never said anything different. The QEMU project will deal with the C issue in a decisive way. Q.M.U.

[Qemu-devel] [RFC for-3.0 3/4] block/qcow2-rust: Add partial write support

Some people may want to lead you to believe write support may destroy your data. These entirely BASELESS and FALSE accusations are COMPLETE and UTTER LIES because you actually cannot use this driver yet at all, as it does not register itself as a qemu block driver. This is a very modest approach,

[Qemu-devel] [RFC for-3.0 1/4] block: Add Rust interface

This patch adds an FFI interface for block drivers written in Rust, the language of the future. It's a very good interface, in fact, it's the best interface there is. We are truly making QEMU great again! Signed-off-by: Max Reitz --- configure |

[Qemu-devel] [RFC for-3.0 0/4] block: Add qcow2-rust block driver

The issues of using C are well understood and nobody likes it. Let's use a better language. C++ is not a better language, Rust is. Everybody loves Rust. Rust is good. Rust is hip. It will attract developers, it will improve code quality, it will improve performance, it will even improve your

[Qemu-devel] [RFC for-3.0 2/4] block/qcow2-rust: Add qcow2-rust block driver

Currently, this MUCH MORE SECURE block driver than the LEGACY C qcow2 driver (SAD!) only has read support. But this makes it actually much less likely to destroy your data, so this is a GOOD thing. Signed-off-by: Max Reitz --- block/rust/src/lib.rs | 3

Re: [Qemu-devel] [PATCH for-2.10] iotests: 109: Filter out "len" of failed jobs

On 04/18/2017 02:59 AM, Fam Zheng wrote: > Mirror calculates job len from current I/O progress: > > s->common.len = s->common.offset + > (cnt + s->sectors_in_flight) * BDRV_SECTOR_SIZE; > > The final "len" of a failed mirror job in iotests 109 depends on the > subtle

Re: [Qemu-devel] [PATCH RESEND v4 1/4] X86: Move rdmsr/wrmsr functionality to standalone functions

On 18/04/2017 17:28, Eduardo Habkost wrote: > Hi, > > A few comments below: > > On Tue, Apr 18, 2017 at 09:39:43AM +0200, Julian Kirsch wrote: >> Add two new functions to provide read/write access to model specific >> registers >> (MSRs) on x86. Move original functionality to new functions >>

Re: [Qemu-devel] [Qemu-block] migrate -b problems

Am 18.04.2017 um 16:47 hat Stefan Hajnoczi geschrieben: > On Wed, Apr 12, 2017 at 11:18:19AM +0200, Kevin Wolf wrote: > > after getting assertion failure reports for block migration in the last > > minute, we just hacked around it by commenting out op blocker assertions > > for the 2.9 release,

Re: [Qemu-devel] virtio-scsi limits

On 18/04/2017 17:24, Richard W.M. Jones wrote: > In libvirt, refers to the virtio-scsi "channel". > The current virtio-scsi driver in qemu has a hard limit of 1 channel, > so you can only use bus="0" (or channel=0). > > Open question: Will this limit ever be increased? No, it's only there

Re: [Qemu-devel] [PATCH RESEND v4 1/4] X86: Move rdmsr/wrmsr functionality to standalone functions

Hi, A few comments below: On Tue, Apr 18, 2017 at 09:39:43AM +0200, Julian Kirsch wrote: > Add two new functions to provide read/write access to model specific registers > (MSRs) on x86. Move original functionality to new functions > x86_cpu_[rd|wr]msr. This enables other parts of the qemu

[Qemu-devel] virtio-scsi limits

Hi Paolo, I was looking for documentation on the limits of #controllers, #channels, #targets, #LUNs, #disks in virtio-scsi, and couldn't find any, so I thought I would create that documentation instead. I wonder if you could check that the following is correct information. Also - at the bottom

Re: [Qemu-devel] [PATCH v9 1/9] memory: add section range info for IOMMU notifier

On 04/10/2017 10:09 AM, Peter Xu wrote: On Mon, Apr 10, 2017 at 02:39:22PM +1000, David Gibson wrote: On Fri, Apr 07, 2017 at 06:59:07PM +0800, Peter Xu wrote: In this patch, IOMMUNotifier.{start|end} are introduced to store section information for a specific notifier. When notification

Re: [Qemu-devel] guest host time synchronization

On 18 April 2017 at 16:32, Stefan Hajnoczi wrote: > On Tue, Apr 11, 2017 at 09:01:40AM +0200, Jiahuan Zhang wrote: > > I made a test to check the time difference of QEMU emulated ARM-based > Linux > > guest and the Windows host. The result is, the guest time is around 0.2 > >

Re: [Qemu-devel] [PATCH v5 1/9] block: add bdrv_measure() API

On 04/18/2017 08:57 AM, Stefan Hajnoczi wrote: > bdrv_measure() provides a conservative maximum for the size of a new > image. This information is handy if storage needs to be allocated (e.g. > a SAN or an LVM volume) ahead of time. > > Signed-off-by: Stefan Hajnoczi >

[Qemu-devel] [PULL 1/2] block: Walk bs->children carefully in bdrv_drain_recurse

The recursive bdrv_drain_recurse may run a block job completion BH that drops nodes. The coming changes will make that more likely and use-after-free would happen without this patch Stash the bs pointer and use bdrv_ref/bdrv_unref in addition to QLIST_FOREACH_SAFE to prevent such a case from

[Qemu-devel] [PULL 0/2] Block patches for 2.9-rc5

The following changes since commit 9c6b899f7a46893ab3b671e341a2234e9c0c060e: 9pfs: local: set the path of the export root to "." (2017-04-18 14:01:43 +0100) are available in the git repository at: git://github.com/famz/qemu.git tags/block-pull-request for you to fetch changes up to

[Qemu-devel] [PULL 2/2] block: Drain BH in bdrv_drained_begin

During block job completion, nothing is preventing block_job_defer_to_main_loop_bh from being called in a nested aio_poll(), which is a trouble, such as in this code path: qmp_block_commit commit_active_start bdrv_reopen bdrv_reopen_multiple

Re: [Qemu-devel] [PATCH 1/7] target/openrisc: Fixes for memory debugging

On 04/18/2017 07:18 AM, Stafford Horne wrote: On Tue, Apr 18, 2017 at 12:47:30AM -0700, Richard Henderson wrote: On 04/16/2017 04:23 PM, Stafford Horne wrote: When debugging in gdb you might want to inspect instructions in mapped pages or in exception vectors like 0x800 etc. This was

Re: [Qemu-devel] [PATCH 03/14] cg3: remove unused width and height variables

On 04/18/2017 07:38 AM, Mark Cave-Ayland wrote: On 15/04/17 11:54, Richard Henderson wrote: On 04/05/2017 01:35 AM, Mark Cave-Ayland wrote: These aren't required since we can use the display width and height directly. Signed-off-by: Mark Cave-Ayland ---

Re: [Qemu-devel] [PATCH for-2.9-rc5 v4 1/2] block: Walk bs->children carefully in bdrv_drain_recurse

On Tue, 04/18 16:46, Kevin Wolf wrote: > Am 18.04.2017 um 16:30 hat Fam Zheng geschrieben: > > The recursive bdrv_drain_recurse may run a block job completion BH that > > drops nodes. The coming changes will make that more likely and > > use-after-free > > would happen without this patch > > > >

Re: [Qemu-devel] sleeping in vm live migration code

On Wed, Apr 12, 2017 at 06:13:33PM +0430, ali saeedi wrote: > why we have below code in vm live migration? > * g_usleep((initial_time + BUFFER_DELAY - current_time)*1000);* It's for migration rate-limiting. The migration thread throttles itself if the user has configured a maximum transmission

Re: [Qemu-devel] [PATCH for-2.9-rc5 v4 0/2] block: Drain BH in bdrv_drained_begin

On Tue, Apr 18, 2017 at 10:30:42PM +0800, Fam Zheng wrote: > v4: Split patch, and fix the unsafe bdrv_unref. [Paolo] > > Fam Zheng (2): > block: Walk bs->children carefully in bdrv_drain_recurse > block: Drain BH in bdrv_drained_begin > > block/io.c| 23 --- >

Re: [Qemu-devel] help for code

On Wed, Apr 12, 2017 at 04:36:58PM +0430, ali saeedi wrote: > I am new in qemu vm live migration. why we have this condition > "current_time >= initial_time + BUFFER_DELAY" in qemu? BUFFER_DELAY is used for rate-limiting. The maximum network throughput can be set by the user so that QEMU doesn't

  1   2   3   >