This patch documents the steps to use virtio pmem.
It also documents other useful information about
virtio pmem e.g use-case, comparison with Qemu NVDIMM
backend and current limitations.
Signed-off-by: Pankaj Gupta
---
docs/virtio-pmem.txt | 65
1 fil
This patch documents the steps to use virtio pmem.
It also documents other useful information about
virtio pmem e.g use-case, comparison with Qemu NVDIMM
backend and current limitations.
Signed-off-by: Pankaj Gupta
---
docs/virtio-pmem.txt | 65
1 fil
Eduardo Habkost writes:
> On Fri, Jul 26, 2019 at 02:05:35PM +0200, Markus Armbruster wrote:
>> In my "build everything" tree, changing hw/qdev-properties.h triggers
>> a recompile of some 2700 out of 6600 objects (not counting tests and
>> objects that don't depend on qemu/osdep.h).
>>
>> Many
Kevin Wolf writes:
> scsi-disks decides whether it has a read-only device by looking at
> whether the BlockBackend specified as drive=... is read-only. In the
> case of an anonymous BlockBackend (with a node name specified in
> drive=...), this is the read-only flag of the attached node. In the c
That is a long list of install commands Hans Peter, wouldn't dependencies just
take care of it as well?
Anyway, I installed the same set of packages and it works fine for me.
Which Ubuntu release are you on?
What machine are you on?
Any further configuration done to libvirt yet?
Maybe a list of a
On Tue, Jul 30, 2019 at 1:52 AM Wei Yang wrote:
>
> Hi, Stefan
>
> Thanks for your comments :-)
>
> On Mon, Jul 29, 2019 at 02:58:59PM +0100, Stefan Hajnoczi wrote:
> >On Wed, Jul 24, 2019 at 03:03:07PM +0800, Wei Yang wrote:
> >> Persistent backend setup requires some knowledge about nvdimm and n
GPIO pins are arranged in groups of 8 pins labeled A,B,..,Y,Z,AA,AB,AC.
(Note that the ast2400 controller only goes up to group AB).
A set has four groups (except set AC which only has one) and is
referred to by the groups it is composed of (eg ABCD,EFGH,...,YZAAAB).
Each set is accessed and contro
The AST2600 has the same sets of 3.6v gpios as the AST2400 plus an
addtional two sets of 1.8V gpios.
Signed-off-by: Rashmica Gupta
---
hw/gpio/aspeed_gpio.c | 186 +-
include/hw/gpio/aspeed_gpio.h | 2 +-
2 files changed, 184 insertions(+), 4 deletions(-
There are a couple of things I'm not confident about here:
- what should be in init vs realize?
- should the irq state be in vmstate?
- is there a better way to do composition of classes (patch 3)?
v3:
- didn't have each gpio set up as an irq
- now can't access set AC on ast2400 (only exists on a
Signed-off-by: Rashmica Gupta
---
hw/arm/aspeed_soc.c | 17 +
include/hw/arm/aspeed_soc.h | 3 +++
2 files changed, 20 insertions(+)
diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
index c6fb3700f2..ff422c8ad1 100644
--- a/hw/arm/aspeed_soc.c
+++ b/hw/arm/aspeed_s
From: Ivan Ren
This patch fix a multifd migration bug in migration speed calculation, this
problem can be reproduced as follows:
1. start a vm and give a heavy memory write stress to prevent the vm be
successfully migrated to destination
2. begin a migration with multifd
3. migrate for a long
From: Ivan Ren
Multifd sync will send MULTIFD_FLAG_SYNC flag info to destination, add
these bytes to ram_counters record.
Signed-off-by: Ivan Ren
Suggested-by: Wei Yang
---
migration/ram.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/migration/ram.c b/migration/ram.c
index 88ddd2bbe2
From: Ivan Ren
Add qemu_file_update_transfer for just update bytes_xfer for speed
limitation. This will be used for further migration feature such as
multifd migration.
Signed-off-by: Ivan Ren
Reviewed-by: Wei Yang
---
migration/qemu-file.c | 5 +
migration/qemu-file.h | 1 +
2 files cha
From: Ivan Ren
Currently multifd migration has not been limited and it will consume
the whole bandwidth of Nic. These two patches add speed limitation to
it.
This is the v3 patches:
v3 VS v2:
Add Reviewed info and Suggested info.
v2 VS v1:
1. change qemu_file_update_rate_transfer interface nam
From: Ivan Ren
Limit the speed of multifd migration through common speed limitation
qemu file.
Signed-off-by: Ivan Ren
---
migration/ram.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/migration/ram.c b/migration/ram.c
index 889148dd84..88ddd2bbe2
Thanks
I'll send a new version with these suggest info and review info.
On Tue, Jul 30, 2019 at 8:42 AM Wei Yang
wrote:
> On Mon, Jul 29, 2019 at 04:01:21PM +0800, Ivan Ren wrote:
> >Multifd sync will send MULTIFD_FLAG_SYNC flag info to destination, add
> >these bytes to ram_counters record.
> >
On 7/29/19 6:52 AM, Peter Maydell wrote:
> I'm not so convinced about this one -- gen_exception_insn()
> and gen_exception_internal_insn() shouldn't have the
> same pattern of function prototype but different semantics
> like this, it's confusing. It happens that both the cases
> of wanting to gene
Set frame buffer endianness according to requested endianness for
frame buffer aperture 0. This fixes inverted colors with Xorg frame
buffer driver. Setting endianness of aperture 1 and reg aperture are
not implemented.
Signed-off-by: BALATON Zoltan
---
hw/display/ati.c | 9 -
hw/di
On 7/29/19 6:43 AM, Peter Maydell wrote:
> On Fri, 26 Jul 2019 at 18:50, Richard Henderson
> wrote:
>>
>> With this, we can have the function return a value from the DisasContext.
>>
>> Signed-off-by: Richard Henderson
>> ---
>> scripts/decodetree.py | 5 -
>> tests/decode/succ_f
On 7/29/19 8:25 AM, Peter Maydell wrote:
> I'm afraid this patch is too big for me to digest :-(
>
> I just spent about half an hour trying to figure out whether
> the changes just to the thumb dp-immediate insns were right
> and didn't manage to work through it all.
Hmm. It is probably the larg
On Mon, Jul 29, 2019 at 01:04:41PM -0600, Alex Williamson wrote:
> On Mon, 29 Jul 2019 16:26:46 +0800
> Peter Xu wrote:
>
> > On Fri, Jul 26, 2019 at 06:55:53PM -0600, Alex Williamson wrote:
> > > When we account for DMA aliases in the PCI address space, we can no
> > > longer use a single IVHD e
On 7/29/19 7:32 AM, Peter Maydell wrote:
> On Fri, 26 Jul 2019 at 18:50, Richard Henderson
> wrote:
>>
>> We will shortly be calling this function much more often.
>>
>> Signed-off-by: Richard Henderson
>> ---
>> target/arm/translate.c | 28
>> 1 file changed, 12 ins
On 7/29/2019 9:09 PM, Igor Mammedov wrote:
On Mon, 29 Jul 2019 14:31:18 +0800
Tao Xu wrote:
Add struct NumaState in MachineState and move existing numa global
nb_numa_nodes(renamed as "num_nodes") into NumaState. And add variable
numa_support into MachineClass to decide which submachines suppo
Hi, Stefan
Thanks for your comments :-)
On Mon, Jul 29, 2019 at 02:58:59PM +0100, Stefan Hajnoczi wrote:
>On Wed, Jul 24, 2019 at 03:03:07PM +0800, Wei Yang wrote:
>> Persistent backend setup requires some knowledge about nvdimm and ndctl
>> tool. Some users report they may struggle to gather the
On 7/29/19 7:15 AM, Peter Maydell wrote:
> On Fri, 26 Jul 2019 at 18:50, Richard Henderson
> wrote:
>>
>> Used only on the thumb side so far, but will be more obvious
>> once we start unifying the implementation of A32+T32.
>>
>> Signed-off-by: Richard Henderson
>> ---
>> target/arm/translate-vf
On Mon, Jul 29, 2019 at 04:01:18PM +0800, Ivan Ren wrote:
>Currently multifd migration has not been limited and it will consume
>the whole bandwidth of Nic. These two patches add speed limitation to
>it.
>
>This is the v2 patches, differences with v1:
>1. change qemu_file_update_rate_transfer inter
On Mon, Jul 29, 2019 at 04:01:21PM +0800, Ivan Ren wrote:
>Multifd sync will send MULTIFD_FLAG_SYNC flag info to destination, add
>these bytes to ram_counters record.
>
>Signed-off-by: Ivan Ren
Also this is suggested by me, it would be better to add Suggested-by.
>---
> migration/ram.c | 2 ++
>
On Mon, Jul 29, 2019 at 04:01:19PM +0800, Ivan Ren wrote:
>Add qemu_file_update_transfer for just update bytes_xfer for speed
>limitation. This will be used for further migration feature such as
>multifd migration.
>
>Signed-off-by: Ivan Ren
Well I have reviewed this patch, suppose you need add m
On 7/29/19 7:05 AM, Peter Maydell wrote:
> On Fri, 26 Jul 2019 at 18:50, Richard Henderson
> wrote:
>>
>> We currently have 3 different ways of computing the architectural
>> value of "PC" as seen in the ARM ARM.
>>
>> The value of s->pc has been incremented past the current insn,
>> but that is a
When we iterate the memory-device list to get the available range, it is not
necessary to iterate the whole list.
1) no more overlap for hinted range if tmp exceed it
v2:
* remove #2 as suggested by Igor and David
* add some comment to inform address assignment stay the same as before
We are already at the last condition check.
Signed-off-by: Wei Yang
Reviewed-by: Igor Mammedov
Reviewed-by: David Hildenbrand
---
hw/mem/memory-device.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/hw/mem/memory-device.c b/hw/mem/memory-device.c
index 5f2c408036..df3261b32a 100644
--- a/
The memory-device list built by memory_device_build_list is ordered by
its address, this means if the tmp range exceed the hinted range, all
the following range will not overlap with it.
And this won't change default pc-dimm mapping and address assignment stay
the same as before this change.
Sign
On 2019/7/29 23:41, Stefan Hajnoczi wrote:
> On Mon, Jul 29, 2019 at 08:35:36PM +0800, piaojun wrote:
>> Hi Stefan,
>>
>> On 2019/7/26 17:11, Stefan Hajnoczi wrote:
>>> Most lo_do_lookup() have already checked that the parent inode exists.
>>> lo_lookup() hasn't and can therefore hit a NULL poin
Use F_GETLK for fcntl when F_OFD_GETLK not defined.
Signed-off-by: Jun Piao
---
contrib/virtiofsd/passthrough_ll.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/contrib/virtiofsd/passthrough_ll.c
b/contrib/virtiofsd/passthrough_ll.c
index 9ae1381..757785b 100644
--- a/contrib/vir
Patchew URL:
https://patchew.org/QEMU/1564424746-11065-1-git-send-email-aleksandar.marko...@rt-rk.com/
Hi,
This series failed build test on s390x host. Please find the details below.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
# Testing script will be invoked under the git checkout with
# HEAD poin
This reverts commit 0d910cfeaf2076b116b4517166d5deb0fea76394.
It's not correct to just ignore an error code in a callback; we need to
handle that error and possible report failure to the guest so that they
don't wait indefinitely for an operation that will now never finish.
This ought to help cas
On 7/29/19 5:51 PM, Paolo Bonzini wrote:
> On 29/07/19 23:46, John Snow wrote:
>>> @@ -111,15 +112,12 @@ static void dma_complete(DMAAIOCB *dbs, int ret)
>>> {
>>> trace_dma_complete(dbs, ret, dbs->common.cb);
>>>
>>> +assert(!dbs->acb && !dbs->bh);
>>> dma_blk_unmap(dbs);
>>>
On 29/07/19 23:46, John Snow wrote:
>> @@ -111,15 +112,12 @@ static void dma_complete(DMAAIOCB *dbs, int ret)
>> {
>> trace_dma_complete(dbs, ret, dbs->common.cb);
>>
>> +assert(!dbs->acb && !dbs->bh);
>> dma_blk_unmap(dbs);
>> if (dbs->common.cb) {
>> dbs->common.cb(
On 29/07/19 23:37, John Snow wrote:
>>>
>>> If it does -- if there are indeed no places in the code today that
>>> artificially inject -ECANCELED -- I need to remove these special stanzas
>>> from the IDE code and allow the IDE state machine to handle these errors
>>> as true errors.
>> The bug is
The race is as follows:
vCPU thread reader thread
--- ---
TLB check -> slow path
notdirty_mem_write
write to RAM
set dirty flag
clear dirty flag
TLB
There is a race between TCG and accesses to the dirty log:
vCPU thread reader thread
--- ---
TLB check -> slow path
notdirty_mem_write
write to RAM
set dirty flag
On 7/29/19 5:34 PM, Paolo Bonzini wrote:
> dma_aio_cancel unschedules the BH if there is one, which corresponds
> to the reschedule_dma case of dma_blk_cb. This can stall the DMA
> permanently, because dma_complete will never get invoked and therefore
> nobody will ever invoke the original AIO
Like script_main, but doesn't require a single point of entry.
Replace all existing initialization sections with this drop-in replacement.
This brings debug support to all existing script-style iotests.
Note: supported_oses=['linux'] was omitted, as it is a default argument.
Signed-off-by: John S
We can turn logging on/off globally instead of per-function.
Remove use_log from run_job, and use python logging to turn on
diffable output when we run through a script entry point.
iotest 245 changes output order due to buffering reasons.
Signed-off-by: John Snow
---
tests/qemu-iotests/030
On 7/29/19 5:32 PM, Paolo Bonzini wrote:
> On 29/07/19 21:45, John Snow wrote:
>> Next, we'll unschedule the BH if there is one. I think the only case
>> where there is one is the reschedule_dma case of dma_blk_cb. (I'm not
>> too familiar with these DMA helpers: in what cases do we expect the i
This will add supported_protocols and unsupported_protocols to all of
iotests.main, iotests.script_main, and iotests.script_initialize.
Signed-off-by: John Snow
---
tests/qemu-iotests/207| 4 ++--
tests/qemu-iotests/210| 4 ++--
tests/qemu-iotests/211| 4 ++--
tests/qemu-
Based-on: https://github.com/jnsnow/qemu/tree/bitmaps
This series uses python logging to enable output conditionally on
iotests.log(). We unify an initialization call (which also enables
debugging output for those tests with -d) and then make the switch
inside of iotests.
It will help alleviate t
dma_aio_cancel unschedules the BH if there is one, which corresponds
to the reschedule_dma case of dma_blk_cb. This can stall the DMA
permanently, because dma_complete will never get invoked and therefore
nobody will ever invoke the original AIO callback in dbs->common.cb.
Fix this by invoking th
On 29/07/19 21:45, John Snow wrote:
> Next, we'll unschedule the BH if there is one. I think the only case
> where there is one is the reschedule_dma case of dma_blk_cb. (I'm not
> too familiar with these DMA helpers: in what cases do we expect the iov
> to be empty?)
When there is another I/O tha
On 7/25/19 5:05 AM, Vladimir Sementsov-Ogievskiy wrote:
> This helps to avoid extra io, allocations and memory copying.
> We assume here that CMD_CACHE is always used with copy-on-read, as
> otherwise it's a noop.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> nbd/server.c | 43
On 7/26/19 7:42 PM, Dmitry Fomichev wrote:
> John, please see inline...
>
> Regards,
> Dmitry
>
> On Thu, 2019-07-25 at 13:58 -0400, John Snow wrote:
>>
>> On 7/23/19 6:19 PM, Dmitry Fomichev wrote:
>>> Currently, attaching zoned block devices (i.e., storage devices
>>> compliant to ZAC/ZBC st
On 7/25/19 5:05 AM, Vladimir Sementsov-Ogievskiy wrote:
> This helps to avoid extra io, allocations and memory copying.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> block/stream.c | 20 +++-
> 1 file changed, 7 insertions(+), 13 deletions(-)
>
> diff --git a/block/str
I'm sending this out now as these patches are ready,
but it seems likely we'll need another patch for pci,
and as it deals with migration compat it might be a blocker.
Will know more tomorrow :(
The following changes since commit fff3159900d2b95613a9cb75fc3703e67a674729:
Merge remote-tracking
On 7/25/19 5:05 AM, Vladimir Sementsov-Ogievskiy wrote:
> Do effective copy-on-read request when we don't need data actually. It
> will be used for block-stream and NBD_CMD_CACHE.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> include/block/block.h | 8 +++-
> block/io.c
On 7/25/19 4:49 AM, Vladimir Sementsov-Ogievskiy wrote:
> It's needed to provide keepalive for nbd client to track server
> availability.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> +++ b/util/qemu-sockets.c
> @@ -219,6 +219,12 @@ static int inet_listen_saddr(InetSocketAddress *saddr
On 7/28/19 8:07 PM, Eduardo Habkost wrote:
> On Fri, Jul 26, 2019 at 06:52:00PM -0400, John Snow wrote:
>> Like script_main, but doesn't require a single point of entry.
>> Replace all existing initialization sections with this drop-in replacement.
>>
>> This brings debug support to all existing
On Fri, Jul 26, 2019 at 02:05:36PM +0200, Markus Armbruster wrote:
> hw/boards.h pulls in almost 60 headers. The less we include it into
> headers, the better. As a first step, drop superfluous inclusions,
> and downgrade some more to what's actually needed. Gets rid of just
> one inclusion into
On Tue, 2019-07-23 at 12:00 -0500, Michael Roth wrote:
> Hi
> everyone,
>
>
> The following new patches are queued for QEMU stable v3.1.1:
>
> https://github.com/mdroth/qemu/commits/stable-3.1-staging
On 7/26/19 5:16 PM, Eduardo Habkost wrote:
> CCing Cleber and Gabriel. Comments at the "conclusions" section
> below:
>
> On Wed, Jul 24, 2019 at 05:06:41PM -0400, John Snow wrote:
>> Has anyone on this list experimented with these tools?
>>
>> I was hoping to use them to document things like
On Fri, Jul 26, 2019 at 02:05:36PM +0200, Markus Armbruster wrote:
> hw/boards.h pulls in almost 60 headers. The less we include it into
> headers, the better. As a first step, drop superfluous inclusions,
> and downgrade some more to what's actually needed. Gets rid of just
> one inclusion into
On Fri, Jul 26, 2019 at 02:05:39PM +0200, Markus Armbruster wrote:
> Commit e35704ba9c "numa: Move NUMA declarations from sysemu.h to
> numa.h" left a few NUMA-related macros behind. Move them now.
>
> Cc: Eduardo Habkost
> Cc: Marcel Apfelbaum
> Signed-off-by: Markus Armbruster
Reviewed-by:
On Fri, Jul 26, 2019 at 02:05:38PM +0200, Markus Armbruster wrote:
> Move the HostMemoryBackend typedef from sysemu/hostmem.h to
> qemu/typedefs.h. This renders a few inclusions of sysemu/hostmem.h
> superflouous; drop them.
>
> Cc: Eduardo Habkost
> Cc: Igor Mammedov
> Signed-off-by: Markus Ar
On Mon, 22 Jul 2019 22:30:15 PDT (-0700), bmeng...@gmail.com wrote:
Hi Palmer,
On Sat, Jul 20, 2019 at 9:47 AM Palmer Dabbelt wrote:
On Fri, 14 Jun 2019 08:15:51 PDT (-0700), bmeng...@gmail.com wrote:
> This adds a reset opcode for sifive_test device to trigger a system
> reset for testing pu
On 7/29/19 6:09 AM, Stefan Hajnoczi wrote:
> On Fri, Jul 26, 2019 at 04:18:46PM -0400, John Snow wrote:
>> Paolo, Stefan and Kevin: can I loop you in here? I'm quite uncertain
>> about this and I'd like to clear this up quickly if it's possible:
>>
>> On 7/25/19 8:58 PM, John Snow wrote:
>>>
>>>
On Fri, Jul 26, 2019 at 02:05:37PM +0200, Markus Armbruster wrote:
> sysemu/numa.h includes hw/boards.h just for the CPUArchId typedef, at
> the cost of pulling in more than two dozen extra headers indirectly.
>
> I could move the typedef from hw/boards.h to qemu/typedefs.h. But
> it's used in ju
Device model is supposed to destroy IOREQ server for itself.
Signed-off-by: Igor Druzhinin
---
hw/i386/xen/xen-hvm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index e8e79e0..30a5948 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen
On Fri, Jul 26, 2019 at 02:05:35PM +0200, Markus Armbruster wrote:
> In my "build everything" tree, changing hw/qdev-properties.h triggers
> a recompile of some 2700 out of 6600 objects (not counting tests and
> objects that don't depend on qemu/osdep.h).
>
> Many places including hw/qdev-properti
On Fri, Jul 26, 2019 at 06:55:27PM -0600, Alex Williamson wrote:
> Please see patch 1/ for the motivation and utility of this series.
> This v1 submission improves on the previous RFC with revised commit
> logs, comments, and more testing, and the missing IVRS support for DMA
> alias ranges is now
On Mon, 29 Jul 2019 16:26:46 +0800
Peter Xu wrote:
> On Fri, Jul 26, 2019 at 06:55:53PM -0600, Alex Williamson wrote:
> > When we account for DMA aliases in the PCI address space, we can no
> > longer use a single IVHD entry in the IVRS covering all devices. We
> > instead need to walk the PCI b
From: Yongbok Kim
Implement Global Invalidate TLB instruction. As QEMU doesn't support
caches and Virtualization, this implementation only cover the GINVT
(Global Invalidate TLB) instruction.
Signed-off-by: Yongbok Kim
Signed-off-by: Aleksandar Markovic
---
disas/mips.c| 2 +
ta
From: Yongbok Kim
The optional Data Scratch Pad RAM (DSPRAM) block provides a general scratch pad
RAM
used for temporary storage of data. The DSPRAM provides a connection to on-chip
memory or memory-mapped registers, which are accessed in parallel with the L1
data
cache to minimize access laten
From: Yongbok Kim
Add emulation of MIPS' CRC32 (Cyclic Redundancy Check) instructions.
Reuse zlib crc32() and Linux crc32c(). Note that, at the time being,
there is no MIPS CPU that supports CRC32 instructions (they are an
optional part of MIPS64/32 R6 anf nanoMIPS ISAs).
Signed-off-by: Yongbok
From: Aleksandar Markovic
There is a need for printing input and output data for failure cases,
for debugging purpose. This is achieved by this patch, and only if a
preprocessor constant is manually set to 1. (Assumption is that the
need for such printout is relatively rare.)
Signed-off-by: Alek
From: Yongbok Kim
WatchHi is extended by the field MemoryMapID with the GINVT instruction.
The field is accessible by MTHC0/MFHC0 in 32-bit architectures and DMTC0/
DMFC0 in 64-bit architectures.
Signed-off-by: Yongbok Kim
Signed-off-by: Aleksandar Markovic
---
target/mips/cpu.h | 2 +-
From: Aleksandar Markovic
This series includes misc MIPS patches intended to be integrated after
4.1 release.
v1->v2:
- fixed checkpatch warnings
- added four new patches on various topics
Aleksandar Markovic (2):
tests/tcg: target/mips: Add optional printing of more detailed failure
Thanks. Opened https://gitlab.freedesktop.org/slirp/libslirp/issues/9.
** Bug watch added: gitlab.freedesktop.org/slirp/libslirp/issues #9
https://gitlab.freedesktop.org/slirp/libslirp/issues/9
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscrib
* Igor Mammedov (imamm...@redhat.com) wrote:
> use qemu_ram_alloc_from_ptr() to create aliased RAMBlock
> to the part of original memory region.
>
> Signed-off-by: Igor Mammedov
> ---
> exec.c | 7 ---
> memory.c | 5 +
> 2 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git
On Fri, Jul 26, 2019 at 2:55 AM Alistair Francis
wrote:
> Signed-off-by: Alistair Francis
> ---
> hw/riscv/sifive_plic.c | 12
> include/hw/riscv/sifive_plic.h | 3 ---
> 2 files changed, 15 deletions(-)
>
> diff --git a/hw/riscv/sifive_plic.c b/hw/riscv/sifive_plic.c
> in
On 7/29/19 6:42 PM, Kevin Wolf wrote:
> scsi-disks decides whether it has a read-only device by looking at
> whether the BlockBackend specified as drive=... is read-only. In the
> case of an anonymous BlockBackend (with a node name specified in
> drive=...), this is the read-only flag of the attach
On Mon, 29 Jul 2019 at 17:10, Eduardo Habkost wrote:
>
> The following changes since commit 893dc8300c80e3dc32f31e968cf7aa0904da50c3:
>
> Merge remote-tracking branch 'remotes/jasowang/tags/net-pull-request' into
> staging (2019-07-29 12:04:53 +0100)
>
> are available in the Git repository at:
On Fri, Jul 26, 2019 at 2:55 AM Alistair Francis
wrote:
> Let's creaate a function that tests if floating point support is
> enabled. We can then protect all floating point operations based on if
> they are enabled.
>
> This patch so far doesn't change anything, it's just preparing for the
> Hype
On Mon, 29 Jul 2019 17:29:03 +0100
"Dr. David Alan Gilbert (git)" wrote:
> From: "Dr. David Alan Gilbert"
>
> This reverts commit f2784eed306449c3d04a71a05ed6463b8289aedf
> since that accidentally removes the PCIe capabilities from virtio
> devices because virtio_pci_dc_realize is called before
On Mon, 29 Jul 2019 17:29:02 +0100
"Dr. David Alan Gilbert (git)" wrote:
> From: "Dr. David Alan Gilbert"
>
> This reverts commit 8fa70dbd8bb478d9483c1da3e9976a2d86b3f9a0.
>
> Because we're about to revert it's neighbour and thus uses an optional
> again.
>
> Signed-off-by: Dr. David Alan Gil
On Mon, Jul 29, 2019 at 05:43:17PM +0100, Peter Maydell wrote:
> On Mon, 29 Jul 2019 at 17:36, Dr. David Alan Gilbert
> wrote:
> >
> > * Cornelia Huck (coh...@redhat.com) wrote:
> > > On Mon, 29 Jul 2019 17:29:01 +0100
> > > "Dr. David Alan Gilbert (git)" wrote:
> > >
> > > > From: "Dr. David Ala
** Also affects: virt-manager (Ubuntu)
Importance: Undecided
Status: New
** 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/1838312
Title:
Qe
syslog:
kernel: [ 2003.888116] virt-manager[16014]: segfault at 32d0 ip
32d0 sp 7ffeb09ac658 error 14 in python3.7[40+21000]
kernel: [ 2003.888124] Code: Bad RIP value.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to Q
On Mon, 29 Jul 2019 at 17:36, Dr. David Alan Gilbert
wrote:
>
> * Cornelia Huck (coh...@redhat.com) wrote:
> > On Mon, 29 Jul 2019 17:29:01 +0100
> > "Dr. David Alan Gilbert (git)" wrote:
> >
> > > From: "Dr. David Alan Gilbert"
> > >
> > > Revert a couple of patches that break PCIe capabilities
scsi-disks decides whether it has a read-only device by looking at
whether the BlockBackend specified as drive=... is read-only. In the
case of an anonymous BlockBackend (with a node name specified in
drive=...), this is the read-only flag of the attached node. In the case
of an empty anonymous Blo
* Cornelia Huck (coh...@redhat.com) wrote:
> On Mon, 29 Jul 2019 17:29:01 +0100
> "Dr. David Alan Gilbert (git)" wrote:
>
> > From: "Dr. David Alan Gilbert"
> >
> > Revert a couple of patches that break PCIe capabilities in virtio
> > devices. The 'optional' revert is just reverted to make the
Public bug reported:
Hi!
I installed all these packages:
sudo apt install qemu
sudo apt install ipxe-qemu-256k-compat-efi-roms libspice-server1 libbluetooth3
sudo apt install libbrlapi0.6 libcacard0 libfdt1 libusbredirparser1
libvirglrenderer0 libxen-4.9 libxenstore3.0
sudo apt install cpu-chec
On Mon, 29 Jul 2019 17:29:01 +0100
"Dr. David Alan Gilbert (git)" wrote:
> From: "Dr. David Alan Gilbert"
>
> Revert a couple of patches that break PCIe capabilities in virtio
> devices. The 'optional' revert is just reverted to make the main
> reversion trivial.
Don't want to spoil the party
On Mon, Jul 29, 2019 at 05:29:03PM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> This reverts commit f2784eed306449c3d04a71a05ed6463b8289aedf
> since that accidentally removes the PCIe capabilities from virtio
> devices because virtio_pci_dc_realize is called bef
On Mon, Jul 29, 2019 at 05:29:02PM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> This reverts commit 8fa70dbd8bb478d9483c1da3e9976a2d86b3f9a0.
>
> Because we're about to revert it's neighbour and thus uses an optional
> again.
>
> Signed-off-by: Dr. David Alan
From: "Dr. David Alan Gilbert"
This reverts commit f2784eed306449c3d04a71a05ed6463b8289aedf
since that accidentally removes the PCIe capabilities from virtio
devices because virtio_pci_dc_realize is called before the new 'mode'
flag is set.
Signed-off-by: Dr. David Alan Gilbert
---
hw/core/mac
From: "Dr. David Alan Gilbert"
Revert a couple of patches that break PCIe capabilities in virtio
devices. The 'optional' revert is just reverted to make the main
reversion trivial.
Symptom:
Loss of PCIe capabilities in virtio devices hung off PCIe bridges
Signed-off-by: Dr. David Alan Gilbert
From: "Dr. David Alan Gilbert"
This reverts commit 8fa70dbd8bb478d9483c1da3e9976a2d86b3f9a0.
Because we're about to revert it's neighbour and thus uses an optional
again.
Signed-off-by: Dr. David Alan Gilbert
---
include/hw/qdev-core.h | 3 +++
qom/object.c | 3 +++
2 files changed,
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Mon, Jul 29, 2019 at 04:59:09PM +0100, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > This reverts commit f2784eed306449c3d04a71a05ed6463b8289aedf
> > since that accidentally removes the PCIe capabilities from
Hi Markus.
On 7/16/19 5:12 PM, Markus Armbruster wrote:
> "Dr. David Alan Gilbert" writes:
>
>> * Markus Armbruster (arm...@redhat.com) wrote:
>>> Philippe asked me to have a look at this one, so here goes.
Thanks a lot for your careful analysis.
I got scared the uh-oh you raised would get thi
On Mon, 29 Jul 2019 16:59:09 +0100
"Dr. David Alan Gilbert (git)" wrote:
> From: "Dr. David Alan Gilbert"
>
> This reverts commit f2784eed306449c3d04a71a05ed6463b8289aedf
> since that accidentally removes the PCIe capabilities from virtio
> devices because virtio_pci_dc_realize is called before
From: Paul Lai
Changing the name to Snowridge from SnowRidge-Server.
There is no client model of Snowridge, so "-Server" is unnecessary.
Removing CPUID_EXT_VMX from Snowridge cpu feature list.
Signed-off-by: Paul Lai
Tested-by: Tao3 Xu
Message-Id: <20190716155808.25010-1-paul.c@intel.com>
1 - 100 of 285 matches
Mail list logo
