Contrary to what is written in the comment, a buggy guest can misconfigure
the transport buffers and pdu_marshal() may return an error. If this ever
happens, it is up to the transport layer to handle the situation (9P is
transport agnostic).
This fixes Coverity issue CID1348518.
Signed-off-by: G
The 9P protocol is transport agnostic: if the guest misconfigured the
buffers, the best we can do is to set the broken flag on the device.
Since virtio_pdu_vmarshal() may be called by several active PDUs, we
check if the transport isn't broken already to avoid printing extra
error messages.
Signe
The 9p spec at http://man.cat-v.org/plan_9/5/intro reads:
"Each 9P message begins with a four-byte size field specify-
ing the length in bytes of the complete message including
the four bytes of the size field itself. The next byte is
the message type, one of the constants in the enumerati
If the guest sends a malformed request, we end up with a dangling pointer
in V9fsVirtioState. This doesn't seem to cause any bug, but let's remove
this side effect anyway.
Signed-off-by: Greg Kurz
Reviewed-by: Michael S. Tsirkin
---
hw/9pfs/virtio-9p-device.c |3 ++-
1 file changed, 2 inser
The 9p protocol relies on a reliable transport, but the current code
treats transport errors (ie, failure to marshal or unmarshal) as if
they were coming from the backend. This doesn't make sense: if the
transport failed, we should notify the guest that the transport is
broken and needs to be reset
Vadim Galitsyn writes:
> Hi Markus,
>
> Thank you for the input.
>
>> However, your query-memory looks like it could fail.
>
> With the latest version of a patch (
> http://lists.nongnu.org/archive/html/qemu-devel/2017-06/msg03475.html)
> "query-memory" can fail only in two cases:
>
> a) if in QO
Hi Ladi,
Small update. Memtest86+ was running on the host for more than 54 hours. 8
passes were completed and no memory errors found. For now I think we can assume
that the host memory is ok.
I just started all the guests one hour ago. I will monitor them and once one
fails I will attach the d
OK, thanks for your answer!
** Changed in: qemu
Status: Incomplete => Won't Fix
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1047470
Title:
qemu/kvm hangs reading from serial console
Stat
Now we have some globals that can be configured for migration. Dump them
in HMP info migration for better debugging.
(we can also use this to monitor whether COMPAT fields are applied
correctly on compatible machines)
Reviewed-by: Juan Quintela
Signed-off-by: Peter Xu
---
hmp.c
These two parameters:
- MachineState::enforce_config_section
- MigrationState::send_configuration
are playing similar role here. This patch merges the first one into
second, then we'll have a single place to reference whether we need to
send the configuration section.
I didn't remove the Machine
Move it into MigrationState, revert its meaning and renaming it to
send_section_footer, with a property bound to it. Same trick is played
like previous patches.
Removing savevm_skip_section_footers().
Reviewed-by: Juan Quintela
Signed-off-by: Peter Xu
---
hw/i386/pc_piix.c| 1 -
hw/pp
Put it into MigrationState then we can use the properties to specify
whether to enable storing global state.
Removing global_state_set_optional() since now we can use HW_COMPAT_2_3
for x86/power, and AccelClass.global_props for Xen.
Reviewed-by: Juan Quintela
Signed-off-by: Peter Xu
---
hw/i38
It was in SaveState but now moved to MigrationState altogether, reverted
its meaning, then renamed to "send_configuration". Again, using
HW_COMPAT_2_3 for old PC/SPAPR machines, and accel_register_prop() for
xen_init().
Removing savevm_skip_configuration().
Reviewed-by: Juan Quintela
Signed-off-
One less global variable, and it does only matter with migration.
We keep the old "--only-migratable" option, but also now we support:
-global migration.only-migratable=true
Currently still keep the old interface.
Hmm, now vl.c has no way to access migrate_get_current(). Export a
function for
It's not that clear on how the global properties are registered to
global_props (and also its priority relationship). Let's provide a
single function to be called in main() for that, with comment to explain
it a bit.
Signed-off-by: Peter Xu
---
vl.c | 29 -
1 file cha
Let the old man "MigrationState" join the object family. Direct benefit
is that we can start to use all the property features derived from
current QDev, like: HW_COMPAT_* bits, command line setup for migration
parameters (so will never need to set them up each time using HMP/QMP,
this is really, re
Introduce this new field for the accelerator classes so that each
specific accelerator in the future can register its own global
properties to be used further by the system. It works just like how the
old machine compatible properties do, but only tailored for
accelerators.
Introduce register_comp
We have HW_COMPAT_*, however that's only bound to machines, not other
things (like accelerators). Behind it, it was register_compat_prop()
that played the trick. Let's export the function for further use
outside HW_COMPAT_* magic.
Meanwhile, move it to qdev-properties.c where seems more proper (
v5:
- add r-b for Juan on patch 4,5,7-10
- patch 2: introduce register_compat_props_array() that may be further
used by machine codes [Eduardo]
- patch 2: fix english error [Eduardo]
v4:
- dropped lots of patches related to AccelState.global_props. Now I am
using AccelClass.global_props, and o
On Thu, Jun 22, 2017 at 02:28:52PM -0300, Eduardo Habkost wrote:
> On Thu, Jun 22, 2017 at 12:25:30PM +0800, Peter Xu wrote:
> > On Wed, Jun 21, 2017 at 09:23:11AM -0300, Eduardo Habkost wrote:
> > > On Wed, Jun 21, 2017 at 03:52:00PM +0800, Peter Xu wrote:
> [...]
> > > > diff --git a/vl.c b/vl.c
In commit 9e0bc24f dev->log_size was reset to zero too early before
syncing vhost log. It causes syncing to be skipped.
Move it to clear dev->log* after use.
Signed-off-by: Jia-Shiun Li
---
hw/virtio/vhost.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/virtio/vhost
On Thu, Jun 22, 2017 at 11:27:09AM -0600, Alex Williamson wrote:
> On Thu, 22 Jun 2017 22:42:19 +0530
> Nitin Saxena wrote:
>
> > Thanks Alex.
> >
> > >> Without an iommu in the VM, you'd be limited to no-iommu support for VM
> > >> userspace,
> > So are you trying to say VFIO NO-IOMMU should
The caller of SetupDiGetClassDevs must delete the returned device information
set when it is no longer needed by calling SetupDiDestroyDeviceInfoList.
Signed-off-by: Li Ping
Reviewed-by: Marc-André Lureau
---
qga/commands-win32.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff
Use is_power_of_2(), and remove trailing "." from error_setg().
Signed-off-by: Wei Wang
---
hw/net/virtio-net.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index d13ca60..b42423c 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net
This patch enables the virtio-net tx queue size to be configurable
between 256 (the default queue size) and 1024 by the user when the
vhost-user backend is used.
Currently, the maximum tx queue size for other backends is 512 due
to the following limitations:
- QEMU backend: the QEMU backend implem
On 06/22/2017 10:00 PM, Michael S. Tsirkin wrote:
On Sat, Jun 17, 2017 at 04:38:03PM +0800, Wei Wang wrote:
On 06/16/2017 10:31 PM, Michael S. Tsirkin wrote:
On Fri, Jun 16, 2017 at 06:48:38PM +0800, Wei Wang wrote:
This patch enables the virtio-net tx queue size to be configurable
between 256
Marc-André Lureau, on jeu. 22 juin 2017 14:41:45 +0200, wrote:
> I used the clang-tidy qemu-round check to generate the fix:
> https://github.com/elmarco/clang-tools-extra
>
> Signed-off-by: Marc-André Lureau
Applied to my tree, thanks!
> ---
> slirp/ip6.h | 6 +++---
> 1 file changed, 3 inser
On 06/22/17 15:08 +0100, Stefan Hajnoczi wrote:
> I tried live migrating a guest with NVDIMM on qemu.git/master (edf8bc984):
>
> $ qemu -M accel=kvm,nvdimm=on -m 1G,slots=4,maxmem=8G -cpu host \
> -object
> memory-backend-file,id=mem1,share=on,mem-path=nvdimm.dat,size=1G \
>-de
If we have for example: r3 contains 0x
ec 33 3f bf 61 55 risbg %r3,%r3,63,191,97
We want to rotate 33 to the left and only keep MSB bit 63 of that. So the
result is then exactly 1 (we're reading the sign of the 32 bit value).
Current code assumes that we can do that vi
CC'ing Andreas Färber. Could you please give a quick look below at the
way the iothread object is instantiate and destroyed? I am no object
model expert and would appreaciate a second opinion.
On Wed, 21 Jun 2017, Paul Durrant wrote:
> This patch allocates an IOThread object for each xen_disk ins
i don't use kvm/qemu any more and so don't have a means
to determine if this is still an issue or not so please
presume fixed, i guess
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1047470
Title:
q
On Thu, 22 Jun 2017 19:34:58 +0100
"Dr. David Alan Gilbert" wrote:
> * Peter Maydell (peter.mayd...@linaro.org) wrote:
> > On 22 June 2017 at 19:08, Thomas Huth wrote:
> > > On 22.06.2017 19:50, Dr. David Alan Gilbert wrote:
> > >> Could do; I'm just not finding tiny header files with one or
* Eduardo Habkost (ehabk...@redhat.com) wrote:
> On Thu, Jun 22, 2017 at 01:14:58PM +0100, Dr. David Alan Gilbert wrote:
> > * Eduardo Habkost (ehabk...@redhat.com) wrote:
> > > The new flag will make qemu_ram_free() discard the contents of the
> > > block. It will be used to let QEMU be configure
On Thu, Jun 22, 2017 at 08:15:58AM +0200, jean-philippe menil wrote:
> 2017-06-06 1:52 GMT+02:00 Michael S. Tsirkin :
>
> On Mon, Jun 05, 2017 at 05:08:25AM +0300, Michael S. Tsirkin wrote:
> > On Mon, Jun 05, 2017 at 12:48:53AM +0200, Jean-Philippe Menil wrote:
> > > Hi,
> > >
>
On Thu, 22 Jun 2017, Jan Beulich wrote:
> >>> On 21.06.17 at 20:46, wrote:
> > On Wed, 21 Jun 2017, Jan Beulich wrote:
> >> >>> On 20.06.17 at 23:48, wrote:
> >> > On Tue, 20 Jun 2017, Jan Beulich wrote:
> >> >> @@ -36,13 +33,7 @@ struct blkif_x86_32_request_discard {
> >> >> blkif_sector_t
On Thu, Jun 22, 2017 at 02:41:37PM +0200, Marc-André Lureau wrote:
> I used the clang-tidy qemu-round check to generate the fix:
> https://github.com/elmarco/clang-tools-extra
>
> Signed-off-by: Marc-André Lureau
Reviewed-by: Michael S. Tsirkin
> ---
> hw/virtio/vhost.c | 2 +-
> 1 file chang
OK, got your point ... but AFAIK the vmware display device in QEMU is
pretty much unmaintened anyway, so unless someone steps up and takes
care of this device, I think the WONT-FIX status is appropriate for this
bug.
--
You received this bug notification because you are a member of qemu-
devel-ml
Public bug reported:
I am experimenting with this OS https://github.com/phil-opp/blog_os and
spotted a weird behavior with qemu.
I am looking at code that does transition from 32bit mode to 64bit mode.
Right now it does 'jmp $SELECTOR,64bitfunction'. https://github.com
/phil-
opp/blog_os/blob/557
* Peter Maydell (peter.mayd...@linaro.org) wrote:
> On 22 June 2017 at 19:08, Thomas Huth wrote:
> > On 22.06.2017 19:50, Dr. David Alan Gilbert wrote:
> >> Could do; I'm just not finding tiny header files with one or
> >> two entries each that useful.
>
> Well, it means that the bulk of code tha
On Thu, Jun 22, 2017 at 21:06:34 +0300, Lluís Vilanova wrote:
> Please ignore, I'm having problems with my mail server and there's patches
> being
> dropeed.
Can you post a public "v7" branch we can pull from?
Thanks,
E.
Also http://airlied.livejournal.com/69291.html
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1037606
Title:
vmwgfx does not work with kvm vmware vga
Status in Linux:
Confirmed
Status in QEMU:
The kernel bugzilla response is:
The vmwgfx kernel module does not support devices without the pitchlock
capability. Sorry. In that case you need to use the xf86-video-vmware
driver standalone without kernel modesetting.
So presumably this is some capability to be added to the qemu device
--
Yo
qemu-backup will be a command-line tool for performing full and incremental
disk backups on running VMs. It is intended as a reference implementation for
management stack and backup developers to see QEMU's backup features in action.
The following commit is an initial implementation of manpage
On 22 June 2017 at 19:08, Thomas Huth wrote:
> On 22.06.2017 19:50, Dr. David Alan Gilbert wrote:
>> Could do; I'm just not finding tiny header files with one or
>> two entries each that useful.
Well, it means that the bulk of code that doesn't care about the
types doesn't get its compilation fra
On 22.06.2017 19:50, Dr. David Alan Gilbert wrote:
> * Greg Kurz (gr...@kaod.org) wrote:
>> On Thu, 22 Jun 2017 18:25:55 +0100
>> "Dr. David Alan Gilbert" wrote:
>>
>>> * Peter Maydell (peter.mayd...@linaro.org) wrote:
On 22 June 2017 at 18:03, Juan Quintela wrote:
> Greg Kurz wrote:
Please ignore, I'm having problems with my mail server and there's patches being
dropeed.
Thanks,
Lluis
Lluís Vilanova writes:
> This series proposes a generic (target-agnostic) instruction translation
> framework.
> It basically provides a generic main loop for instruction disassembly, whic
Please ignore, I'm having problems with my mail server and there's patches being
dropeed.
Thanks,
Lluis
Lluís Vilanova writes:
> This series proposes a generic (target-agnostic) instruction translation
> framework.
> It basically provides a generic main loop for instruction disassembly, whic
Please ignore, I'm having problems with my mail server and there's patches being
dropeed.
Thanks,
Lluis
Lluís Vilanova writes:
> This series proposes a generic (target-agnostic) instruction translation
> framework.
> It basically provides a generic main loop for instruction disassembly, whic
Please ignore, I'm having problems with my mail server and there's patches being
dropeed.
Thanks,
Lluis
Lluís Vilanova writes:
> This series proposes a generic (target-agnostic) instruction translation
> framework.
> It basically provides a generic main loop for instruction disassembly, which
On 21 June 2017 at 16:43, Gerd Hoffmann wrote:
> The following changes since commit 8dfaf23ae1f2273a9730a9b309cc8471269bb524:
>
> tcg/tci: fix tcg-interpreter build (2017-06-20 18:39:15 +0100)
>
> are available in the git repository at:
>
> git://git.kraxel.org/qemu tags/usb-20170621-pull-requ
* Greg Kurz (gr...@kaod.org) wrote:
> On Thu, 22 Jun 2017 18:25:55 +0100
> "Dr. David Alan Gilbert" wrote:
>
> > * Peter Maydell (peter.mayd...@linaro.org) wrote:
> > > On 22 June 2017 at 18:03, Juan Quintela wrote:
> > > > Greg Kurz wrote:
> > > >> On Thu, 22 Jun 2017 17:14:08 +0100
> > >
Adds macro QTAILQ_FOREACH_CONTINUE to support incremental list
traversal.
Signed-off-by: Lluís Vilanova
---
include/qemu/queue.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/qemu/queue.h b/include/qemu/queue.h
index 35292c3155..eb2bf9cb1c 100644
--- a/include/qemu/
Incrementally paves the way towards using the generic instruction translation
loop.
Signed-off-by: Lluís Vilanova
---
target/i386/translate.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/target/i386/translate.c b/target/i386/translate.c
index
This series proposes a generic (target-agnostic) instruction translation
framework.
It basically provides a generic main loop for instruction disassembly, which
calls target-specific functions when necessary. This generalization makes
inserting new code in the main loop easier, and helps in keepin
Incrementally paves the way towards using the generic instruction translation
loop.
Signed-off-by: Lluís Vilanova
---
target/i386/translate.c | 48 +++
1 file changed, 36 insertions(+), 12 deletions(-)
diff --git a/target/i386/translate.c b/target/i
Incrementally paves the way towards using the generic instruction translation
loop.
Signed-off-by: Lluís Vilanova
---
target/i386/translate.c | 72 +++
1 file changed, 47 insertions(+), 25 deletions(-)
diff --git a/target/i386/translate.c b/target/i
Incrementally paves the way towards using the generic instruction translation
loop.
Signed-off-by: Lluís Vilanova
---
target/i386/translate.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/target/i386/translate.c b/target/i386/translate.c
index f0d12a3d13..3c7ef4af
Incrementally paves the way towards using the generic instruction translation
loop.
Signed-off-by: Lluís Vilanova
---
target/i386/translate.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/target/i386/translate.c b/target/i386/translate.c
in
On Thu, 22 Jun 2017 18:25:55 +0100
"Dr. David Alan Gilbert" wrote:
> * Peter Maydell (peter.mayd...@linaro.org) wrote:
> > On 22 June 2017 at 18:03, Juan Quintela wrote:
> > > Greg Kurz wrote:
> > >> On Thu, 22 Jun 2017 17:14:08 +0100
> > >> Peter Maydell wrote:
> > >>
> > >>> On 22 June
Incrementally paves the way towards using the generic instruction translation
loop.
Signed-off-by: Lluís Vilanova
---
target/i386/translate.c | 43 ---
1 file changed, 24 insertions(+), 19 deletions(-)
diff --git a/target/i386/translate.c b/target/i386/
Signed-off-by: Lluís Vilanova
---
include/exec/gen-icount.h |6 +++--
target/alpha/translate.c | 14 ++--
target/arm/translate-a64.c| 10 -
target/arm/translate.c| 10 -
target/cris/translate.c |6 +++--
target/hppa/translate.c
Signed-off-by: Lluís Vilanova
---
Makefile.target|1
include/exec/gen-icount.h |2
include/exec/translate-block.h | 125 +++
include/qom/cpu.h | 22 +
translate-block.c | 185 +
This series proposes a generic (target-agnostic) instruction translation
framework.
It basically provides a generic main loop for instruction disassembly, which
calls target-specific functions when necessary. This generalization makes
inserting new code in the main loop easier, and helps in keepin
Adds macro QTAILQ_FOREACH_CONTINUE to support incremental list
traversal.
Signed-off-by: Lluís Vilanova
---
include/qemu/queue.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/qemu/queue.h b/include/qemu/queue.h
index 35292c3155..eb2bf9cb1c 100644
--- a/include/qemu/
Signed-off-by: Lluís Vilanova
---
Makefile.target|1
include/exec/gen-icount.h |2
include/exec/translate-block.h | 125 +++
include/qom/cpu.h | 22 +
translate-block.c | 185 +
Needed to implement a target-agnostic gen_intermediate_code() in the
future.
Signed-off-by: Lluís Vilanova
Reviewed-by: David Gibson
Reviewed-by: Richard Henderson
---
include/exec/exec-all.h |2 +-
target/alpha/translate.c | 11 +--
target/arm/translate.c| 2
Adds macro QTAILQ_FOREACH_CONTINUE to support incremental list
traversal.
Signed-off-by: Lluís Vilanova
---
include/qemu/queue.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/qemu/queue.h b/include/qemu/queue.h
index 35292c3155..eb2bf9cb1c 100644
--- a/include/qemu/
This series proposes a generic (target-agnostic) instruction translation
framework.
It basically provides a generic main loop for instruction disassembly, which
calls target-specific functions when necessary. This generalization makes
inserting new code in the main loop easier, and helps in keepin
On 06/22/2017 02:41 AM, David Hildenbrand wrote:
By adding idte, we are now able to expose the DAT-enhancement facility
to our guest. Also, properly simulate and expose the local-tlb-clearing
facility.
To improve the TLB flushing, we will have to remember each used table (or
at least a hash!) fo
Signed-off-by: Lluís Vilanova
---
include/exec/gen-icount.h |6 +++--
target/alpha/translate.c | 14 ++--
target/arm/translate-a64.c| 10 -
target/arm/translate.c| 10 -
target/cris/translate.c |6 +++--
target/hppa/translate.c
Needed to implement a target-agnostic gen_intermediate_code() in the
future.
Signed-off-by: Lluís Vilanova
Reviewed-by: David Gibson
Reviewed-by: Richard Henderson
---
include/exec/exec-all.h |2 +-
target/alpha/translate.c | 11 +--
target/arm/translate.c| 2
Signed-off-by: Lluís Vilanova
---
Makefile.target|1
include/exec/gen-icount.h |2
include/exec/translate-block.h | 125 +++
include/qom/cpu.h | 22 +
translate-block.c | 185 +
Incrementally paves the way towards using the generic instruction translation
loop.
Signed-off-by: Lluís Vilanova
---
target/i386/translate.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/target/i386/translate.c b/target/i386/translate.c
in
This series proposes a generic (target-agnostic) instruction translation
framework.
It basically provides a generic main loop for instruction disassembly, which
calls target-specific functions when necessary. This generalization makes
inserting new code in the main loop easier, and helps in keepin
Adds macro QTAILQ_FOREACH_CONTINUE to support incremental list
traversal.
Signed-off-by: Lluís Vilanova
---
include/qemu/queue.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/qemu/queue.h b/include/qemu/queue.h
index 35292c3155..eb2bf9cb1c 100644
--- a/include/qemu/
On Thu, Jun 22, 2017 at 12:25:30PM +0800, Peter Xu wrote:
> On Wed, Jun 21, 2017 at 09:23:11AM -0300, Eduardo Habkost wrote:
> > On Wed, Jun 21, 2017 at 03:52:00PM +0800, Peter Xu wrote:
[...]
> > > diff --git a/vl.c b/vl.c
> > > index 59fea15..4452d7a 100644
> > > --- a/vl.c
> > > +++ b/vl.c
> > >
On Thu, Jun 22, 2017 at 01:14:58PM +0100, Dr. David Alan Gilbert wrote:
> * Eduardo Habkost (ehabk...@redhat.com) wrote:
> > The new flag will make qemu_ram_free() discard the contents of the
> > block. It will be used to let QEMU be configured to avoid flushing file
> > contents to disk when exit
On Thu, 22 Jun 2017 22:42:19 +0530
Nitin Saxena wrote:
> Thanks Alex.
>
> >> Without an iommu in the VM, you'd be limited to no-iommu support for VM
> >> userspace,
> So are you trying to say VFIO NO-IOMMU should work inside VM. Does
> that mean VFIO NO-IOMMU in VM and VFIO IOMMU in host for
* Peter Maydell (peter.mayd...@linaro.org) wrote:
> On 22 June 2017 at 18:03, Juan Quintela wrote:
> > Greg Kurz wrote:
> >> On Thu, 22 Jun 2017 17:14:08 +0100
> >> Peter Maydell wrote:
> >>
> >>> On 22 June 2017 at 17:06, Greg Kurz wrote:
> >>> > Function types cannot reside in the same sorted
On 22 June 2017 at 18:03, Juan Quintela wrote:
> Greg Kurz wrote:
>> On Thu, 22 Jun 2017 17:14:08 +0100
>> Peter Maydell wrote:
>>
>>> On 22 June 2017 at 17:06, Greg Kurz wrote:
>>> > Function types cannot reside in the same sorted list as opaque types since
>>> > they may depend on a type whic
Thanks Alex.
>> Without an iommu in the VM, you'd be limited to no-iommu support for VM
>> userspace,
So are you trying to say VFIO NO-IOMMU should work inside VM. Does
that mean VFIO NO-IOMMU in VM and VFIO IOMMU in host for same device
is a legitimate configuration? I did tried this configurati
* Halil Pasic (pa...@linux.vnet.ibm.com) wrote:
>
>
> On 06/22/2017 10:22 AM, Dr. David Alan Gilbert wrote:
> > * Halil Pasic (pa...@linux.vnet.ibm.com) wrote:
> >>
> >>
> >> On 06/08/2017 01:05 PM, Halil Pasic wrote:
> >>>
> >>>
> >>> On 06/07/2017 11:51 AM, Dr. David Alan Gilbert wrote:
>
Greg Kurz wrote:
> On Thu, 22 Jun 2017 17:14:08 +0100
> Peter Maydell wrote:
>
>> On 22 June 2017 at 17:06, Greg Kurz wrote:
>> > Function types cannot reside in the same sorted list as opaque types since
>> > they may depend on a type which would be defined later.
>> >
>> > Of course, the same
[cc +qemu-devel, +peterx]
On Thu, 22 Jun 2017 22:18:06 +0530
Nitin Saxena wrote:
> Hi,
>
> I have a PCI device connected as an endpoint to Intel host machine.
> The requirement is to run dpdk like user space data path application
> in VM using PCI PF passthrough (SRIOV disabled). This applicati
Am 16.06.2017 um 19:36 hat Kevin Wolf geschrieben:
> The qed block driver is one of the last remaining block drivers that use the
> AIO callback style interfaces. This series converts it to the coroutine model
> that other drivers are using and removes some AIO functions from the block
> layer API
On Thu, 22 Jun 2017 17:14:08 +0100
Peter Maydell wrote:
> On 22 June 2017 at 17:06, Greg Kurz wrote:
> > Function types cannot reside in the same sorted list as opaque types since
> > they may depend on a type which would be defined later.
> >
> > Of course, the same problem could arise if a fun
On 22.06.2017 17:49, Kevin Wolf wrote:
Am 22.06.2017 um 15:54 hat Pavel Butsykin geschrieben:
On 22.06.2017 01:17, Max Reitz wrote:
On 2017-06-13 14:16, Pavel Butsykin wrote:
The flag as additional precaution of data loss. Perhaps in the future the
operation shrink without this flag will be ba
On Thu, Jun 22, 2017 at 12:54 PM, Peter Maydell
wrote:
> On 5 June 2017 at 15:29, Michael Tokarev wrote:
[...]
>> $ ../configure --disable-system --disable-linux-user --static
>> $ make V=1
>> ...
>
> Why are you trying to build with both system emulation QEMU
> and linux-user QEMU disabled anywa
On Thu, 22 Jun 2017 16:38:45 +0200
Markus Armbruster wrote:
> Pradeep Jagadeesh writes:
>
> > This patch factor out the duplicate throttle code that was present in
> > block and fsdev devices.
> >
> > Signed-off-by: Pradeep Jagadeesh
> > ---
> > blockdev.c | 44 +-
Se non visualizzi correttamente questa email clicca:http://email.mailtoshop.com/c/eJwlj7FuxCAQRL8GuiBYYLELCisn_0LKCMP6TA4b5w5b-fw4ijTF6BWjN8nPcUbLswepnEQA2QFqK5zslBOoFbqhu9mhHw30mhm5hlxafS11F7GufPExzDIgWGMQrSPrlIlA0RAqmFxMfPVgetdbyYtfWtuZHhiMV9okvo4cKaTzb-si7yXHhwiv5YfpMeTE9G0vxACn_55oP2V88Kf_pvV4S
On Wed, Jun 21, 2017 at 8:22 AM, Sam wrote:
> Thank you~
>
> 1. We have a compare test on qemu-kvm enviroment with huge page and without
> huge page. Qemu start process is much longer in huge page enviromwnt. And I
> write an email titled with '[DPDK-memory] how qemu waste such long time
> under
On 22 June 2017 at 17:06, Greg Kurz wrote:
> Function types cannot reside in the same sorted list as opaque types since
> they may depend on a type which would be defined later.
>
> Of course, the same problem could arise if a function type depends on
> another function type with greater alphabeti
Function types cannot reside in the same sorted list as opaque types since
they may depend on a type which would be defined later.
Of course, the same problem could arise if a function type depends on
another function type with greater alphabetical order. Hopefully we
don't have that at this time.
On 06/22/2017 02:41 AM, David Hildenbrand wrote:
Let's allow to enable it for the qemu cpu model and correctly emulate
it.
Signed-off-by: David Hildenbrand
---
target/s390x/cpu_models.c | 1 +
target/s390x/mem_helper.c | 2 --
target/s390x/translate.c | 6 +-
3 files changed, 6 inserti
On 05/30/2017 10:23 AM, Michal Privoznik wrote:
> For more description see patch 3. Long story short, if the bridge helper runs
> with SUID, the mechanism we rely on (DAC denying access to ACL files) does not
> work.
>
> Michal Privoznik (3):
> qemu-bridge-helper: Reverse return value setting lo
On 5 June 2017 at 15:29, Michael Tokarev wrote:
> 31.05.2017 15:00, Kamil Rytarowski wrote:
>> Currently ivshmem requires eventfd() which is Linux specific.
>> Do not and build it unconditionally on every Linux/BSD/Solaris.
>>
>> This patch indirectly fixes build failure on NetBSD, where these too
On Jun 22, 2017, at 3:25 AM, Peter Maydell wrote:
On 22 June 2017 at 03:54, G 3 wrote:
The advantage a test image would have is the user doesn't have to
worry
about compiling a test using a cross compiler. Everything the user
would
need to test QEMU is already inside the image file (hopef
On Thu, Jun 22, 2017 at 12:13 PM, Alex Bennée wrote:
> Now we've been running shippable for a while is it worth turning on the
> IRC notifications?
What about moving such bot/scripts notifications in another channel
like #QEMU-notifications?
It is often hard to follow 3 concurrent topics while th
Philippe Mathieu-Daudé writes:
> On 06/22/2017 11:09 AM, Peter Maydell wrote:
>> On 21 June 2017 at 15:47, Alex Bennée wrote:
> [...]>> We add the following cross-compile targets:
>>>- mipsel-softmmu,mipsel-linux-user,mips64el-linux-user
>>>- armeb-linux-user
>>>
>>> While I was rolling
Hi Markus,
Thank you for the input.
> However, your query-memory looks like it could fail.
With the latest version of a patch (
http://lists.nongnu.org/archive/html/qemu-devel/2017-06/msg03475.html)
"query-memory" can fail only in two cases:
a) if in QOM there is an object of type of TYPE_PC_DI
1 - 100 of 226 matches
Mail list logo
