On 06/06/2018 08:39 AM, David Gibson wrote:
> On Wed, May 30, 2018 at 12:07:54PM +0200, Cédric Le Goater wrote:
>> Based on previous work done in skiboot, the physical mapping array
>> helps in calculating the MMIO ranges of each controller depending on
>> the chip id and the chip type. This is wil
On Wed, Jun 06, 2018 at 02:56:29PM +0800, Peter Xu wrote:
[...]
> > The patches you've
> > sent here seem to me to be adding extra complexity to the
> > notifier API and the core code which isn't required in
> > the patch set that I sent.
>
> Again I didn't really understand the problem behind b
On Tue, 5 Jun 2018 15:12:46 -0300
Eduardo Habkost wrote:
> On Tue, Jun 05, 2018 at 04:00:42PM +0200, Igor Mammedov wrote:
> [...]
> > Based on
> > From: Michal Privoznik
> > Subject: [PATCH] cli: Don't run early event loop if no --preconfig was
> > specified
> > Message-Id:
> >
> >
>
> From: Thomas Huth [mailto:th...@redhat.com]
> On 05.06.2018 12:39, Pavel Dovgalyuk wrote:
> > From: Pavel Dovgalyuk
> >
> > This patch adds functions and headers for adding the helpers from
> > the modules other than the target translators.
> >
> > Signed-off-by: Pavel Dovgalyuk
> > ---
> > in
POWER9 introduced a new variant of the eieio instruction using bit 6
as a hint to tell the CPU it is a store-forwarding barrier.
The usage of this eieio extension was recently added in Linux 4.17
which activated the "support for a store forwarding barrier at kernel
entry/exit".
Unfortunately, it
On Wed, Jun 06, 2018 at 08:42:08AM +0200, Cédric Le Goater wrote:
> On 06/06/2018 08:32 AM, David Gibson wrote:
> > On Wed, Jun 06, 2018 at 08:08:30AM +0200, Cédric Le Goater wrote:
> >> POWER9 introduced a new variant of the eieio instruction using bit 6
> >> as a hint to tell the CPU it is a stor
* Michael S. Tsirkin (m...@redhat.com) wrote:
> On Tue, Jun 05, 2018 at 03:09:17PM -0500, Eric Blake wrote:
> > On 06/05/2018 02:58 PM, Richard W.M. Jones wrote:
> > > > Binary blobs can always be base64 encoded for representation within
> > > > a valid JSON UTF-8 string (and we already have severa
On Tue, 5 Jun 2018 15:30:01 -0300
Eduardo Habkost wrote:
> On Tue, Jun 05, 2018 at 04:00:43PM +0200, Igor Mammedov wrote:
> > 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 --p
* Peter Xu (pet...@redhat.com) wrote:
> On Wed, Jun 06, 2018 at 11:36:00AM +0800, Peter Xu wrote:
> > On Tue, Jun 05, 2018 at 05:25:45PM +0100, Dr. David Alan Gilbert (git)
> > wrote:
> > > From: "Dr. David Alan Gilbert"
> > >
> > > The migration code should be using the
> > > RAMBLOCK_FOREACH
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
Hi,
> > Maybe we should for now just scratch the idea of an virtio-ramfb device.
> > Linux doesn't need it, and windows wouldn't use the virtio part of it so
> > a standalone ramfb device would work equally well.
>
> If that works for you, it works for me best!
Ok, pushed updated branches.
q
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 152819515565.30857.16834004920507717324.stgit@pasha-ThinkPad-T60
Subject: [Qemu-devel] [RFC PATCH v2 0/7] QEMU binary instrumentation prototype
=== TEST SCRIPT BEGIN ===
#!/b
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 1528207243-268226-1-git-send-email-imamm...@redhat.com
Subject: [Qemu-devel] [PATCH v3 0/2] fix -nodefaults and -daemonize regressions
caused by --preconfig introduction
===
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20180605180836.21485-1-ppan...@redhat.com
Subject: [Qemu-devel] [PATCH 0/2] correct size computation in m_cat
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
total=$(git
On Wed, Jun 06, 2018 at 09:35:24AM +0100, Dr. David Alan Gilbert wrote:
> * Peter Xu (pet...@redhat.com) wrote:
> > On Wed, Jun 06, 2018 at 11:36:00AM +0800, Peter Xu wrote:
> > > On Tue, Jun 05, 2018 at 05:25:45PM +0100, Dr. David Alan Gilbert (git)
> > > wrote:
> > > > From: "Dr. David Alan Gilb
** 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/1155677
Title:
snapshot=on fails with non file-based storage
Status in QEMU:
Won't Fix
B
Closing this ticket now since there hasn't been any response within the
last months
** 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/1084148
T
Hi Richard,
I cannot find this patch on qemu master branch. Do you need any help
to get this done?
Thanks!
On Wed, Jul 12, 2017 at 8:45 PM Richard Henderson wrote:
>
> The implementation of these two instructions was swapped.
> At the same time, unify the setup of eflags for the insn group.
>
>
On Wed, 6 Jun 2018 10:53:17 +1000
David Gibson wrote:
> On Tue, Jun 05, 2018 at 06:46:12PM +0200, Greg Kurz wrote:
> > On Mon, 4 Jun 2018 10:53:22 +1000
> > David Gibson wrote:
> >
> > > On Mon, May 07, 2018 at 01:52:42PM -0300, luporl wrote:
> > > > According to PowerISA, the PIR register
From: Luc MICHEL
This commit improve the way the GIC is realized and connected in the
ZynqMP SoC. The security extensions are enabled only if requested in the
machine state. The same goes for the virtualization extensions.
All the GIC to APU CPU(s) IRQ lines are now connected, including FIQ,
vIR
From: Luc MICHEL
Add some traces to the ARM GIC to catch register accesses (distributor,
(v)cpu interface and virtual interface), and to take into account
virtualization extensions (print `vcpu` instead of `cpu` when needed).
Also add some virtualization extensions specific traces: LR updating
a
From: Luc MICHEL
Some functions are now only used in arm_gic.c, put them static. Some of
them where only used by the NVIC implementation and are not used
anymore, so remove them.
Signed-off-by: Luc MICHEL
---
hw/intc/arm_gic.c | 23 ++-
hw/intc/gic_internal.h | 4
From: Luc MICHEL
Add the necessary parts of the virtualization extensions state to the
GIC state. We choose to increase the size of the CPU interfaces state to
add space for the vCPU interfaces (the GIC_NCPU_VCPU macro). This way,
we'll be able to reuse most of the CPU interface code for the vCPU
From: Luc MICHEL
In preparation for the virtualization extensions implementation,
refactor the name of the functions and macros that act on the GIC
distributor to make that fact explicit. It will be useful to
differentiate them from the ones that will act on the virtual
interfaces.
Signed-off-by
From: Luc MICHEL
This commit adds the actual implementation of the GICv2 virtualization
extensions logic.
For the vCPU interfaces, most of the existing CPU interface code is
reused. Calls to macros or functions modifying the distributor state are
replaced with equivalent generic inline functions
From: Luc MICHEL
This patch series add support for the virtualization extensions in the
ARM GICv2 interrupt controller.
The first two commits do some refactoring to prepare for the
implementation. Commits 3 and 4 are the actual implementation. The last
commit updates the ZynqMP implementation to
* Eduardo Habkost (ehabk...@redhat.com) wrote:
> On Tue, Jun 05, 2018 at 10:21:59AM +0100, Dr. David Alan Gilbert wrote:
> >
> >
> > This seems to have fizzled out because of a lack of a concrete proposal;
> > so here is one based on a reply to Max's post:
> >
> > * Max Reitz (mre...@redhat.com)
On 06/06/2018 01:42 PM, Peter Xu wrote:
IMHO migration states do not suite here. IMHO bitmap syncing is too
frequently an operation, especially at the end of a precopy migration.
If you really want to introduce some notifiers, I would prefer
something new rather than fiddling around with migrat
Hi,
This series failed docker-mingw@fedora build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
Type: series
Message-id: 152819515565.30857.16834004920507717324.stgit@pasha-ThinkPad-T60
Subject: [Qemu-devel] [RF
On 06/06/2018 02:43 PM, Peter Xu wrote:
On Tue, Apr 24, 2018 at 02:13:47PM +0800, Wei Wang wrote:
[...]
+if (elem->out_num) {
+size = iov_to_buf(elem->out_sg, elem->out_num, 0, &id, sizeof(id));
+virtqueue_push(vq, elem, size);
Silly question: is this sending the
On 01.06.2018 18: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:
>
> git://git.kernel.org/pub/scm/virt/kvm/mst/qemu
Hi,
This series failed build test on s390x host. Please find the details below.
Type: series
Message-id: 20180605180836.21485-1-ppan...@redhat.com
Subject: [Qemu-devel] [PATCH 0/2] correct size computation in m_cat
=== TEST SCRIPT BEGIN ===
#!/bin/bash
# Testing script will be invoked under the
On 2018-06-04 22:06, Jeff Cody wrote:
> On Mon, Jun 04, 2018 at 04:14:36PM +0200, Max Reitz wrote:
>> When signaling a corruption on a read-only image, qcow2 already makes
>> fatal events non-fatal (i.e., they will not result in the image being
>> closed, and the image header's corrupt flag will no
Hi,
This series failed docker-mingw@fedora build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
Type: series
Message-id: 1528233505-25842-1-git-send-email-th...@redhat.com
Subject: [Qemu-devel] [PATCH] hw/arm: R
On Tue, 29 May 2018 12:14:15 +0200
Max Reitz wrote:
> On 2018-05-29 08:44, Kevin Wolf wrote:
> > Am 28.05.2018 um 23:25 hat Richard W.M. Jones geschrieben:
> >> On Mon, May 28, 2018 at 10:20:54PM +0100, Richard W.M. Jones
> >> wrote:
> >>> On Mon, May 28, 2018 at 08:38:33PM +0200, Kevin Wolf
On 2018-06-04 22:24, Igor Mammedov wrote:
> On Mon, 4 Jun 2018 16:04:33 +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 on
From: Prasad J Pandit
Hello,
While reassembling incoming fragmented datagrams, 'm_cat' routine
extends the 'mbuf' buffer if it has insufficient room. It computes
a wrong buffer size, which leads to overwriting adjacent heap buffer
area.
This patch set fixes this issue and formats m_cat() routin
From: Prasad J Pandit
While reassembling incoming fragmented datagrams, 'm_cat' routine
extends the 'mbuf' buffer, if it has insufficient room. It computes
a wrong buffer size, which leads to overwriting adjacent heap buffer
area. Correct this size computation in m_cat.
Reported-by: ZDI Disclosu
From: Prasad J Pandit
Coding style changes to the m_cat routine and minor refactoring.
Signed-off-by: Prasad J Pandit
---
slirp/mbuf.c | 36
1 file changed, 16 insertions(+), 20 deletions(-)
diff --git a/slirp/mbuf.c b/slirp/mbuf.c
index 6650981fc7..e012cd
Hi Gerd,
When using the gtk frontend, it seems there is a busy loop in libgtk repeatedly
calling recvmsg, causing 100% cpu on the main thread. This started to appear
after I upgraded to Fedora 28. Is this a known problem?
Any hints on how to track it down?
Fam
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20180605194725.8585-1-laur...@vivier.eu
Subject: [Qemu-devel] [PATCH] qemu-binfmt-conf.sh: ignore the OS/ABI field
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
total=
Hi,
This series failed docker-mingw@fedora build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
Type: series
Message-id: 20180605200425.24323.56023.st...@gimli.home
Subject: [Qemu-devel] [PULL 0/6] VFIO updates
On Wed, 6 Jun 2018 12:35:07 +0200
Max Reitz wrote:
> On 2018-06-04 22:24, Igor Mammedov wrote:
> > On Mon, 4 Jun 2018 16:04:33 +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 @pr
On 2018-06-06 11:30, luc.mic...@greensocs.com wrote:
> From: Luc MICHEL
>
> This patch series add support for the virtualization extensions in the
> ARM GICv2 interrupt controller.
>
> The first two commits do some refactoring to prepare for the
> implementation. Commits 3 and 4 are the actual i
On 2018-06-05 11:21, Dr. David Alan Gilbert wrote:
>
>
> This seems to have fizzled out because of a lack of a concrete proposal;
> so here is one based on a reply to Max's post:
>
> * Max Reitz (mre...@redhat.com) wrote:
>
>
>
>> The original problem was that you need to supply a machine typ
On Wed, Jun 06, 2018 at 06:04:23PM +0800, Wei Wang wrote:
> On 06/06/2018 01:42 PM, Peter Xu wrote:
> >
> > IMHO migration states do not suite here. IMHO bitmap syncing is too
> > frequently an operation, especially at the end of a precopy migration.
> > If you really want to introduce some notif
On 2018-06-06 12:32, Michal Suchánek wrote:
> On Tue, 29 May 2018 12:14:15 +0200
> Max Reitz wrote:
>
>> On 2018-05-29 08:44, Kevin Wolf wrote:
>>> Am 28.05.2018 um 23:25 hat Richard W.M. Jones geschrieben:
On Mon, May 28, 2018 at 10:20:54PM +0100, Richard W.M. Jones
wrote:
> On
* Max Reitz (mre...@redhat.com) wrote:
> On 2018-06-05 11:21, Dr. David Alan Gilbert wrote:
> >
> >
> > This seems to have fizzled out because of a lack of a concrete proposal;
> > so here is one based on a reply to Max's post:
> >
> > * Max Reitz (mre...@redhat.com) wrote:
> >
> >
> >
> >> T
On Wed, 6 Jun 2018 13:02:53 +0200
Max Reitz wrote:
> On 2018-06-06 12:32, Michal Suchánek wrote:
> > On Tue, 29 May 2018 12:14:15 +0200
> > Max Reitz wrote:
> >
> >> On 2018-05-29 08:44, Kevin Wolf wrote:
> >>> Am 28.05.2018 um 23:25 hat Richard W.M. Jones geschrieben:
> On Mon, Ma
On Wed, Jun 06, 2018 at 13:02:56 +0200, Max Reitz wrote:
> On 2018-06-05 11:21, Dr. David Alan Gilbert wrote:
[...]
> > (I would suggest in layer2 that the keys are sorted, but
> > that's a pain to do in some json creators)
> >c) Forcing the registry of keys might avoid silly dupl
On 2018-06-06 13:14, Dr. David Alan Gilbert wrote:
> * Max Reitz (mre...@redhat.com) wrote:
>> On 2018-06-05 11:21, Dr. David Alan Gilbert wrote:
>>>
>>>
>>> This seems to have fizzled out because of a lack of a concrete proposal;
>>> so here is one based on a reply to Max's post:
>>>
>>> * Max Re
On 2018-06-06 13:19, Michal Suchánek wrote:
> On Wed, 6 Jun 2018 13:02:53 +0200
> Max Reitz wrote:
>
>> On 2018-06-06 12:32, Michal Suchánek wrote:
>>> On Tue, 29 May 2018 12:14:15 +0200
>>> Max Reitz wrote:
>>>
On 2018-05-29 08:44, Kevin Wolf wrote:
> Am 28.05.2018 um 23:25 hat Ri
* Max Reitz (mre...@redhat.com) wrote:
> On 2018-06-06 13:19, Michal Suchánek wrote:
> > On Wed, 6 Jun 2018 13:02:53 +0200
> > Max Reitz wrote:
> >
> >> On 2018-06-06 12:32, Michal Suchánek wrote:
> >>> On Tue, 29 May 2018 12:14:15 +0200
> >>> Max Reitz wrote:
> >>>
> On 2018-05-29 08:44
On Wed, Jun 06, 2018 at 06:43:57PM +0800, Fam Zheng wrote:
> Hi Gerd,
>
> When using the gtk frontend, it seems there is a busy loop in libgtk
> repeatedly
> calling recvmsg, causing 100% cpu on the main thread. This started to appear
> after I upgraded to Fedora 28. Is this a known problem?
No,
On Wed, Jun 06, 2018 at 06:43:57PM +0800, Fam Zheng wrote:
> Hi Gerd,
>
> When using the gtk frontend, it seems there is a busy loop in libgtk
> repeatedly
> calling recvmsg, causing 100% cpu on the main thread. This started to appear
> after I upgraded to Fedora 28. Is this a known problem?
>
>
On Wed, Jun 06, 2018 at 01:02:53PM +0200, Max Reitz wrote:
> (I'm wondering if we could write a block driver that could provide such
> a chunk allocation transparently to qcow2... Note that a qcow2 file
> does not need to be continuous, so you could in theory indeed store the
> qcow2 file and its
On Wed, Jun 06, 2018 at 12:14:07PM +0100, Dr. David Alan Gilbert wrote:
> The problem with having a separate file is that you either have to copy
> it around with the image or have an archive. If you have an archive
> you have to have an unpacking step which then copies, potentially a lot
> of dat
On Wed, 6 Jun 2018 13:32:47 +0200
Max Reitz wrote:
> On 2018-06-06 13:19, Michal Suchánek wrote:
> > On Wed, 6 Jun 2018 13:02:53 +0200
> > Max Reitz wrote:
> >
> >> On 2018-06-06 12:32, Michal Suchánek wrote:
> >>> On Tue, 29 May 2018 12:14:15 +0200
> >>> Max Reitz wrote:
> >>>
>
On 2018-06-06 13:37, Dr. David Alan Gilbert wrote:
> * Max Reitz (mre...@redhat.com) wrote:
>> On 2018-06-06 13:19, Michal Suchánek wrote:
>>> On Wed, 6 Jun 2018 13:02:53 +0200
>>> Max Reitz wrote:
>>>
On 2018-06-06 12:32, Michal Suchánek wrote:
> On Tue, 29 May 2018 12:14:15 +0200
>
On Wed, Jun 06, 2018 at 12:42:28PM +0100, Richard W.M. Jones wrote:
> On Wed, Jun 06, 2018 at 12:14:07PM +0100, Dr. David Alan Gilbert wrote:
> > The problem with having a separate file is that you either have to copy
> > it around with the image or have an archive. If you have an archive
> > you
On 2018-06-06 13:43, Michal Suchánek wrote:
> On Wed, 6 Jun 2018 13:32:47 +0200
> Max Reitz wrote:
>
>> On 2018-06-06 13:19, Michal Suchánek wrote:
>>> On Wed, 6 Jun 2018 13:02:53 +0200
>>> Max Reitz wrote:
>>>
On 2018-06-06 12:32, Michal Suchánek wrote:
> On Tue, 29 May 2018 12:14
On 2018-06-06 13:48, Daniel P. Berrangé wrote:
> On Wed, Jun 06, 2018 at 12:42:28PM +0100, Richard W.M. Jones wrote:
>> On Wed, Jun 06, 2018 at 12:14:07PM +0100, Dr. David Alan Gilbert wrote:
>>> The problem with having a separate file is that you either have to copy
>>> it around with the image or
I'd like to share some other available workarounds:
1. Use "-machine type=pc-i440fx-x" where x <= 2.6
2. Add "disable-modern=on" option for all virtio block devices
3. Add "-global virtio-blk-pci.disable-modern=on"
3. Use software acceleration for virtual appliances ("-machine accel=tcg")
--
You
* Max Reitz (mre...@redhat.com) wrote:
> On 2018-06-06 13:14, Dr. David Alan Gilbert wrote:
> > * Max Reitz (mre...@redhat.com) wrote:
> >> On 2018-06-05 11:21, Dr. David Alan Gilbert wrote:
> >>>
> >>>
> >>> This seems to have fizzled out because of a lack of a concrete proposal;
> >>> so here is
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Wed, Jun 06, 2018 at 12:42:28PM +0100, Richard W.M. Jones wrote:
> > On Wed, Jun 06, 2018 at 12:14:07PM +0100, Dr. David Alan Gilbert wrote:
> > > The problem with having a separate file is that you either have to copy
> > > it around with the
Public bug reported:
It whould be nice if the qemu-ga allowed received messages to contain
fields which is not part of the spec. In my example I have a host which
sends the following request:
{"execute":"guest-exec","arguments":{"path":"prl_nettool","capture-
output":true,"execute-in-shell":false
* Max Reitz (mre...@redhat.com) wrote:
> On 2018-06-06 13:37, Dr. David Alan Gilbert wrote:
> > * Max Reitz (mre...@redhat.com) wrote:
> >> On 2018-06-06 13:19, Michal Suchánek wrote:
> >>> On Wed, 6 Jun 2018 13:02:53 +0200
> >>> Max Reitz wrote:
> >>>
> On 2018-06-06 12:32, Michal Suchánek w
On Wed, 6 Jun 2018 13:52:35 +0200
Max Reitz wrote:
> On 2018-06-06 13:43, Michal Suchánek wrote:
> > On Wed, 6 Jun 2018 13:32:47 +0200
> > Max Reitz wrote:
> >
> >> On 2018-06-06 13:19, Michal Suchánek wrote:
> >>> On Wed, 6 Jun 2018 13:02:53 +0200
> >>> Max Reitz wrote:
> >>>
>
On Tue, 5 Jun 2018 17:23:02 +0200
Pierre Morel wrote:
> On 05/06/2018 15:14, Cornelia Huck wrote:
> > On Tue, 22 May 2018 17:10:44 +0200
> > Pierre Morel wrote:
> >
> >> On 22/05/2018 14:52, Cornelia Huck wrote:
> >>> On Wed, 16 May 2018 15:32:48 +0200
> >>> Pierre Morel wrote:
> >>>
>
On Wed, Jun 06, 2018 at 12:48:17PM +0100, Daniel P. Berrangé wrote:
> On Wed, Jun 06, 2018 at 12:42:28PM +0100, Richard W.M. Jones wrote:
> > On Wed, Jun 06, 2018 at 12:14:07PM +0100, Dr. David Alan Gilbert wrote:
> > > The problem with having a separate file is that you either have to copy
> > > i
On 06/06/2018 11:13, Ricardo Ribalda Delgado wrote:
> Hi Richard,
>
> I cannot find this patch on qemu master branch. Do you need any help
> to get this done?
I queued it now, thanks for the reminder!
Paolo
> Thanks!
> On Wed, Jul 12, 2017 at 8:45 PM Richard Henderson wrote:
>>
>> The impleme
On Wed, Jun 6, 2018 at 2:56 AM, Tian, Kevin wrote:
>> From: Jintack Lim [mailto:jint...@cs.columbia.edu]
>> Sent: Tuesday, June 5, 2018 8:57 PM
>>
>> Thanks, Kevin.
>>
>> On Tue, Jun 5, 2018 at 2:54 AM, Tian, Kevin wrote:
>> >> From: Jintack Lim
>> >> Sent: Friday, June 1, 2018 11:47 AM
>> >>
>>
It has been marked as deprecated since QEMU v2.0 already, so it
is time now to finally remove it.
Signed-off-by: Thomas Huth
---
qemu-doc.texi | 7 ---
qemu-img-cmds.hx | 4 ++--
qemu-img.c | 7 +--
qemu-img.texi | 7 ++-
tests/qemu-iotests/029 | 2
On 06/06/18 10:49, Gerd Hoffmann wrote:
> edk2:
>QemuRamfbDxe driver, x86 wireup, incomplete arm wireup.
I'm looking at the patches very cursorily right now:
> Notes on QemuRamfbDxe:
>
> QemuRamfbDxe registers as VenHw device with a fresh generated uuid.
> The uuid should probably go to some
On 06/05/2018 06:31 AM, Eric Blake wrote:
On 06/04/2018 04:55 AM, guangrong.x...@gmail.com wrote:
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
On 2018-06-06 14:00, Dr. David Alan Gilbert wrote:
> * Max Reitz (mre...@redhat.com) wrote:
>> On 2018-06-06 13:14, Dr. David Alan Gilbert wrote:
>>> * Max Reitz (mre...@redhat.com) wrote:
On 2018-06-05 11:21, Dr. David Alan Gilbert wrote:
>
>
> This seems to have fizzled out beca
Max Reitz writes:
> On 2018-05-10 16:54, Eric Blake wrote:
>> On 05/09/2018 11:55 AM, Max Reitz wrote:
>>> There are numerous QDict functions that have been introduced for and are
>>> used only by the block layer. Move their declarations into an own
>>
>> s/an own/their own/
>>
>>> header file
On 2018-06-06 14:13, Michal Suchánek wrote:
> On Wed, 6 Jun 2018 13:52:35 +0200
> Max Reitz wrote:
>
>> On 2018-06-06 13:43, Michal Suchánek wrote:
>>> On Wed, 6 Jun 2018 13:32:47 +0200
>>> Max Reitz wrote:
>>>
On 2018-06-06 13:19, Michal Suchánek wrote:
> On Wed, 6 Jun 2018 13:02:
On 2018-06-06 14:03, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrangé (berra...@redhat.com) wrote:
>> On Wed, Jun 06, 2018 at 12:42:28PM +0100, Richard W.M. Jones wrote:
>>> On Wed, Jun 06, 2018 at 12:14:07PM +0100, Dr. David Alan Gilbert wrote:
The problem with having a separate file is t
MAINTAINERS files include/block/qdict.h under "Block layer core". Let's
split qobject/qdict.c as well, so it's there, too. Obvious patch
appended. Feel free to squash it into yours without giving me credit
for it.
PS: I tried to move block-qdict.c to block/, but totally failed at
persuading Mak
On Tue, Jun 05, 2018 at 02:59:05PM -0400, John Snow wrote:
> From: Vladimir Sementsov-Ogievskiy
>
> This is needed, for example, to create a new bitmap and merge several
> disabled bitmaps into a new one. Without this flag we will have to
> put block-dirty-bitmap-add and block-dirty-bitmap-disabl
Hi,
> > QemuRamfbDxe registers as VenHw device with a fresh generated uuid.
> > The uuid should probably go to some header file, suggestions where to
> > place it best?
>
> (1) Under "OvmfPkg/Include/Guid/". The file "VirtioMmioTransport.h" is a
> minimal example.
Ok.
> (4) Once you add the v
On Tue, Jun 05, 2018 at 02:59:02PM -0400, John Snow wrote:
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> [Added x- prefix. --js]
> Signed-off-by: John Snow
> ---
> blockdev.c | 42 ++
> qapi/block-core.json | 42
On Tue, Jun 05, 2018 at 02:59:01PM -0400, John Snow wrote:
> From: Vladimir Sementsov-Ogievskiy
>
> Add locks and remove comments about BQL accordingly to
> dirty_bitmap_mutex definition in block_int.h.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> Signed-off-by: John Snow
Reviewed-by: Je
On 2018-06-06 14:16, Dr. David Alan Gilbert wrote:
> * Max Reitz (mre...@redhat.com) wrote:
>> On 2018-06-06 13:37, Dr. David Alan Gilbert wrote:
>>> * Max Reitz (mre...@redhat.com) wrote:
On 2018-06-06 13:19, Michal Suchánek wrote:
> On Wed, 6 Jun 2018 13:02:53 +0200
> Max Reitz wrot
Some old guests (before commit 7a11370e5: "virtio_blk: enable VQs early")
kick virtqueue before setting VIRTIO_CONFIG_S_DRIVER_OK. This violates
the virtio spec. But virtio 1.0 transitional devices support this behaviour.
So we should start vhost when guest kicks in this case.
Signed-off-by: Yongj
> On 5 June 2018 at 21:52, Dongjiu Geng wrote:
> > Import KVM_CAP_ARM_INJECT_SERROR_ESR and struct kvm_vcpu_events for
> > arm64
> >
> > Signed-off-by: Dongjiu Geng
>
> Was this produced with the update-headers script? If so, the commit message
> should say so and also which upstream kernel com
Hi Igor,
Thanks for your response firstly. :)
> -Original Message-
> From: Igor Mammedov [mailto:imamm...@redhat.com]
> Sent: Friday, June 01, 2018 6:23 PM
>
> On Fri, 1 Jun 2018 08:17:12 +
> xuyandong wrote:
>
> > Hi there,
> >
> > I am doing some test on qemu vcpu hotplug and I r
On Wed, Jun 06, 2018 at 10:44:20AM +0100, Dr. David Alan Gilbert wrote:
> * Eduardo Habkost (ehabk...@redhat.com) wrote:
> > On Tue, Jun 05, 2018 at 10:21:59AM +0100, Dr. David Alan Gilbert wrote:
> > >
> > >
> > > This seems to have fizzled out because of a lack of a concrete proposal;
> > > so
On 06/06/2018 06:31 AM, luc.mic...@greensocs.com wrote:
> From: Luc MICHEL
>
> Add some traces to the ARM GIC to catch register accesses (distributor,
> (v)cpu interface and virtual interface), and to take into account
> virtualization extensions (print `vcpu` instead of `cpu` when needed).
>
>
On 06/06/2018 06:30 AM, luc.mic...@greensocs.com wrote:
> From: Luc MICHEL
>
> Some functions are now only used in arm_gic.c, put them static. Some of
> them where only used by the NVIC implementation and are not used
> anymore, so remove them.
>
> Signed-off-by: Luc MICHEL
Reviewed-by: Philip
On 06/06/2018 06:30 AM, luc.mic...@greensocs.com wrote:
> From: Luc MICHEL
>
> In preparation for the virtualization extensions implementation,
> refactor the name of the functions and macros that act on the GIC
> distributor to make that fact explicit. It will be useful to
> differentiate them f
On 05/06/2018 01:06, Justin Terry (VM) wrote:
> Paolo - I saw that this merged with commit:
> 327fccb288976f95808efa968082fc9d4a9ced84 but it seems to be missing
> whp-dispatch.h so now the build is failing. Any idea how this file failed to
> get included?
My mistake, I'll add it.
Paolo
> Th
On Wed, Jun 06, 2018 at 01:44:02PM +0200, Max Reitz wrote:
> On 2018-06-06 13:37, Dr. David Alan Gilbert wrote:
> > * Max Reitz (mre...@redhat.com) wrote:
> >> On 2018-06-06 13:19, Michal Suchánek wrote:
> >>> On Wed, 6 Jun 2018 13:02:53 +0200
> >>> Max Reitz wrote:
> >>>
> On 2018-06-06 12:3
On 05/06/2018 01:27, John Snow wrote:
>
>
> On 06/04/2018 11:50 AM, Paolo Bonzini wrote:
>> On 02/06/2018 03:22, John Snow wrote:
>>> - Status: Should be the status register after receiving the H2D Register
>>> update FIS, but prior to the data transfer, I think. "New value of the
>>> Status
On Wed, 6 Jun 2018 15:14:03 +0200
Max Reitz wrote:
> On 2018-06-06 14:13, Michal Suchánek wrote:
> > On Wed, 6 Jun 2018 13:52:35 +0200
> > Max Reitz wrote:
> >
> >> On 2018-06-06 13:43, Michal Suchánek wrote:
> >>> On Wed, 6 Jun 2018 13:32:47 +0200
> >>> Max Reitz wrote:
> >>>
>
On Wed, Jun 06, 2018 at 03:45:10PM +0200, Michal Suchánek wrote:
>
> I think that *if* we want an 'appliance' format that stores a whole VM
> in a single file to ease VM distribution then the logical place to look
> in qemu is qcow. The reason have been explained at length.
I rather disagree. Thi
On Wed, Jun 06, 2018 at 10:37:05AM +0200, Igor Mammedov wrote:
[...]
> @@ -4578,6 +4579,13 @@ int main(int argc, char **argv, char **envp)
> parse_numa_opts(current_machine);
>
> /* do monitor/qmp handling at preconfig state if requested */
> +if (!preconfig_exit_requested && is_dae
Signed-off-by: BALATON Zoltan
---
default-configs/ppc-softmmu.mak| 1 +
default-configs/ppcemb-softmmu.mak | 1 +
hw/i2c/ppc4xx_i2c.c| 14 +-
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/default-configs/ppc-softmmu.mak b/default-configs/ppc-soft
Basic emulation of the M41T80 serial (I2C) RTC chip. Only getting time
of day is implemented. Setting time and RTC alarm are not supported.
Signed-off-by: BALATON Zoltan
---
MAINTAINERS | 1 +
default-configs/ppc-softmmu.mak | 1 +
hw/timer/Makefile.objs | 1 +
1 - 100 of 341 matches
Mail list logo
