On Tue, 09/11 11:27, David Gibson wrote:
> On Mon, Sep 10, 2018 at 09:46:30PM +0100, Mark Cave-Ayland wrote:
> > On some early machines the on-board PCI devices IRQs are wired directly to
> > the interrupt controller instead of via the PCI host bridge.
> >
> > Add an optional external IRQ that if
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> On 10/09/2018 07:36, Pavel Dovgalyuk wrote:
> > After locking here,
> >
> >> if (runstate_is_running()) {
> >> int64_t clock = REPLAY_CLOCK(REPLAY_CLOCK_VIRTUAL_RT,
> >> cpu_get_clock_locked());
The new layout using static IRQ number does not leave much space to
the dynamic MSI range, only 0x100 IRQ numbers. Increase the total
number of IRQS for newer machines and introduce a legacy XICS backend
for pre-3.1 machines to maintain compatibility.
For the old backend, provide a 'nr_msis' value
The number of MSI interrupts a sPAPR machine can allocate is in direct
relation with the number of interrupts of the sPAPRIrq backend. Define
statically this value at the sPAPRIrq class level and use it for the
"ibm,pe-total-#msi" property of the sPAPR PHB.
According to the PAPR specs, "ibm,pe-tot
Hello,
This series adds a new sPAPRIrq backend increasing the number of
available IRQ numbers in pseries-3.1 machines. This change is an
opportunity to also fix the "ibm,pe-total-#msi" and remove the old
XICS_IRQS_SPAPR definition.
Thanks,
C.
Changes since v1:
- merge patch 1 and 3
Cédric L
On Mon, Sep 10, 2018 at 01:29:01PM +0200, Roman Kapl wrote:
> External PID is a mechanism present on BookE 2.06 that enables application to
> store/load data from different address spaces. There are special version of
> some
> instructions, which operate on alternate address space, which is descri
This series enables filename parsing on open, on the old key/value pair.
Recent changes to new option formats for rbd broke some images. See
Patch 2 for more details.
Jeff Cody (2):
block/rbd: pull out qemu_rbd_convert_options
block/rbd: Attempt to parse legacy filenames
block/rbd.c | 66 ++
When we converted rbd to get rid of the older key/value-centric
encoding format, we broke compatibility with image files with backing
file strings encoded in the old format.
This leaves a bit of an ugly conundrum, and a hacky solution.
If the initial attempt to parse the "proper" options fails, i
Code movement to pull the conversion from Qdict to BlockdevOptionsRbd
into a helper function.
Signed-off-by: Jeff Cody
---
block/rbd.c | 36
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/block/rbd.c b/block/rbd.c
index ca8e5bbace..a8e79d01d2
Hi,
> > type_register_static(&vfio_pci_dev_info);
> > +type_register_static(&vfio_pci_ramfb_dev_info);
> My concern here is still all of the extra tooling that needs to be
> added to management layers above QEMU for this device that exists only
> because we can't hotplug the primary di
On 09/11/2018 03:50 AM, David Gibson wrote:
> On Mon, Sep 10, 2018 at 01:02:22PM +0200, Cédric Le Goater wrote:
>> The "ibm,pe-total-#msi" property of the sPAPR PHB defines the number
>> of allocatable MSI interrupts. This is currently set to XICS_IRQS_SPAPR
>> which covers the full IRQ number spac
On 09/11/2018 03:48 AM, David Gibson wrote:
> On Mon, Sep 10, 2018 at 01:02:20PM +0200, Cédric Le Goater wrote:
> 11;rgb://> The number of MSI interrupts a sPAPR machine can
> allocate is in direct
>> relation with the number of interrupts of the sPAPRIrq backend. Define
>> statically
On Mon, Sep 10, 2018 at 01:02:21PM +0200, Cédric Le Goater wrote:
> The new layout using static IRQ number does not leave much space to
> the dynamic MSI range, only 0x100 IRQ numbers. Increase the total
> number of IRQS for newer machines and introduce a legacy XICS backend
> for pre-3.1 machines
On Mon, Sep 10, 2018 at 01:02:22PM +0200, Cédric Le Goater wrote:
> The "ibm,pe-total-#msi" property of the sPAPR PHB defines the number
> of allocatable MSI interrupts. This is currently set to XICS_IRQS_SPAPR
> which covers the full IRQ number space of the machine. This is wrong.
>
> Fix the def
On Mon, Sep 10, 2018 at 01:02:20PM +0200, Cédric Le Goater wrote:
11;rgb://> The number of MSI interrupts a sPAPR machine can
allocate is in direct
> relation with the number of interrupts of the sPAPRIrq backend. Define
> statically this value at the sPAPRIrq class level.
>
> Signed-
On Mon, Sep 10, 2018 at 08:32:40AM +0200, Thomas Huth wrote:
> On 2018-09-10 06:25, David Gibson wrote:
> > On Fri, Sep 07, 2018 at 08:39:52AM -0500, Eric Blake wrote:
> >> On 09/07/2018 02:31 AM, David Gibson wrote:
> >>> From: Thomas Huth
> >>>
> >>> There is no known available OS for ppc around
On Mon, Sep 10, 2018 at 07:24:47PM +0200, Cédric Le Goater wrote:
> On 09/10/2018 05:02 PM, Greg Kurz wrote:
> > On Mon, 10 Sep 2018 13:02:19 +0200
> > Cédric Le Goater wrote:
> >
> >> Hello,
> >>
> >> This series adds a new sPAPRIrq backend increasing the number of
> >> available IRQ numbers in
This is the program I used to check the behavior of SEEK_DATA and SEEK_HOLE.
#define _FILE_OFFSET_BITS 64
#define _LARGEFILE64_SOURCE 1
#include
#include
#include
#include
#include
#include
#include
#include
/*
* This function is suitable for macOS and Solaris' lseek behavior,
* since s
On Mon, 2018-09-10 at 14:38 -0300, Eduardo Habkost wrote:
> On Thu, Sep 06, 2018 at 06:00:29AM +, Hu, Robert wrote:
> >
> > >
> > > Yeah, since this type is used in the qom-get backdoor that evades
> > > introspection,
> > > it's even more important that you follow the backwards-
> > > compat
On Mon, Sep 10, 2018 at 09:46:30PM +0100, Mark Cave-Ayland wrote:
> On some early machines the on-board PCI devices IRQs are wired directly to
> the interrupt controller instead of via the PCI host bridge.
>
> Add an optional external IRQ that if wired up via qdev will replace the
> in-built PCI I
On Mon, Sep 10, 2018 at 09:46:31PM +0100, Mark Cave-Ayland wrote:
> Whilst the PReP specification describes how all PCI IRQs are routed via IRQ
> 15 on the interrupt controller, the real 40p machine has a routing quirk in
> that the LSI SCSI device is routed directly to IRQ 13.
>
> Enable the exte
s32c1i must load and store value with target endianness, not host.
This results in an infinite loop in atomic cmpxchg sequences when target
endianness doesn't match host endianness.
Fixes: 9fb40342d4b3 ("target/xtensa: support MTTCG")
Cc: qemu-sta...@nongnu.org
Signed-off-by: Max Filippov
---
ta
Signed-off-by: Emilio G. Cota
---
cpus.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/cpus.c b/cpus.c
index f045416c94..5a16a0186c 100644
--- a/cpus.c
+++ b/cpus.c
@@ -277,7 +277,8 @@ static int64_t cpu_get_icount_raw_locked(void)
static int64_t cpu
Signed-off-by: Emilio G. Cota
---
cpus.c | 4
1 file changed, 4 deletions(-)
diff --git a/cpus.c b/cpus.c
index ebc13bac2d..38dabb138d 100644
--- a/cpus.c
+++ b/cpus.c
@@ -250,16 +250,12 @@ void cpu_update_icount(CPUState *cpu)
int64_t executed = cpu_get_icount_executed(cpu);
cpu-
With the seqlock, we either have to use atomics to remain
within defined behaviour (and note that 64-bit atomics aren't
always guaranteed to compile, irrespective of __nocheck), or
drop the atomics and be in undefined behaviour territory.
Fix it by dropping the seqlock and using atomic64 accessors
- With CONFIG_ATOMIC64:
$ tests/atomic64-bench -n 1
Throughput: 310.40 Mops/s
- Without:
$ tests/atomic64-bench -n 1
Throughput: 149.08 Mops/s
Signed-off-by: Emilio G. Cota
---
tests/atomic64-bench.c | 171 +
tests/Makefile.include |
v1: https://lists.gnu.org/archive/html/qemu-devel/2018-09/msg00237.html
Changes since v1:
- Add Alex's R-b tags
- Introduce atomic64 to just use a spinlock when doing atomic_set/read
on i64's and u64's if !CONFIG_ATOMIC64, just like the kernel does.
+ Add a benchmark for these types of access
Reviewed-by: Alex Bennée
Signed-off-by: Emilio G. Cota
---
include/qemu/atomic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/qemu/atomic.h b/include/qemu/atomic.h
index c34c2f78c4..f6993a8fb1 100644
--- a/include/qemu/atomic.h
+++ b/include/qemu/atomic.h
@@ -98,7
Complete xtensa-semi chardev console implementation: allow reading input
characters from file descriptor 0 and call sys_select_one simcall on it.
Signed-off-by: Max Filippov
---
Changes v1->v2:
- put CharBackend and input buffer into the XtensaSimConsole structure
target/xtensa/xtensa-semi.c |
This introduces read/set accessors for int64_t and uint64_t.
Signed-off-by: Emilio G. Cota
---
include/qemu/atomic.h | 34 ++
util/atomic64.c | 83 +++
util/cacheinfo.c | 3 ++
util/Makefile.objs| 1 +
4 files changed, 121
Signed-off-by: Emilio G. Cota
---
configure | 2 ++
1 file changed, 2 insertions(+)
diff --git a/configure b/configure
index 58862d2ae8..f715252c9f 100755
--- a/configure
+++ b/configure
@@ -7025,12 +7025,14 @@ TARGET_ABI_DIR=""
case "$target_name" in
i386)
+mttcg="yes"
gdb_xml_fi
Signed-off-by: Emilio G. Cota
---
include/qemu/osdep.h | 2 ++
util/cacheinfo.c | 5 +
2 files changed, 7 insertions(+)
diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
index a91068df0e..a746a5e531 100644
--- a/include/qemu/osdep.h
+++ b/include/qemu/osdep.h
@@ -570,6 +570,8 @@ e
Needed for MTTCG.
Note that in user-mode, code generation is serialized by
mmap_lock, so making these variables per-thread would
just waste TLS space.
Acked-by: Alex Bennée
Signed-off-by: Emilio G. Cota
---
target/i386/translate.c | 24
1 file changed, 16 insertions(+)
Signed-off-by: Emilio G. Cota
---
cpus.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/cpus.c b/cpus.c
index 38dabb138d..f045416c94 100644
--- a/cpus.c
+++ b/cpus.c
@@ -252,8 +252,8 @@ void cpu_update_icount(CPUState *cpu)
seqlock_write_lock(&timers_state.vm_c
We forgot to initialize the spinlock introduced in 94377115b2
("cpus: protect TimerState writes with a spinlock", 2018-08-23).
Fix it.
Reviewed-by: Alex Bennée
Signed-off-by: Emilio G. Cota
---
cpus.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/cpus.c b/cpus.c
index 8ee6e5db93..ebc13bac
To avoid undefined behaviour.
Note that these "atomics" are atomic in the "access once" sense.
The variables are updated by a single thread at a time, so no
"full" atomics are necessary.
Signed-off-by: Emilio G. Cota
---
tests/test-rcu-list.c | 20 +++-
1 file changed, 11 insert
On 07/06/2018 07:36 AM, Vladimir Sementsov-Ogievskiy wrote:
> Rename block-dirty-bitmap-clear transaction handlers to reuse them for
> x-block-dirty-bitmap-merge transaction in the following patch.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> blockdev.c | 8
> 1 file chang
We actually don't restore anything just yet, so this commit message is a
little off I think.
On 07/06/2018 07:36 AM, Vladimir Sementsov-Ogievskiy wrote:
> Add backup parameter to bdrv_merge_dirty_bitmap() and refactor
> bdrv_undo_clear_dirty_bitmap() to use it both for undo clean and merge.
>
> S
On 08/14/2018 08:14 AM, Vladimir Sementsov-Ogievskiy wrote:
> This reverts commit a33fbb4f8b64226becf502a123733776ce319b24.
>
> The functionality is unused.
>
> Note: in addition to automatic revert, drop second parameter in
> hbitmap_iter_next() call from hbitmap_next_dirty_area() too.
>
Hm
On 08/14/2018 08:14 AM, Vladimir Sementsov-Ogievskiy wrote:
> Use bdrv_dirty_bitmap_next_dirty_area() instead of
> bdrv_dirty_iter_next_area(), because of the following problems of
> bdrv_dirty_iter_next_area():
>
> 1. Using HBitmap iterators we should carefully handle unaligned offset,
> as fi
s/drity-bitmap/dirty-bitmap/g
On 07/06/2018 07:36 AM, Vladimir Sementsov-Ogievskiy wrote:
> Move checks from qmp_x_block_dirty_bitmap_merge() to
> bdrv_merge_dirty_bitmap(), to share them with dirty bitmap merge
> transaction action in future commit.
>
> Note: for now, only qmp_x_block_dirty_bitm
On some early machines the on-board PCI devices IRQs are wired directly to
the interrupt controller instead of via the PCI host bridge.
Add an optional external IRQ that if wired up via qdev will replace the
in-built PCI IRQ.
Signed-off-by: Mark Cave-Ayland
---
hw/scsi/lsi53c895a.c | 16 +++
Whilst the PReP specification describes how all PCI IRQs are routed via IRQ
15 on the interrupt controller, the real 40p machine has a routing quirk in
that the LSI SCSI device is routed directly to IRQ 13.
Enable the external IRQ for the LSI SCSI device by wiring up the IRQ with
qdev to the relev
According to the PReP specification section 6.1.6 "System Interrupt
Assignments", all PCI interrupts are routed via IRQ 15.
In the case of the 40p machine this isn't quite true in that it has a routing
quirk: the LSI SCSI device is always routed to IRQ 13. At least Linux and
NetBSD compare the mod
On 08/14/2018 08:14 AM, Vladimir Sementsov-Ogievskiy wrote:
> Signed-off-by: Vladimir Sementsov-Ogievskiy
ACK, and
Tested-by: John Snow
> ---
> tests/test-hbitmap.c | 106
> +++
> 1 file changed, 106 insertions(+)
>
> diff --git a/tests/test
On 08/14/2018 08:14 AM, Vladimir Sementsov-Ogievskiy wrote:
> The function alters bdrv_dirty_iter_next_area(), which is wrong and
> less efficient (see further commit
> "block/mirror: fix and improve do_sync_target_write" for description).
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
On 10/09/18 04:48, David Gibson wrote:
> On Sat, Sep 08, 2018 at 10:08:20AM +0100, Mark Cave-Ayland wrote:
>> Whilst the PReP specification describes how all PCI IRQs are routed via IRQ
>> 15 on the interrupt controller, the real 40p machine has routing quirk in
>> that the LSI SCSI device is rout
On 9/10/18 2:25 PM, John Snow wrote:
Hi, has this series been superseded or do we need a respin for 3.1?
Needs a respin.
There are two issues still to be solved:
1. Asking the top-most block layer for its alignment isn't necessarily
right for qemu as server. If we have:
backing (512) <- a
Public bug reported:
This bug is reported against the 3.0 release.
I noticed that the GCC test gcc.dg/torture/tls/tls-test.c is failing
when run in user-mode qemu for nios2 target. The problem appears to be
that the thread-related syscalls are unimplemented in qemu. Here is
output from running
Hi, has this series been superseded or do we need a respin for 3.1?
(It's not quite been a month, but it caught my eye.)
--js
On 08/02/2018 10:48 AM, Eric Blake wrote:
> Rich reported a bug when using qemu as client to nbdkit serving
> a non-sector-aligned image; in turn, I found a second bug wi
On 08/09/2018 09:44 AM, Alberto Garcia wrote:
> The cache-clean-interval option is used to periodically release unused
> entries from the L2 and refcount caches. Dirty cache entries are left
> untouched, even if they are otherwise valid candidates for removal.
>
> This patch allows releasing th
Precomputing the hash values allows us to perform more frequent
accesses to the hash table, thereby reaching higher throughputs.
We keep the old behaviour by default, since (1) we might confuse
users if they measured a speedup without changing anything in
the QHT implementation, and (2) benchmarki
This improves coverage by one (!) LoC in qht.c, bringing the
coverage rate up from 90.00% to 90.28%.
Reviewed-by: Alex Bennée
Signed-off-by: Emilio G. Cota
---
tests/test-qht.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/tests/test-qht.c b/tests/test-qht.c
Accessing the HT from an iterator results almost always
in a deadlock. Given that only one qht-internal function
uses this argument, drop it from the interface.
Suggested-by: Alex Bennée
Signed-off-by: Emilio G. Cota
---
include/qemu/qht.h| 5 ++---
accel/tcg/translate-all.c | 6 ++---
Perform first the tests that exercise code paths that are
easier to hit at small table sizes, and then resize the table
to speed up subsequent tests. If this resize is not too large,
we can make the test faster with no code coverage loss.
- With gcov enabled:
Before: 20.568s, 90.28% qht.c coverag
This improves qht.c code coverage from 89.44% to 90.00%.
Reviewed-by: Alex Bennée
Signed-off-by: Emilio G. Cota
---
tests/test-qht.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/tests/test-qht.c b/tests/test-qht.c
index 283fb3db39..05b1d6807a 1
These functions do not modify their @ht or @bucket arguments.
Constify those arguments.
Signed-off-by: Emilio G. Cota
---
util/qht.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/util/qht.c b/util/qht.c
index 4378775d68..aa51be3c52 100644
--- a/util/qht.c
Signed-off-by: Emilio G. Cota
---
include/qemu/qht.h | 2 +-
util/qht.c | 8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/qemu/qht.h b/include/qemu/qht.h
index 2e2d6bca93..758c7ac6c8 100644
--- a/include/qemu/qht.h
+++ b/include/qemu/qht.h
@@ -211,7 +211
seqlock_read_begin takes a const param since c04649eeea
("seqlock: constify seqlock_read_begin", 2018-08-23), so
we can constify the entire lookup.
Signed-off-by: Emilio G. Cota
---
include/qemu/qht.h | 4 ++--
util/qht.c | 16
2 files changed, 10 insertions(+), 10 dele
Signed-off-by: Emilio G. Cota
---
util/qht.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/util/qht.c b/util/qht.c
index 50ed7a2102..3564a7e20f 100644
--- a/util/qht.c
+++ b/util/qht.c
@@ -671,7 +671,7 @@ qht_entry_move(struct qht_bucket *to, int i, struct
qht_bucket *from,
v1: https://github.com/cota/qemu/tree/qht-for-3.1-v2
Changes since v1:
- Added Alex's R-b tags to patches 1-6
- Added a patch to drop *ht from qht_iter and qht_iter_remove,
as suggested by Alex.
- Added some constification patches
- Added a flag to qht-bench to precompute the hashes, which
al
Reviewed-by: Alex Bennée
Signed-off-by: Emilio G. Cota
---
tests/test-qht.c | 50 ++--
1 file changed, 48 insertions(+), 2 deletions(-)
diff --git a/tests/test-qht.c b/tests/test-qht.c
index dda6a067be..283fb3db39 100644
--- a/tests/test-qht.c
+++ b/t
Reviewed-by: Alex Bennée
Signed-off-by: Emilio G. Cota
---
util/qht.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/util/qht.c b/util/qht.c
index 1e3a072e25..28d9273371 100644
--- a/util/qht.c
+++ b/util/qht.c
@@ -692,8 +692,7 @@ static inline void qht_bucket_remove_en
This currently has no users, but the use case is so common that I
think we must support it.
Note that without the appended we cannot safely remove a set of
elements; a 2-step approach (i.e. qht_iter first, keep track of
the to-be-deleted elements, and then a bunch of qht_remove calls)
would be rac
On Mon, 10 Sep 2018 08:43:40 +0200
Gerd Hoffmann wrote:
> So we have a boot display when using a vgpu as primary display.
>
> Use vfio-pci-ramfb instead of vfio-pci to enable it.
>
> Signed-off-by: Gerd Hoffmann
> ---
> include/hw/vfio/vfio-common.h | 2 ++
> hw/vfio/display.c |
problem solved! :-)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1791680
Title:
network bridge does not work
Status in QEMU:
Invalid
Bug description:
hi there
the network bridge does not
problem solved! :-)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1404278
Title:
tap connections not working on windows host
Status in QEMU:
Fix Released
Bug description:
using latest qemu 2.
On 9/10/18 12:49 PM, Eduardo Habkost wrote:
I was considering something like this:
Signed-off-by: Eduardo Habkost
---
diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
index 060e015be6..74f6a64b8b 100644
--- a/qemu-deprecated.texi
+++ b/qemu-options.hx
@@ -155,8 +155,13 @@ to 4.
F
On 9/4/18 8:22 AM, Igor Mammedov wrote:
-smp [cpus],sockets/cores/threads[,maxcpus] should describe topology
so that total number of logical CPUs [sockets * cores * threads]
would be equal to [maxcpus], however historically we didn't have
such check in QEMU and it is possible to start VM with an
On Thu, Sep 06, 2018 at 10:02:13AM +0200, Igor Mammedov wrote:
> On Wed, 5 Sep 2018 10:45:12 -0300
> Eduardo Habkost wrote:
>
> > On Wed, Sep 05, 2018 at 11:25:11AM +0200, Igor Mammedov wrote:
> > > On Tue, 4 Sep 2018 23:12:55 -0300
> > > Eduardo Habkost wrote:
> > >
> > > > On Tue, Sep 04, 2
On Thu, Sep 06, 2018 at 06:00:29AM +, Hu, Robert wrote:
>
> > -Original Message-
> > From: Eric Blake [mailto:ebl...@redhat.com]
> > Sent: Thursday, September 6, 2018 1:41
> > To: Eduardo Habkost
> > Cc: Robert Hoo ; Paolo Bonzini
> > ; Hu, Robert ; r...@twiddle.net;
> > thomas.lenda.
On 09/10/2018 05:02 PM, Greg Kurz wrote:
> On Mon, 10 Sep 2018 13:02:19 +0200
> Cédric Le Goater wrote:
>
>> Hello,
>>
>> This series adds a new sPAPRIrq backend increasing the number of
>> available IRQ numbers in pseries-3.1 machines. This change is an
>> opportunity to also fix the "ibm,pe-tot
Public bug reported:
This bug is against the 3.0 release.
It appears that the signal handling parts of the nios2 user-mode
emulation have never really been completed or tested. Some examples of
failing tests from the GCC testsuite are gcc.dg/pr78185.c and
gcc.dg/cleanup-10.c.
Some problems I've
On 09/10/2018 11:18 AM, Alex Bennée wrote:
>
> Wei Huang writes:
>
>> Recently a new configure option, CROSS_CC_GUEST, was added to
>> $(TARGET)-softmmu/config-target.mak to support TCG-related tests. This
>> patch tries to leverage this option to support cross compilation when the
>> migrati
static ip does also not work, can't reach other machines in my own
subnet:
qemu-system-arm.exe -M versatilepb -cpu arm1176 -hda
2018-09-03_stretch_inkl_phalcon.img -kernel kernel-qemu-4.4.34-jessie -m
512 -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw
ip=192.168.80.252::192.168.80.1:255.255.25
10.09.2018 19:55, Eric Blake wrote:
On 9/10/18 11:49 AM, Vladimir Sementsov-Ogievskiy wrote:
-int64_t hbitmap_next_zero(const HBitmap *hb, uint64_t start);
+int64_t hbitmap_next_zero(const HBitmap *hb, uint64_t start,
int64_t end);
The interface looks weird because we can define a 'start' tha
On 9/10/18 11:49 AM, Vladimir Sementsov-Ogievskiy wrote:
-int64_t hbitmap_next_zero(const HBitmap *hb, uint64_t start);
+int64_t hbitmap_next_zero(const HBitmap *hb, uint64_t start, int64_t
end);
The interface looks weird because we can define a 'start' that's beyond
the 'end'.
I realize that
Alex Bennée wrote:
D> Wei Huang writes:
>
>> Recently a new configure option, CROSS_CC_GUEST, was added to
>> $(TARGET)-softmmu/config-target.mak to support TCG-related tests. This
>> patch tries to leverage this option to support cross compilation when the
>> migration boot block file is being r
On 10.09.18 17:18, Kevin Wolf wrote:
> Am 09.08.2018 um 23:34 hat Max Reitz geschrieben:
>> Once more, I’ll spare both me and you another iteration of the cover
>> letter, so see here:
>>
>> http://lists.nongnu.org/archive/html/qemu-block/2017-09/msg01030.html
>>
>> (Although this series no longer
08.09.2018 00:49, John Snow wrote:
On 08/14/2018 08:14 AM, Vladimir Sementsov-Ogievskiy wrote:
Add bytes parameter to the function, to limit searched range.
I'm going to assume that Eric Blake has been through here and commented
on the interface itself.
Signed-off-by: Vladimir Sementsov-Ogi
On Mon 10 Sep 2018 05:55:15 PM CEST, Eric Blake wrote:
>> Hm, it actually doesn't crash for me even without the fix. Anyway, I
>> don't have a good idea to make it more likely to crash and it's
>> certainly better than nothing.
>
> Does running the test under valgrind reliably see the use-after-fre
when i install tap driver from https://openvpn.net/index.php/open-
source/downloads.html im able to start with tap01 (when i rename the tap
interface to "tap01"..)
but on start i get an apipa address with that config:
qemu-system-arm.exe -M versatilepb -cpu arm1176 -hda
2018-09-03_stretch_inkl_ph
On Mon, Sep 10, 2018 at 16:41:21 +0100, Alex Bennée wrote:
>
> Emilio G. Cota writes:
>
> > On Mon, Sep 10, 2018 at 12:26:58 +0100, Alex Bennée wrote:
> >>
> >> Emilio G. Cota writes:
> >>
> >> > A few fixes since yesterday's v1:
> >> > https://lists.gnu.org/archive/html/qemu-devel/2018-09/ms
"it works with qemu-w64-setup-20180519.exe"
not really:
J:\Tools\qemu>.\run.bat
J:\Tools\qemu>qemu-system-arm.exe -M versatilepb -cpu arm1176 -hda
2018-09-03_stretch_inkl_phalcon.img -kernel kernel-qe
mu-4.4.34-jessie -m 512 -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw
init=/bin/bash" -no
Wei Huang writes:
> Recently a new configure option, CROSS_CC_GUEST, was added to
> $(TARGET)-softmmu/config-target.mak to support TCG-related tests. This
> patch tries to leverage this option to support cross compilation when the
> migration boot block file is being re-generated:
>
> * The x8
On Fri 07 Sep 2018 02:42:53 PM CEST, Max Reitz wrote:
> The whole purpose of bs->auto_backing_file is so you can compare it
> with bs->backing->bs->filename, see when it differs, and then you know
> that the user has changed the backing file from what it would be based
> on the image header alone (
On 09/10/2018 10:59 AM, Eric Blake wrote:
> On 9/7/18 4:49 PM, John Snow wrote:
>>
>>
>> On 08/14/2018 08:14 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> Add bytes parameter to the function, to limit searched range.
>>>
>>
>> I'm going to assume that Eric Blake has been through here and commented
https://bugs.launchpad.net/qemu/+bug/1404278
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1791680
Title:
network bridge does not work
Status in QEMU:
Invalid
Bug description:
hi there
the
On 9/10/18 4:57 AM, Kevin Wolf wrote:
Am 10.09.2018 um 11:29 hat Alberto Garcia geschrieben:
We just fixed a bug that was causing a use-after-free when QEMU was
unable to create a temporary snapshot. This is a test case for this
scenario.
Signed-off-by: Alberto Garcia
Hm, it actually doesn't
On Mon, Sep 10, 2018 at 01:32:15 +0200, Paolo Bonzini wrote:
> On 03/09/2018 19:18, Emilio G. Cota wrote:
> > Using atomics here is a mistake since they're not guaranteed
> > to compile.
>
> But isn't it technically a C11 data race if you don't use atomics?
Yes, it's undefined behaviour.
> Could
Emilio G. Cota writes:
> On Mon, Sep 10, 2018 at 12:26:58 +0100, Alex Bennée wrote:
>>
>> Emilio G. Cota writes:
>>
>> > A few fixes since yesterday's v1:
>> > https://lists.gnu.org/archive/html/qemu-devel/2018-09/msg00884.html
>> >
>> > - Convert copy_qemu_to_soft80 to qemu_to_soft80, just
Am 09.08.2018 um 23:34 hat Max Reitz geschrieben:
> Once more, I’ll spare both me and you another iteration of the cover
> letter, so see here:
>
> http://lists.nongnu.org/archive/html/qemu-block/2017-09/msg01030.html
>
> (Although this series no longer includes a @base-directory option.)
>
> In
Am 24.08.2018 um 04:43 hat Fam Zheng geschrieben:
> All callers have acquired ctx already. Doing that again results in
> aio_poll() hang. This fixes the problem that a BDRV_POLL_WHILE() in the
> callback cannot make progress because ctx is recursively locked, for
> example, when drive-backup finish
incompatible with windows, right? so i need a linux machine with ethx??
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1791680
Title:
network bridge does not work
Status in QEMU:
Invalid
Bug des
On Mon, Sep 10, 2018 at 12:26:58 +0100, Alex Bennée wrote:
>
> Emilio G. Cota writes:
>
> > A few fixes since yesterday's v1:
> > https://lists.gnu.org/archive/html/qemu-devel/2018-09/msg00884.html
> >
> > - Convert copy_qemu_to_soft80 to qemu_to_soft80, just like the other
> > conversion fu
OK thx.
"The -device option can only be used for pluggable NICs. Boards (e.g.
embedded boards) which feature an on-board NIC cannot be configured with
-device yet, so -net nic,netdev= must be used here instead."
--
You received this bug notification because you are a member of qemu-
devel-ml, wh
what do i need for netdev id? n1 as described in your links does not
work. messsage: "netdev 'n1' not found"
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1791680
Title:
network bridge does not wor
currently, only one nic adapter is enabled on my win10 host: the
ethernet controller.
the other 2, 1x internal wlan and 1x usb wlan is disabled..
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1791680
when i only use "-net nic", i get an apipa address
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1791680
Title:
network bridge does not work
Status in QEMU:
Invalid
Bug description:
hi there
"-nic tap,model=e1000"
-> "Device 'tap' colud not be found
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1791680
Title:
network bridge does not work
Status in QEMU:
Invalid
Bug description:
1 - 100 of 172 matches
Mail list logo
