On Mon, 4 Jun 2018 04:38:22 +0300
"Michael S. Tsirkin" wrote:
> On Sun, Jun 03, 2018 at 12:27:49PM +0300, Marcel Apfelbaum wrote:
> > Moving to QEMU 3.0 seems like a good opportunity for such a change.
> >
> > I440FX is really old and does not support modern features like IOMMU.
> > Q35's SATA
On 1 June 2018 at 18:34, Peter Maydell wrote:
> In particular, this means that if you create what you expect to
> be a local-to-this-device RAM memory region in a SysBusDevice,
> then (because SysBus doesn't implement get_dev_path), there is
> no per-device qualification added to the region name,
On Mon, 4 Jun 2018 14:00:43 +0200
David Hildenbrand wrote:
> On 04.06.2018 13:38, Cornelia Huck wrote:
> > On Fri, 25 May 2018 13:37:02 +0200
> > David Hildenbrand wrote:
> >
> >> Let's treat this like a separate device. TCG will have to store the
> >> actual state/time later on.
> >>
> >>
On Fri, 25 May 2018 13:37:07 +0200
David Hildenbrand wrote:
> If the CPU data is migrated after the TOD clock, the CKC timer of a CPU
> is not rearmed. Let's rearm it when loading the CPU state.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/machine.c | 7 +++
> 1 file changed,
On Fri, 25 May 2018 13:37:06 +0200
David Hildenbrand wrote:
> This allows a guest to change its TOD. We already take care of updating
> all CKC timers from within S390TODClass.
>
> Use MO_ALIGN to load the operand manually - this will properly trigger a
> SPECIFICATION exception.
>
>
On 06/04/2018 12:51 PM, Stefan Hajnoczi wrote:
On Fri, Jun 01, 2018 at 05:24:53PM +0300, Ari Sundholm wrote:
On 06/01/2018 04:32 PM, Stefan Hajnoczi wrote:
On Fri, Jun 01, 2018 at 12:17:19AM +0300, Ari Sundholm wrote:
From: Aapo Vienamo
Thanks for the patch!
Implements a block device
On Mon, 4 Jun 2018 11:46:06 +0200
Max Reitz wrote:
> On 2018-06-02 12:46, Michal Privoznik wrote:
> > On 06/01/2018 03:28 PM, Max Reitz wrote:
> >> Hi,
> >>
> >> The @preconfig RunState documentation states:
> >>
> >>> The state is reachable only if the --preconfig CLI option is used.
> >>
The RUN_STATE_PRECONFIG state is not supposed to be reachable unless the
--preconfig argument is given to QEMU, but when it was introduced in:
commit 047f7038f586d2150f16c6d9ba9cfd0479f0f6ac
Author: Igor Mammedov
Date: Fri May 11 19:24:43 2018 +0200
cli: add --preconfig option
On Mon, Jun 04, 2018 at 01:58:02PM +0200, Igor Mammedov wrote:
> On Mon, 4 Jun 2018 12:33:04 +0200
> Max Reitz wrote:
>
> > On 2018-06-04 12:27, Daniel P. Berrangé wrote:
> > > The RUN_STATE_PRECONFIG state is not supposed to be reachable unless the
> > > --preconfig argument is given to QEMU,
When using --daemonize, the initial lead process will fork a child and
then wait to be notified that setup is complete via a pipe, before it
exits. When using --preconfig there is an extra call to main_loop()
before the notification is done from os_setup_post(). Thus the parent
process won't exit
The change to use RUN_STATE_PRECONFIG as the default initial state, even
when not requested with --preconfig has caused a number of problems. This
series introduces a new RUN_STATE_NONE to act as the initial state, so
that we never use RUN_STATE_PRECONFIG unless the mgmt app has explicitly
On 04.06.2018 13:38, Cornelia Huck wrote:
> On Fri, 25 May 2018 13:37:02 +0200
> David Hildenbrand wrote:
>
>> Let's treat this like a separate device. TCG will have to store the
>> actual state/time later on.
>>
>> Include cpu-qom.h in kvm_s390x.h (due to S390CPU) to compile tod-kvm.c.
>
>
On 04.06.2018 13:57, Cornelia Huck wrote:
> On Fri, 25 May 2018 13:37:04 +0200
> David Hildenbrand wrote:
>
>> Right now, each CPU has its own TOD. Especially, the TOD will differ
>> based on creation time of a CPU - e.g. when hotplugging a CPU the times
>> will differ quite a lot, resulting in
On Mon, 4 Jun 2018 12:33:04 +0200
Max Reitz wrote:
> On 2018-06-04 12:27, Daniel P. Berrangé wrote:
> > The RUN_STATE_PRECONFIG state is not supposed to be reachable unless the
> > --preconfig argument is given to QEMU, but when it was introduced in:
> >
> > commit
On Fri, 25 May 2018 13:37:04 +0200
David Hildenbrand wrote:
> Right now, each CPU has its own TOD. Especially, the TOD will differ
> based on creation time of a CPU - e.g. when hotplugging a CPU the times
> will differ quite a lot, resulting in stall warnings in the guest.
>
> Let's use a
On 2 June 2018 at 00:14, Richard Henderson wrote:
> The following changes since commit 392fba9f583223786f844dce9b2e7f9a0ce0147a:
>
> Merge remote-tracking branch
> 'remotes/stsquad/tags/pull-travis-updates-010618-1' into staging (2018-06-01
> 17:32:30 +0100)
>
> are available in the Git
On 01.06.2018 13:39, Igor Mammedov wrote:
> On Thu, 17 May 2018 10:15:27 +0200
> David Hildenbrand wrote:
>
>> Let's move the plug logic into the applicable hotplug handler for pc and
>> spapr.
>>
>> Signed-off-by: David Hildenbrand
>> ---
>> hw/i386/pc.c | 35
On 01.06.2018 13:17, Igor Mammedov wrote:
> On Thu, 17 May 2018 10:15:25 +0200
> David Hildenbrand wrote:
>
>> Let's move all pre-plug checks we can do without the device being
>> realized into the applicable hotplug handler for pc and spapr.
>>
>> Signed-off-by: David Hildenbrand
>> ---
>>
On Sat, 2 Jun 2018 12:34:52 +0200
Michal Privoznik wrote:
> After 047f7038f586d215 it is possible for event loop to run two
> times. First time whilst parsing command line options (the idea
> is to bring up monitor early so that management applications can
> tweak config before machine is
On Fri, 25 May 2018 13:37:02 +0200
David Hildenbrand wrote:
> Let's treat this like a separate device. TCG will have to store the
> actual state/time later on.
>
> Include cpu-qom.h in kvm_s390x.h (due to S390CPU) to compile tod-kvm.c.
Can't you include it in tod-kvm.c instead? Why was it not
On 31.05.2018 16:13, Igor Mammedov wrote:
> On Wed, 30 May 2018 16:13:32 +0200
> David Hildenbrand wrote:
>
>> On 30.05.2018 15:08, Igor Mammedov wrote:
>>> On Thu, 17 May 2018 10:15:17 +0200
>>> David Hildenbrand wrote:
>>>
For multi stage hotplug handlers, we'll have to do some error
Currently we use memory_region_init_rom_nomigrate() to create
the "bios.1fc" memory region, and we don't manually register
it with vmstate_register_ram(). This currently means that its
contents are migrated but as a ram block whose name is the empty
string; in future it may mean they are not
Commit d759c951f3287fad04210a52f2dc93f94cf58c7f ("replay: push
replay_mutex_lock up the call tree") removed the !timeout lock
optimization in the main loop.
The idea of the optimization was to avoid ping-pongs between threads by
keeping the Big QEMU Lock held across non-blocking (!timeout) main
From: Fam Zheng
It's a BlockBackend wrapper of the BDS interface.
Signed-off-by: Fam Zheng
Reviewed-by: Stefan Hajnoczi
Message-id: 20180601092648.24614-10-f...@redhat.com
Signed-off-by: Stefan Hajnoczi
---
include/sysemu/block-backend.h | 4
block/block-backend.c | 18
From: Fam Zheng
The new blk_co_copy_range interface offers a more efficient way in the
case of network based storage. Make use of it to allow faster convert
operation.
Since copy offloading cannot do zero detection ('-S') and compression
(-c), only try it when these options are not used.
From: Fam Zheng
With copy_file_range(2), we can implement the bdrv_co_copy_range
semantics.
Signed-off-by: Fam Zheng
Message-id: 20180601092648.24614-6-f...@redhat.com
Signed-off-by: Stefan Hajnoczi
---
configure | 17 +++
include/block/raw-aio.h | 10 -
From: Fam Zheng
This loop is repeated a growing number times. Make a helper.
Signed-off-by: Fam Zheng
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Eric Blake
Message-id: 20180601092648.24614-8-f...@redhat.com
Signed-off-by: Stefan Hajnoczi
---
block/iscsi.c | 54
Currently we use memory_region_init_rom_nomigrate() to create
the "boston.flash" memory region, and we don't manually register
it with vmstate_register_ram(). This currently means that its
contents are migrated but as a ram block whose name is the empty
string; in future it may mean they are not
From: Fam Zheng
Issue EXTENDED COPY (LID1) command to implement the copy_range API.
The parameter data construction code is modified from libiscsi's
iscsi-dd.c.
Signed-off-by: Fam Zheng
Reviewed-by: Stefan Hajnoczi
Message-id: 20180601092648.24614-9-f...@redhat.com
Signed-off-by: Stefan
From: Fam Zheng
The device designator data returned in INQUIRY command will be useful to
fill in source/target fields during copy offloading. Do this when
connecting to the target and save the data for later use.
Signed-off-by: Fam Zheng
Reviewed-by: Stefan Hajnoczi
Message-id:
From: Fam Zheng
Introduce the bdrv_co_copy_range() API for copy offloading. Block
drivers implementing this API support efficient copy operations that
avoid reading each block from the source device and writing it to the
destination devices. Examples of copy offload primitives are SCSI
The following changes since commit c25e8bba1f546ea72744ccfab77f8a9e8a323be8:
Merge remote-tracking branch 'remotes/otubo/tags/pull-seccomp-20180601' into
staging (2018-06-01 13:11:30 +0100)
are available in the Git repository at:
git://github.com/stefanha/qemu.git tags/block-pull-request
From: Fam Zheng
Just pass down to ->file.
Signed-off-by: Fam Zheng
Reviewed-by: Stefan Hajnoczi
Message-id: 20180601092648.24614-4-f...@redhat.com
Signed-off-by: Stefan Hajnoczi
---
block/raw-format.c | 32
1 file changed, 32 insertions(+)
diff --git
From: Fam Zheng
We don't verify the request range against s->size in the I/O callbacks
except for raw_co_pwritev. This is inconsistent (especially for
raw_co_pwrite_zeroes and raw_co_pdiscard), so fix them, in the meanwhile
make the helper reusable by the coming new callbacks.
Note that in most
From: Fam Zheng
The two callbacks are implemented quite similarly to the read/write
functions: bdrv_co_copy_range_from maps for read and calls into bs->file
or bs->backing depending on the allocation status; bdrv_co_copy_range_to
maps for write and calls into bs->file.
Reviewed-by: Stefan
On 4 June 2018 at 14:10:08, Stefan Hajnoczi (stefa...@gmail.com) wrote:
> What is the status of the Cortex M0 in that source tree? Is it complete?
all supported Cortex-M devices run blinky demos using the official
CMSIS initialisations, but I would not qualify them as complete.
they also
On Sun, Jun 3, 2018 at 2:14 PM, Liviu Ionescu wrote:
> On 2 June 2018 at 17:15:15, Stefan Hajnoczi (stefa...@gmail.com) wrote:
>
>> > I have put together a basic Cortex M0 ARMv6-M CPU that can serve
>> as
>> the basis for this work. Please see the RFC patches that I've sent
>> separately.
>
> you
This patchset fixes a a bug in the MIPS boston and malta boards:
they currently use memory_region_init_rom_nomigrate() to create
memory regions for their BIOS/flash, and they don't manually
register the MR with vmstate_register_ram() either. This currently
means that its contents are migrated, but
On 2018-05-31 23:24, Eric Blake wrote:
> Commit bf42508f introduced new generated files; make sure they
> don't get accidentally committed from an in-tree build.
>
> Signed-off-by: Eric Blake
> ---
> .gitignore | 4
> 1 file changed, 4 insertions(+)
Reviewed-by: Max Reitz
>> Let me explain a little bit why I don't like such restrictions (for
>> which I don't see a need yet):
> (*) being conservative is good here because we can always relax restrictions
> in future if it's needed without breaking users, but we can't take away
> something thing that's been shipped
On 06/04/2018 12:35 PM, Daniel P. Berrangé wrote:
> On Mon, Jun 04, 2018 at 12:33:04PM +0200, Max Reitz wrote:
>> On 2018-06-04 12:27, Daniel P. Berrangé wrote:
>>> The RUN_STATE_PRECONFIG state is not supposed to be reachable unless the
>>> --preconfig argument is given to QEMU, but when it was
Richard Henderson writes:
> The translator loop does not allow the tb_start hook to set
> dc->base.is_jmp; the only hook allowed to do that is translate_insn.
>
> Split the work between init_disas_context where we validate
> the gUSA parameters, and translate_insn where we emit code.
>
>
On 2018-06-04 12:35, Daniel P. Berrangé wrote:
> On Mon, Jun 04, 2018 at 12:33:04PM +0200, Max Reitz wrote:
>> On 2018-06-04 12:27, Daniel P. Berrangé wrote:
>>> The RUN_STATE_PRECONFIG state is not supposed to be reachable unless the
>>> --preconfig argument is given to QEMU, but when it was
On Mon, Jun 04, 2018 at 12:33:04PM +0200, Max Reitz wrote:
> On 2018-06-04 12:27, Daniel P. Berrangé wrote:
> > The RUN_STATE_PRECONFIG state is not supposed to be reachable unless the
> > --preconfig argument is given to QEMU, but when it was introduced in:
> >
> > commit
On 04.06.2018 09:18, Markus Armbruster wrote:
> Roman Kagan writes:
>
>> Add helper functions to query the block drivers actually supported by
>> QEMU using "-drive format=?". This allows to skip certain tests that
>> require drivers not built in or whitelisted in QEMU.
>>
>> Signed-off-by:
On Sat, Jun 02, 2018 at 12:34:52PM +0200, Michal Privoznik wrote:
> After 047f7038f586d215 it is possible for event loop to run two
> times. First time whilst parsing command line options (the idea
> is to bring up monitor early so that management applications can
> tweak config before machine is
On 2018-06-04 12:27, Daniel P. Berrangé wrote:
> The RUN_STATE_PRECONFIG state is not supposed to be reachable unless the
> --preconfig argument is given to QEMU, but when it was introduced in:
>
> commit 047f7038f586d2150f16c6d9ba9cfd0479f0f6ac
> Author: Igor Mammedov
> Date: Fri May 11
On 22 February 2017 at 00:21, Yongbok Kim wrote:
> From: Paul Burton
>
> Add support for emulating the Xilinx AXI Root Port Bridge for PCI
> Express as described by Xilinx' PG055 document. This is a PCIe
> controller that can be used with certain series of Xilinx FPGAs, and is
> used on the MIPS
Hi,
Is there some way to start a KVM-accelerated VM with QEMU (on an Intel/VMX
host) that is configured so that RDTSC/RDTSCP instructions won't cause a
VM-exit?
According to Intel's manual, it seems I should disable the "RDTSC exiting"
bit on the MSR that Linux identifies as
On 2018-06-01 16:12, Peter Maydell wrote:
> Convert the pflash_cfi02 device away from using the old_mmio field
> of MemoryRegionOps.
>
> Signed-off-by: Peter Maydell
> ---
> hw/block/pflash_cfi02.c | 97 -
> 1 file changed, 18 insertions(+), 79
On 1 June 2018 at 17:26, Michael S. Tsirkin wrote:
> The following changes since commit 63b88968f139b6a77f2f81e6f1eedf70c0170a85:
>
> intel-iommu: rework the page walk logic (2018-05-23 17:34:05 +0300)
>
> are available in the Git repository at:
>
>
The RUN_STATE_PRECONFIG state is not supposed to be reachable unless the
--preconfig argument is given to QEMU, but when it was introduced in:
commit 047f7038f586d2150f16c6d9ba9cfd0479f0f6ac
Author: Igor Mammedov
Date: Fri May 11 19:24:43 2018 +0200
cli: add --preconfig option
The
On Mon, Jun 04, 2018 at 10:29:40AM +0100, Peter Maydell wrote:
> On 4 June 2018 at 10:20, Stefan Hajnoczi wrote:
> > Many of these inputs/outputs can be tied to an external UI. A degree of
> > timing precision is required so that the UI is responsive, although
> > cycle-accurate timing is not
From: Xiao Guangrong
Adapt the compression code to the lockless multithread model
Signed-off-by: Xiao Guangrong
---
migration/ram.c | 381 ++--
1 file changed, 175 insertions(+), 206 deletions(-)
diff --git a/migration/ram.c
* Marc-André Lureau (marcandre.lur...@redhat.com) wrote:
> Hi
>
> On Mon, Jun 4, 2018 at 11:07 AM, Dr. David Alan Gilbert
> wrote:
> > * Marc-André Lureau (marcandre.lur...@redhat.com) wrote:
> >> Ask vhost user input backend the list of virtio_input_config.
> >
> > Why is this vhost-user
From: Xiao Guangrong
Current implementation of compression and decompression are very
hard to be enabled on productions. We noticed that too many wait-wakes
go to kernel space and CPU usages are very low even if the system
is really free
The reasons are:
1) there are two many locks used to do
From: Xiao Guangrong
Adapt the compression code to the lockless multithread model
Signed-off-by: Xiao Guangrong
---
migration/ram.c | 412 ++--
1 file changed, 161 insertions(+), 251 deletions(-)
diff --git a/migration/ram.c
From: Xiao Guangrong
flush_compressed_data() needs to wait all compression threads to
finish their work, after that all threads are free until the
migration feed new request to them, reducing its call can improve
the throughput and use CPU resource more effectively
We do not need to flush all
On Fri, Jun 01, 2018 at 07:26:03AM -0500, Eric Blake wrote:
> On 05/31/2018 04:17 PM, Ari Sundholm wrote:
> > +static void blk_log_writes_co_do_file(void *opaque)
> > +{
> > +BlkLogWritesFileReq *fr = opaque;
> > +
> > +fr->file_ret = fr->func(fr);
> > +
> > +fr->r->done++;
>
> Two
On 01.06.2018 14:13, Igor Mammedov wrote:
> On Fri, 25 May 2018 14:43:39 +0200
> David Hildenbrand wrote:
>
>> On 17.05.2018 10:15, David Hildenbrand wrote:
>>> We can have devices that need certain other resources that are e.g.
>>> system resources managed by the machine. We need a clean way to
From: Xiao Guangrong
Try to hold src_page_req_mutex only if the queue is not
empty
Signed-off-by: Xiao Guangrong
---
include/qemu/queue.h | 1 +
migration/ram.c | 4
2 files changed, 5 insertions(+)
diff --git a/include/qemu/queue.h b/include/qemu/queue.h
index
From: Xiao Guangrong
It's the simple lockless ring buffer implement which supports both
single producer vs. single consumer and multiple producers vs.
single consumer.
Many lessons were learned from Linux Kernel's kfifo (1) and DPDK's
rte_ring (2) before i wrote this implement. It corrects some
From: Xiao Guangrong
Instead of putting the main thread to sleep state to wait for
free compression thread, we can directly post it out as normal
page that reduces the latency and uses CPUs more efficiently
Signed-off-by: Xiao Guangrong
---
migration/ram.c | 34
From: Xiao Guangrong
It is used to slightly clean the code up, no logic is changed
Signed-off-by: Xiao Guangrong
---
migration/ram.c | 35 ++-
1 file changed, 22 insertions(+), 13 deletions(-)
diff --git a/migration/ram.c b/migration/ram.c
index
From: Xiao Guangrong
Detecting zero page is not a light work, we can disable it
for compression that can handle all zero data very well
Signed-off-by: Xiao Guangrong
---
migration/ram.c | 44 +++-
1 file changed, 23 insertions(+), 21 deletions(-)
diff
From: Xiao Guangrong
The compressed page is not normal page
Signed-off-by: Xiao Guangrong
---
migration/ram.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/migration/ram.c b/migration/ram.c
index 0caf32ab0a..dbf24d8c87 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -1432,7 +1432,6
From: Xiao Guangrong
Then the uses can adjust the parameters based on this info
Currently, it includes:
pages: amount of pages compressed and transferred to the target VM
busy: amount of count that no free thread to compress data
busy-rate: rate of thread busy
reduced-size: amount of bytes
From: Xiao Guangrong
Sync up xbzrle_cache_miss_prev only after migration iteration goes
forward
Signed-off-by: Xiao Guangrong
---
migration/ram.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/migration/ram.c b/migration/ram.c
index dbf24d8c87..dd1283dd45 100644
---
Hi,
> > One aim of our efforts is to create a user interface that models the
> > look and feel of the physical microbit board and lets the user interact
> > with its inputs and provide feedback on its outsputs.
> >
> > For this it is necessary to transmit user inputs such as the pressing of a
From: Xiao Guangrong
Background
--
Current implementation of compression and decompression are very
hard to be enabled on productions. We noticed that too many wait-wakes
go to kernel space and CPU usages are very low even if the system
is really free
The reasons are:
1) there are two
Qemu initialize the MigrationIncomingState structure in migration_object_init,
but not release it. this patch release it in migration_object_finalize.
Signed-off-by: Lidong Chen
---
migration/migration.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/migration/migration.c
On 01.06.2018 14:24, Igor Mammedov wrote:
> On Wed, 25 Apr 2018 16:54:12 +0530
> Pankaj Gupta wrote:
>
> [...]
>> - Qemu virtio-pmem device
>> It exposes a persistent memory range to KVM guest which
>> at host side is file backed memory and works as persistent
>> memory device. In
On Fri, Jun 01, 2018 at 05:24:53PM +0300, Ari Sundholm wrote:
> On 06/01/2018 04:32 PM, Stefan Hajnoczi wrote:
> > On Fri, Jun 01, 2018 at 12:17:19AM +0300, Ari Sundholm wrote:
> > > From: Aapo Vienamo
> >
> > Thanks for the patch!
> >
> > > Implements a block device write logging system,
On 2018-06-01 23:36, Eric Blake wrote:
> On 06/01/2018 07:32 AM, Max Reitz wrote:
>> 219 has two issues that may lead to sporadic failure, both of which are
>> the result of issuing query-jobs too early after a job has been
>> modified. This can then lead to different results based on whether the
On 2018-06-02 12:46, Michal Privoznik wrote:
> On 06/01/2018 03:28 PM, Max Reitz wrote:
>> Hi,
>>
>> The @preconfig RunState documentation states:
>>
>>> The state is reachable only if the --preconfig CLI option is used.
>>
>> However, this is not true:
>>
>> $ echo |
On Fri, Jun 01, 2018 at 04:15:52PM +0600, Artem Pisarenko wrote:
> Please, add important note to https://wiki.qemu.org/Features/VirtioVsock page,
> that this feature only supported in KVM accelerated mode. It's not obvious.
> Furthermore, it isn't checked by qemu when invoking with "-device
>
On Mon, Jun 04, 2018 at 04:54:45AM +0300, Michael S. Tsirkin wrote:
> On Mon, Jun 04, 2018 at 09:34:35AM +0800, Wei Xu wrote:
> > On Tue, Apr 10, 2018 at 03:32:53PM +0800, Jason Wang wrote:
> > >
> > >
> > > On 2018年04月04日 20:54, w...@redhat.com wrote:
> > > >From: Wei Xu
> > > >
> > > >helper
On Fri, Jun 01, 2018 at 06:27:48PM +0200, Marc-André Lureau wrote:
> Add to virtio-gpu devices a "vhost-user" property. When set, the
> associated vhost-user backend is used to handle the virtio rings.
>
> For now, a socketpair is created for the backend to share the rendering
> results with qemu
On Fri, Jun 01, 2018 at 06:27:41PM +0200, Marc-André Lureau wrote:
> Create a vhost-user-backend object that holds a connection to a
> vhost-user backend and can be referenced from virtio devices that
> support it. See later patches for input & gpu usage.
>
> A chardev can be specified to
On Wed, 30 May 2018 11:16:58 +0200
Thomas Huth wrote:
> With the STSI instruction, we can get the UUID of the current VM instance,
> so we can support loading pxelinux config files via UUID in the file name,
> too.
>
> Signed-off-by: Thomas Huth
> ---
> pc-bios/s390-ccw/netmain.c | 46
>
On 4 June 2018 at 10:20, Stefan Hajnoczi wrote:
> Many of these inputs/outputs can be tied to an external UI. A degree of
> timing precision is required so that the UI is responsive, although
> cycle-accurate timing is not what I'd expect from QMP.
Would we also be able to tie them to an
On Fri, Jun 01, 2018 at 05:26:38PM +0800, Fam Zheng wrote:
> v9: Don't break older libiscsi. [patchew]
>
> v8: Fix compiling against new glibc and libiscsi on Fedora 28 where v7 had
> conflict definitions. [Stefan, myself]
> - Add HAVE_COPY_FILE_RANGE in configure.
> - Drop
On Fri, Jun 01, 2018 at 06:27:47PM +0200, Marc-André Lureau wrote:
> Add a new vhost-user message to give a unix socket for gpu updates to
> a vhost-user backend.
>
> Back when I started that work, I added a new GPU channel because the
> vhost-user protocol wasn't bidirectional. Since then, there
On Thu, May 31, 2018 at 08:00:34PM -0400, John Snow wrote:
> On 05/30/2018 08:43 PM, John Snow wrote:
> > Commit d759c951f changed the main thread lock release/reacquisition,
> > and in so doing apparently jostled loose a race condition in the AHCI
> > code.
> >
> > Patch 2 should be sufficient
On Sun, Jun 03, 2018 at 04:34:12PM -0400, Steffen Görtz wrote:
> Changes in v2:
> - Remove stray 1
>
> Changes in v1:
> - Fix coding style issues
>
> Add a new category "stimulate" to host commands that
> act upon high-level devices associated with machines/boards.
>
> This is patch is part
Hi
On Mon, Jun 4, 2018 at 11:07 AM, Dr. David Alan Gilbert
wrote:
> * Marc-André Lureau (marcandre.lur...@redhat.com) wrote:
>> Ask vhost user input backend the list of virtio_input_config.
>
> Why is this vhost-user specific; shouldn't the vhost-input
> behaviour be the same irrespective of if
On 1 June 2018 at 18:15, Paolo Bonzini wrote:
> The following changes since commit 5a5c383b1373aeb6c87a0d6060f6c3dc7c53082b:
>
> Merge remote-tracking branch
> 'remotes/vivier2/tags/linux-user-for-2.13-pull-request' into staging
> (2018-05-25 10:04:36 +0100)
>
> are available in the Git
On 1 June 2018 at 17:20, Alex Bennée wrote:
> The following changes since commit c25e8bba1f546ea72744ccfab77f8a9e8a323be8:
>
> Merge remote-tracking branch 'remotes/otubo/tags/pull-seccomp-20180601'
> into staging (2018-06-01 13:11:30 +0100)
>
> are available in the Git repository at:
>
>
On Mon, Jun 04, 2018 at 06:06:04PM +0930, Joel Stanley wrote:
> On 4 June 2018 at 17:34, David Gibson wrote:
> > On Thu, May 31, 2018 at 10:34:29PM +0930, Joel Stanley wrote:
> >> @@ -98,6 +99,15 @@ void helper_store_ptcr(CPUPPCState *env, target_ulong
> >> val)
> >>
* Marc-André Lureau (marcandre.lur...@redhat.com) wrote:
> Ask vhost user input backend the list of virtio_input_config.
Why is this vhost-user specific; shouldn't the vhost-input
behaviour be the same irrespective of if it's vhost-user or plain vhost?
Dave
> Signed-off-by: Marc-André Lureau
> +#define TYPE_VHOST_USER_INPUT_PCI "vhost-user-input-pci"
Patch $subject mismatch.
> +struct VHostUserInput {
> +VirtIOInput parent_obj;
> +
> +VhostUserBackend *vhost;
> +};
Nothing input specific here ...
> +static void
On Thu, 17 May 2018 19:23:38 +0300
Viktor Prutyanov wrote:
> Recently a Windows guest driver has been added with the ability to
> publish the data needed to produce useful guest dumps on the
> hypervisor side. The data is wrapped in a standard VMCOREINFO
> container and is exposed to the
On Fri, Jun 01, 2018 at 11:38:08AM -0400, Konrad Rzeszutek Wilk wrote:
> AMD future CPUs expose _two_ ways to utilize the Intel equivalant
> of the Speculative Store Bypass Disable. The first is via
> the virtualized VIRT_SPEC CTRL MSR (0xC001_011f) and the second
> is via the SPEC_CTRL MSR
Just set the full_update flag if we need a new DisplaySurface. Create
a new surface when the flag is set instead of having two places where
qemu_create_displaysurface_from() is called.
Signed-off-by: Gerd Hoffmann
Message-id: 20180525131318.28437-1-kra...@redhat.com
---
hw/display/vga.c | 36
The following changes since commit 392fba9f583223786f844dce9b2e7f9a0ce0147a:
Merge remote-tracking branch
'remotes/stsquad/tags/pull-travis-updates-010618-1' into staging (2018-06-01
17:32:30 +0100)
are available in the git repository at:
git://git.kraxel.org/qemu tags/vga-20180604-pull
Fixes: CID 1391291
Signed-off-by: Gerd Hoffmann
Reviewed-by: Ján Tomko
Reviewed-by: Philippe Mathieu-Daudé
Message-id: 20180525045344.28347-1-kra...@redhat.com
---
hw/display/bochs-display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/display/bochs-display.c
The powerpc Linux kernel[1] and skiboot firmware[2] recently gained changes
that cause the Processor Compatibility Register (PCR) SPR to be cleared.
These changes cause Linux to fail to boot on the Qemu powernv machine
with an error:
Trying to write privileged spr 338 (0x152) at
On 4 June 2018 at 17:34, David Gibson wrote:
> On Thu, May 31, 2018 at 10:34:29PM +0930, Joel Stanley wrote:
>> @@ -98,6 +99,15 @@ void helper_store_ptcr(CPUPPCState *env, target_ulong val)
>> tlb_flush(CPU(cpu));
>> }
>> }
>> +
>> +void helper_store_pcr(CPUPPCState *env,
On 2018年06月04日 01:44, Wei Xu wrote:
+static int virtio_queue_empty_packed_rcu(VirtQueue *vq)
+{
+struct VRingDescPacked desc;
+VRingMemoryRegionCaches *cache;
+
+if (unlikely(!vq->packed.desc)) {
+return 1;
+}
+
+cache = vring_get_region_caches(vq);
+
On Mon, Jun 04, 2018 at 12:59:04PM +0800, Peter Xu wrote:
> On Thu, May 31, 2018 at 09:42:23AM -0500, Eric Blake wrote:
> > On 05/31/2018 12:16 AM, Peter Xu wrote:
> > > This event is not really necessary. After OOB series it might affect
> > > the timing of the script so this event may or may
201 - 300 of 326 matches
Mail list logo
