Hurray!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1714750
Title:
2.10.0 cannot be installed on case-insensitive file system
Status in QEMU:
New
Bug description:
The https://download.qemu.
Le 02/10/2017 à 11:07, Igor Mammedov a écrit :
> Signed-off-by: Igor Mammedov
> ---
> CC: laur...@vivier.eu
> CC: h...@tuxfamily.org
> ---
> hw/m68k/mcf5208.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/hw/m68k/mcf5208.c b/hw/m68k/mcf5208.c
> index b9dde75..cf
Le 02/10/2017 à 11:07, Igor Mammedov a écrit :
> Signed-off-by: Igor Mammedov
> ---
> CC: h...@tuxfamily.org
> CC: laur...@vivier.eu
> ---
> hw/m68k/an5206.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/hw/m68k/an5206.c b/hw/m68k/an5206.c
> index 9002c46..0cedc
On Tue, 3 Oct 2017 11:25:01 -0300
Eduardo Habkost wrote:
> On Tue, Oct 03, 2017 at 02:14:46PM +0200, Igor Mammedov wrote:
> > it will help to remove code duplication in places
> > that currently open code registration of static
> > type[s] and remove necessity to declare function
> > for type_ini
Thanks for checking again!
** Changed in: qemu
Status: Incomplete => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1320360
Title:
usb passthrough not working anymore
Status in
Hi All,
I added a field to "kvm_run" data structure in both Qemu and KVM to create
a communication interface for a VM security monitoring application in order
to avoid heavy modifications in the hypervisor.
The problem I'm facing is that when this field is updated in KVM after a VM
exit, I don't se
On 2 October 2017 at 12:11, Markus Armbruster wrote:
> The following changes since commit ab161529261928ae7f3556e3220829c34b2686ec:
>
> Merge remote-tracking branch
> 'remotes/dgilbert/tags/pull-migration-20170927a' into staging (2017-09-27
> 22:44:51 +0100)
>
> are available in the git reposi
On Tue, Oct 03, 2017 at 05:01:39PM +0200, Igor Mammedov wrote:
> On Tue, 3 Oct 2017 11:25:01 -0300
> Eduardo Habkost wrote:
>
> > On Tue, Oct 03, 2017 at 02:14:46PM +0200, Igor Mammedov wrote:
> > > it will help to remove code duplication in places
> > > that currently open code registration of s
On Tue, 3 Oct 2017 10:29:22 -0300
Philippe Mathieu-Daudé wrote:
> Hi Igor,
>
> On 10/03/2017 09:14 AM, Igor Mammedov wrote:
> > it will help to remove code duplication in places
> > that currently open code registration of static
> > type[s] and remove necessity to declare function
> > for type_
On 3 October 2017 at 13:14, Igor Mammedov wrote:
> it will help to remove code duplication in places
> that currently open code registration of static
> type[s] and remove necessity to declare function
> for type_init() to call, when only static types
> need to be registered.
>
> Signed-off-by: Ig
On 03/10/2017 05:15, John Snow wrote:
> For drive-backup and blockdev-backup, expose the manual-cull
> property, having it default to false. There are no universal
> creation parameters, so it must be added to each job type that
> it makes sense for individually.
>
> Signed-off-by: John Snow
> --
On 10/03/2017 11:57 AM, Paolo Bonzini wrote:
> On 03/10/2017 05:15, John Snow wrote:
>> For drive-backup and blockdev-backup, expose the manual-cull
>> property, having it default to false. There are no universal
>> creation parameters, so it must be added to each job type that
>> it makes sense
Hi Laszlo,
On 10/01/2017 04:56 AM, Laszlo Ersek wrote:
On 10/01/17 11:17, Laszlo Ersek wrote:
(3) Implement SEV encryption for pflash. A pflash chip can be in one of
two modes: (a) it reads and executes as ROM, or (b) it behaves like a
programmable (r/w) device with MMIO registers. Switching
The 32-bit ARM validate_guest_space() check tests whether the
specified -R value leaves enough space for us to put the
commpage in at 0x0f00. However it was incorrectly doing
a <= check for the check against (guest_base + guest_size),
which meant that it wasn't permitting the guest space to
but
On 8 July 2017 at 03:50, Richard Henderson wrote:
> We had a check using TARGET_VIRT_ADDR_SPACE_BITS to make sure
> that the allocation coming in from the command-line option was
> not too large, but that didn't include target-specific knowledge
> about other restrictions on user-space.
>
> Remove
* Jan Dakinevich (jan.dakinev...@virtuozzo.com) wrote:
>
>
> On 10/03/2017 05:02 PM, Eric Blake wrote:
> > On 10/03/2017 07:47 AM, Jan Dakinevich wrote:
> >> The command is intended for gathering virtio information such as status,
> >> feature bits, negotiation status. It is convenient and useful
On Tue, 3 Oct 2017 12:37:22 -0300
Eduardo Habkost wrote:
> On Tue, Oct 03, 2017 at 05:01:39PM +0200, Igor Mammedov wrote:
> > On Tue, 3 Oct 2017 11:25:01 -0300
> > Eduardo Habkost wrote:
> >
> > > On Tue, Oct 03, 2017 at 02:14:46PM +0200, Igor Mammedov wrote:
> > > > it will help to remove
On 20 September 2017 at 23:13, John Reiser wrote:
> Now that I know the nature of the conflict, then I will spend a
> handful of instructions to avoid [0xf700, +), and also the
> stack if it gets placed immediately below that.
Cool. I figured out why -R 0x didn't work and have sent
a
On Tue, 3 Oct 2017 16:44:28 +0100
Peter Maydell wrote:
> On 3 October 2017 at 13:14, Igor Mammedov wrote:
> > it will help to remove code duplication in places
> > that currently open code registration of static
> > type[s] and remove necessity to declare function
> > for type_init() to call, wh
On 3 October 2017 at 11:28, Paolo Bonzini wrote:
> The following changes since commit ab161529261928ae7f3556e3220829c34b2686ec:
>
> Merge remote-tracking branch
> 'remotes/dgilbert/tags/pull-migration-20170927a' into staging (2017-09-27
> 22:44:51 +0100)
>
> are available in the git repository
The qdev_unplug() function contains a g_assert(hotplug_ctrl) statement,
so QEMU crashes when the user tries to device_add + device_del a device
that does not have a corresponding hotplug controller. This could be
provoked for a couple of devices in the past (see commit 4c93950659487c7ad
or 84ebd3e8
On Mon, 2 Oct 2017, Eduardo Habkost wrote:
> On Thu, Sep 28, 2017 at 10:12:34AM -0300, Eduardo Habkost wrote:
> > On Thu, Sep 28, 2017 at 02:33:57AM -0600, Jan Beulich wrote:
> > > >>> On 27.09.17 at 21:56, wrote:
> > > > --- a/hw/xen/xen_pt.c
> > > > +++ b/hw/xen/xen_pt.c
> > > > @@ -964,6 +964,1
On 10/03/2017 11:13 AM, Greg Kurz wrote:
The offset of the root node is guaranteed to be 0.
This doesn't fix anything, it's just trivial cleanup of the two
remaining places where this was done under hw/ppc.
Signed-off-by: Greg Kurz
Reviewed-by: Daniel Henrique Barboza
---
hw/ppc/pnv.c
no-re...@patchew.org writes ("Re: [Qemu-devel] [PATCH RFC 0/6] xen:
xen-domid-restrict improvements"):
> This series seems to have some coding style problems. See output below for
> more information:
Thanks for this automatic mail. I have sorted out most of these.
However:
> ERROR: consider usi
Anthony PERARD writes ("Re: [Qemu-devel] [PATCH RFC 1/6] xen: link against
xentoolcore"):
> Here is a patch that I think will work, if libxentoolcore is release in
> Xen 4.10.
Thanks very much. I have, more or less, adopted this. Thanks also
for your other comments, which I have addressed.
Ian
On Tue, Oct 03, 2017 at 11:59:28AM -0400, John Snow wrote:
>
>
> On 10/03/2017 11:57 AM, Paolo Bonzini wrote:
> > On 03/10/2017 05:15, John Snow wrote:
> >> For drive-backup and blockdev-backup, expose the manual-cull
> >> property, having it default to false. There are no universal
> >> creation
> On 3 Oct 2017, at 15:45, Paolo Bonzini wrote:
>
> Alex (both of them), Sergio, anyone else who can help?
Very interested in this (and thanks!) but it will be a while
before I have a sensible number of cycles available to play
with this one again.
--
Alex Bligh
On Tue, Oct 03, 2017 at 17:21:43 +0100, Peter Maydell wrote:
> The 32-bit ARM validate_guest_space() check tests whether the
> specified -R value leaves enough space for us to put the
> commpage in at 0x0f00. However it was incorrectly doing
> a <= check for the check against (guest_base + gues
On Tue, Oct 03, 2017 at 06:37:37PM +0200, Igor Mammedov wrote:
> On Tue, 3 Oct 2017 12:37:22 -0300
> Eduardo Habkost wrote:
>
> > On Tue, Oct 03, 2017 at 05:01:39PM +0200, Igor Mammedov wrote:
> > > On Tue, 3 Oct 2017 11:25:01 -0300
> > > Eduardo Habkost wrote:
> > >
> > > > On Tue, Oct 03, 2
On 02.10.2017 17:36, Richard Henderson wrote:
On 10/01/2017 04:27 PM, Helge Deller wrote:
What I'm absolutely missing knowledge in is the emulation code in
qemu to really be able to emulate the missing hppa assembler instructions.
For example, the space registers, some other PSW bits, and so on.
A previous commit (4e5ee5b21c) broke USB pass-through by introducing
a typo in a configuration variable.
Signed-off-by: Thomas Jansen
On Tue, Oct 03, 2017 at 06:46:02PM +0200, Thomas Huth wrote:
> The qdev_unplug() function contains a g_assert(hotplug_ctrl) statement,
> so QEMU crashes when the user tries to device_add + device_del a device
> that does not have a corresponding hotplug controller. This could be
> provoked for a co
From: Peter Xu
IOThread is a general framework that contains IO loop environment and a
real thread behind. It's also good to be used internally inside qemu.
Provide some helpers for it to create iothreads to be used internally.
Put all the internal used iothreads into the internal object contai
After iothread is enabled internally inside QEMU with GMainContext, we
may encounter this warning when destroying the iothread:
(qemu-system-x86_64:19925): GLib-CRITICAL **: g_source_remove_poll:
assertion '!SOURCE_DESTROYED (source)' failed
The problem is that g_source_remove_poll() does not al
The following changes since commit d147f7e815f97cb477e223586bcb80c316ae10ea:
Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging
(2017-10-03 16:27:24 +0100)
are available in the git repository at:
git://github.com/stefanha/qemu.git tags/block-pull-request
for you
From: Peter Xu
When gcontext is used with iothread, the context will be destroyed
during iothread_stop(). That's not good since sometimes we would like
to keep the resources until iothread is destroyed, but we may want to
stop the thread before that point.
Delay the destruction of gcontext to i
From: Peter Xu
So that internal iothread users can explicitly stop one iothread without
destroying it.
Since at it, fix iothread_stop() to allow it to be called multiple
times. Before this patch we may call iothread_stop() more than once on
single iothread, while that may not be correct since q
From: Peter Xu
We have object_get_objects_root() to keep user created objects, however
no place for objects that will be used internally. Create such a
container for internal objects.
CC: Andreas Färber
CC: Markus Armbruster
CC: Paolo Bonzini
Suggested-by: Daniel P. Berrange
Signed-off-by:
This patch add a MachineClass element that can be set in the machine C
code to specify a list of supported CPU types. If the supported CPU
types are specified the user enter CPU (by -cpu at runtime) is checked
against the supported types and QEMU exits if they aren't supported.
Signed-off-by: Alis
There are numorous QEMU machines that only have a single or a handful of
valid CPU options. To simplyfy the management of specificying which CPU
is/isn't valid let's create a property that can be set in the machine
init. We can then check to see if the user supplied CPU is in that list
or not.
I h
List all possible valid CPU options.
Signed-off-by: Alistair Francis
---
hw/arm/xilinx_zynq.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/arm/xilinx_zynq.c b/hw/arm/xilinx_zynq.c
index 1836a4ed45..de1e0bbce1 100644
--- a/hw/arm/xilinx_zynq.c
+++ b/hw/arm/xilinx_zynq.c
@@ -313,6
List all possible valid CPU options.
Signed-off-by: Alistair Francis
---
hw/arm/raspi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index 5941c9f751..555db0f258 100644
--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@ -158,6 +158,10 @@ static void raspi2
List all possible valid CPU options.
Although the board only ever has a Cortex-M3 we mark the Cortex-M4 as
supported because the Netduino2 Plus supports the Cortex-M4 and the
Netduino2 Plus is similar to the Netduino2.
Signed-off-by: Alistair Francis
---
RFC v2:
- Use a NULL terminated list
-
On Tue, Oct 03, 2017 at 01:05:09PM -0700, Alistair Francis wrote:
> This patch add a MachineClass element that can be set in the machine C
> code to specify a list of supported CPU types. If the supported CPU
> types are specified the user enter CPU (by -cpu at runtime) is checked
> against the sup
On Tue, Oct 3, 2017 at 1:23 PM, Eduardo Habkost wrote:
> On Tue, Oct 03, 2017 at 01:05:09PM -0700, Alistair Francis wrote:
>> This patch add a MachineClass element that can be set in the machine C
>> code to specify a list of supported CPU types. If the supported CPU
>> types are specified the use
On Tue, Oct 03, 2017 at 01:05:11PM -0700, Alistair Francis wrote:
> List all possible valid CPU options.
>
> Although the board only ever has a Cortex-M3 we mark the Cortex-M4 as
> supported because the Netduino2 Plus supports the Cortex-M4 and the
> Netduino2 Plus is similar to the Netduino2.
>
On Tue, Oct 03, 2017 at 01:26:53PM -0700, Alistair Francis wrote:
> On Tue, Oct 3, 2017 at 1:23 PM, Eduardo Habkost wrote:
> > On Tue, Oct 03, 2017 at 01:05:09PM -0700, Alistair Francis wrote:
> >> This patch add a MachineClass element that can be set in the machine C
> >> code to specify a list o
On Tue, Oct 03, 2017 at 01:05:13PM -0700, Alistair Francis wrote:
> List all possible valid CPU options.
>
> Signed-off-by: Alistair Francis
> ---
>
> hw/arm/xlnx-zcu102.c | 10 ++
> hw/arm/xlnx-zynqmp.c | 16 +---
> include/hw/arm/xlnx-zynqmp.h | 1 +
> 3 f
On Tue, Oct 03, 2017 at 01:05:18PM -0700, Alistair Francis wrote:
> List all possible valid CPU options.
>
> Signed-off-by: Alistair Francis
> ---
>
> hw/arm/raspi.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
> index 5941c9f751..555db0f258 10
Both -nodefconfig and -no-user-config options do the same thing
today, we only need one variable to keep track of them.
Suggested-by: Markus Armbruster
Acked-by: Alistair Francis
Reviewed-by: Markus Armbruster
Signed-off-by: Eduardo Habkost
---
vl.c | 5 +
1 file changed, 1 insertion(+),
Changes v1 -> v2:
* Document at "Deprecated features" section in qemu-doc.texi
(Daniel)
* Remove documentation for the option from qemu-options.hx
(Markus)
Since 2012 (commit ba6212d8 "Eliminate cpus-x86_64.conf file") we
have no default config files that would be disabled using
-nodefconfig.
Since 2012 (commit ba6212d8 "Eliminate cpus-x86_64.conf file") we
have no default config files that would be disabled using
-nodefconfig. Update documentation and document -nodefconfig as
deprecated.
Cc: Markus Armbruster
Acked-by: Alistair Francis
Signed-off-by: Eduardo Habkost
---
Changes v1
On 2017-10-02 15:34, Markus Armbruster wrote:
> Max Reitz writes:
>
>> Add a new test file (check-qobject.c) for unit tests that concern
>> QObjects as a whole.
>>
>> Its only purpose for now is to test the qobject_is_equal() function.
>>
>> Signed-off-by: Max Reitz
>> ---
>> tests/Makefile.inc
On 09/29/2017 07:10 AM, Amarnath Valluri wrote:
This change introduces a new TPM backend driver that can communicate with
swtpm(software TPM emulator) using unix domain socket interface. QEMU talks to
TPM emulator using QEMU's socket-based chardev backend device.
Swtpm uses two Unix sockets for
On Tue, Oct 03, 2017 at 06:17:30PM -0300, Eduardo Habkost wrote:
> Since 2012 (commit ba6212d8 "Eliminate cpus-x86_64.conf file") we
> have no default config files that would be disabled using
> -nodefconfig. Update documentation and document -nodefconfig as
> deprecated.
>
> Cc: Markus Armbruste
On Tue, Oct 3, 2017 at 1:39 PM, Eduardo Habkost wrote:
> On Tue, Oct 03, 2017 at 01:05:18PM -0700, Alistair Francis wrote:
>> List all possible valid CPU options.
>>
>> Signed-off-by: Alistair Francis
>> ---
>>
>> hw/arm/raspi.c | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/h
On Tue, Oct 3, 2017 at 1:33 PM, Eduardo Habkost wrote:
> On Tue, Oct 03, 2017 at 01:26:53PM -0700, Alistair Francis wrote:
>> On Tue, Oct 3, 2017 at 1:23 PM, Eduardo Habkost wrote:
>> > On Tue, Oct 03, 2017 at 01:05:09PM -0700, Alistair Francis wrote:
>> >> This patch add a MachineClass element t
On Tue, Oct 3, 2017 at 1:36 PM, Eduardo Habkost wrote:
> On Tue, Oct 03, 2017 at 01:05:13PM -0700, Alistair Francis wrote:
>> List all possible valid CPU options.
>>
>> Signed-off-by: Alistair Francis
>> ---
>>
>> hw/arm/xlnx-zcu102.c | 10 ++
>> hw/arm/xlnx-zynqmp.c | 16
Commit c3e5875afc0f ("checkpatch: check trace-events code style")
introduces a regression as reported:
https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg05820.html
Bareword found where operator expected at ./scripts/checkpatch.pl line 1350,
near "s/($hex[.:\/ ])+$hex//gr"
syntax error at
Hi everyone,
I am pleased to announce that the QEMU v2.10.1 stable release is now
available:
You can grab the tarball from our download page here:
https://www.qemu.org/download/#source
v2.10.1 is now tagged in the official qemu.git repository,
and the stable-2.10 branch has been updated accor
On 10/03/2017 05:05 PM, Alistair Francis wrote:
> List all possible valid CPU options.
>
> Although the board only ever has a Cortex-M3 we mark the Cortex-M4 as
> supported because the Netduino2 Plus supports the Cortex-M4 and the
> Netduino2 Plus is similar to the Netduino2.
>
> Signed-off-by: A
On Tue, 19 Sep 2017 14:29:33 +0200
Paolo Bonzini wrote:
> From: "Daniel P. Berrange"
>
> Currently before submitting a series, devs should run checkpatch.pl
> across each patch to be submitted. This can be automated using a
> command such as:
>
> git rebase -i master -x 'git show | ./scripts
On 10/03/2017 05:05 PM, Alistair Francis wrote:
> List all possible valid CPU options.
>
> Signed-off-by: Alistair Francis
Reviewed-by: Philippe Mathieu-Daudé
> ---
>
> hw/arm/xilinx_zynq.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/hw/arm/xilinx_zynq.c b/hw/arm/xilinx_zy
If the hypervisor needs to add purely virtual capabilties, give us a
hook through quirks to do that. Note that we determine the maximum
size for a capability based on the physical device, if we insert a
virtual capability, that can change. Therefore if maximum size is
smaller after added virt cap
The following changes since commit d147f7e815f97cb477e223586bcb80c316ae10ea:
Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging
(2017-10-03 16:27:24 +0100)
are available in the git repository at:
git://github.com/awilliam/qemu-vfio.git tags/vfio-updates-20171003.
If vfio_add_std_cap() errors then going to out prepends irrelevant
errors for capabilities we haven't attempted to add as we unwind our
recursive stack. Just return error.
Fixes: 7ef165b9a8d9 ("vfio/pci: Pass an error object to vfio_add_capabilities")
Signed-off-by: Alex Williamson
---
hw/vfio/
NVIDIA has defined a specification for creating GPUDirect "cliques",
where devices with the same clique ID support direct peer-to-peer DMA.
When running on bare-metal, tools like NVIDIA's p2pBandwidthLatencyTest
(part of cuda-samples) determine which GPUs can support peer-to-peer
based on chipset a
On 10/03/2017 06:36 PM, Alistair Francis wrote:
> On Tue, Oct 3, 2017 at 1:39 PM, Eduardo Habkost wrote:
>> On Tue, Oct 03, 2017 at 01:05:18PM -0700, Alistair Francis wrote:
>>> List all possible valid CPU options.
>>>
>>> Signed-off-by: Alistair Francis
>>> ---
>>>
>>> hw/arm/raspi.c | 6 ++
Quoting Michael Roth (2017-07-26 20:30:52)
> This series was motivated by the discussion in this thread:
>
> https://www.redhat.com/archives/libvir-list/2017-June/msg01370.html
>
> The issue this series addresses is that when libvirt unplugs a VFIO PCI
> device,
> it may attempt to bind the ho
On Tue, Oct 03, 2017 at 04:13:11PM +0200, Greg Kurz wrote:
> The offset of the root node is guaranteed to be 0.
>
> This doesn't fix anything, it's just trivial cleanup of the two
> remaining places where this was done under hw/ppc.
>
> Signed-off-by: Greg Kurz
Applied to ppc-for-2.11.
> ---
>
Taken from the upgraded hypervisor
ubuntu@aw3:/var/lib/nova/instances/2cec409e-de92-4d29-ad68-3f1d1f8be7fc$ sudo
qemu-system-aarch64 --version
QEMU emulator version 2.8.0(Debian 1:2.8+dfsg-3ubuntu2.3~cloud0)
Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers
ubuntu@aw3:/var
Today I ran some tests and installed a Newton Deployment on arm64, which
we already know works. I upgraded QEMU and Libvirt on one of the
hypervisors from the xenial-updates/ocata cloud-archive.
See attached notes.
Libvirt - 1.3.1-1ubuntu10.14 -> 2.5.0-3ubuntu5.5~cloud0
QEMU - 1:2.5+dfsg-5ubuntu
Taken from the upgraded hypervisor:
ubuntu@awrep3:/var/lib/nova/instances/2cec409e-de92-4d29-ad68-3f1d1f8be7fc$
sudo qemu-system-aarch64 --version
QEMU emulator version 2.8.0(Debian 1:2.8+dfsg-3ubuntu2.3~cloud0)
Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers
ubuntu@awre
On Tue, Oct 03, 2017 at 12:14:04PM +0200, Thomas Huth wrote:
> We don't have any 460 or 460F CPUs in QEMU, so the init functions
> are just dead code. Let's simply remove them (translate_init.c
> is already big enough without them).
>
> Signed-off-by: Thomas Huth
Applied to ppc-for-2.11, thanks.
On 10/03/2017 01:43 PM, Jeff Cody wrote:
> On Tue, Oct 03, 2017 at 11:59:28AM -0400, John Snow wrote:
>>
>>
>> On 10/03/2017 11:57 AM, Paolo Bonzini wrote:
>>> On 03/10/2017 05:15, John Snow wrote:
For drive-backup and blockdev-backup, expose the manual-cull
property, having it default
On Thu, Sep 28, 2017 at 04:08:10PM +0530, Aravinda Prasad wrote:
> Memory error such as bit flips that cannot be corrected
> by hardware are passed on to the kernel for handling.
> If the memory address in error belongs to guest then
> the guest kernel is responsible for taking suitable action.
> P
On Thu, Sep 28, 2017 at 04:08:31PM +0530, Aravinda Prasad wrote:
> Block VM migration requests until the machine check
> error handling is complete as (i) these errors are
> specific to the source hardware and is irrelevant on
> the target hardware, (ii) these errors cause data
> corruption and sho
On Thu, Sep 28, 2017 at 04:08:21PM +0530, Aravinda Prasad wrote:
> Enable the KVM capability KVM_CAP_PPC_FWNMI so that
> the KVM causes guest exit with NMI as exit reason
> when it encounters a machine check exception on the
> address belonging to a guest. Without this capability
> enabled, KVM red
Handle a 0-length block status request up front, with a uniform
return value claiming the area is not allocated.
Most callers don't pass a length of 0 to bdrv_get_block_status()
and friends; but it definitely happens with a 0-length read when
copy-on-read is enabled. While we could audit all call
Make it easier to enable copy-on-read during iotests, by
exposing a new bool option to main and open.
Signed-off-by: Eric Blake
Reviewed-by: Jeff Cody
Reviewed-by: Kevin Wolf
Reviewed-by: John Snow
Reviewed-by: Stefan Hajnoczi
---
qemu-io.c | 15 ---
1 file changed, 12 insertions
During my quest to switch block status to be byte-based, John
forced me to evaluate whether we have a situation during
copy-on-read where we could exceed BDRV_REQUEST_MAX_BYTES [1].
Sure enough, we have a number of pre-existing bugs in the
copy-on-read code. Fix those, along with adding a test.
A
Make it possible to inject errors on writes performed during a
read operation due to copy-on-read semantics.
Signed-off-by: Eric Blake
Reviewed-by: Jeff Cody
Reviewed-by: Kevin Wolf
Reviewed-by: John Snow
Reviewed-by: Stefan Hajnoczi
---
qapi/block-core.json | 5 -
block/io.c |
Add a test for qcow2 copy-on-read behavior, including exposure
for the just-fixed bugs.
The copy-on-read behavior is always to a qcow2 image, but the
test is careful to allow running with most image protocol/format
combos as the backing file being copied from (luks being the
exception, as it is ha
Improve our braindead copy-on-read implementation. Pre-patch,
we have multiple issues:
- we create a bounce buffer and perform a write for the entire
request, even if the active image already has 99% of the
clusters occupied, and really only needs to copy-on-read the
remaining 1% of the clusters
-
RFC: The error returned by a job creation command when that device
already has a job attached has become misleading; "Someone should
do something about that!"
Signed-off-by: John Snow
---
tests/qemu-iotests/056 | 227 +
tests/qemu-iotests/056.out |
Add a persistent (manually reap) property to block jobs that forces
them to linger in the block job list (visible to QMP queries) until
the user explicitly dismisses them via QMP.
The reap command itself is implemented in the next commit, and the
feature is exposed to drive-backup and blockdev-bac
For jobs that complete when a monitor isn't looking, there's no way to
tell what the job's final return code was. We need to allow jobs to
remain in the list until queried for reliable management.
V2:
- Added tests!
- Changed property name (Jeff, Paolo)
RFC:
The next version will add tests for
For jobs that have finished (either completed or canceled), allow the
user to dismiss the job's status reports via block-job-reap.
Signed-off-by: John Snow
---
block/trace-events | 1 +
blockdev.c | 14 ++
qapi/block-core.json | 21 +
3 files changed,
For drive-backup and blockdev-backup, expose the persistent
property, having it default to false. There are no universal
creation parameters, so it must be added to each job type that
it makes sense for individually.
Signed-off-by: John Snow
---
blockdev.c | 10 --
qapi/block-c
There are patches floating around to add NBD_CMD_BLOCK_STATUS,
but NBD wants to report status on byte granularity (even if the
reporting will probably be naturally aligned to sectors or even
much higher levels). I've therefore started the task of
converting our block status code to report at a byt
Not all callers care about which BDS owns the mapping for a given
range of the file. In particular, bdrv_is_allocated() cares more
about finding the largest run of allocated data from the guest
perspective, whether or not that data is consecutive from the
host perspective, and whether or not the d
In the process of converting sector-based interfaces to bytes,
I'm finding it easier to represent a byte count as a 64-bit
integer at the block layer (even if we are internally capped
by SIZE_MAX or even INT_MAX for individual transactions, it's
still nicer to not have to worry about truncation/ove
We are gradually converting to byte-based interfaces, as they are
easier to reason about than sector-based. Convert another internal
function (no semantic change); and as with its public counterpart,
rename to bdrv_co_block_status() to make the compiler enforce that
we catch all uses. For now, we
We are gradually moving away from sector-based interfaces, towards
byte-based. In the common case, allocation is unlikely to ever use
values that are not naturally sector-aligned, but it is possible
that byte-based values will let us be more precise about allocation
at the end of an unaligned file
We are gradually converting to byte-based interfaces, as they are
easier to reason about than sector-based. Continue by converting
an internal function (no semantic change), and simplifying its
caller accordingly.
Signed-off-by: Eric Blake
Reviewed-by: Fam Zheng
Reviewed-by: John Snow
---
v2-
We are gradually converting to byte-based interfaces, as they are
easier to reason about than sector-based. Convert another internal
function (no semantic change), and rename it to is_zero() in the
process.
Signed-off-by: Eric Blake
Reviewed-by: Fam Zheng
Reviewed-by: John Snow
---
v3-v5: no
Not all callers care about which BDS owns the mapping for a given
range of the file. This patch merely simplifies the callers by
consolidating the logic in the common call point, while guaranteeing
a non-NULL file to all the driver callbacks, for no semantic change.
The only caller that does not c
As long as we are querying the status for a chunk smaller than
the known image size, we are guaranteed that a successful return
will have set pnum to a non-zero size (pnum is zero only for
queries beyond the end of the file). Use that to slightly
simplify the calculation of the current chunk size
Continue on the quest to make more things byte-based instead of
sector-based.
Signed-off-by: Eric Blake
Reviewed-by: John Snow
---
v4-v5: no change
v3: new patch
---
qemu-img.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/qemu-img.c b/qemu-i
We are gradually moving away from sector-based interfaces, towards
byte-based. In the common case, allocation is unlikely to ever use
values that are not naturally sector-aligned, but it is possible
that byte-based values will let us be more precise about allocation
at the end of an unaligned file
101 - 200 of 246 matches
Mail list logo
