On Fri, May 31, 2019 at 05:43:37PM +0100, Dr. David Alan Gilbert wrote:
> * Wei Yang (richardw.y...@linux.intel.com) wrote:
> > During migration, we would sync bitmap from ram_list.dirty_memory to
> > RAMBlock.bmap in cpu_physical_memory_sync_dirty_bitmap().
> >
> > Since we set RAMBlock.bmap and
Hello!
I was compiling latest qemu git, and was surprized to find qemu-system-x86_64
(compiled for 32-bit x86 machine) can't boot any 64-bit kernel anymore.
32-bit kernels and kvm were fine.
So, I run git bisect
./configure --target-list=x86_64-softmmu --disable-werror
make -j 5
On Fri, May 31, 2019 at 03:01:29PM +0200, Juan Quintela wrote:
> Peter Xu wrote:
> > Similar to 9460dee4b2 ("memory: do not touch code dirty bitmap unless
> > TCG is enabled", 2015-06-05) but for the migration bitmap - we can
> > skip the MIGRATION bitmap update if migration not enabled.
> >
> >
On 5/31/19 12:31 PM, Vladimir Sementsov-Ogievskiy wrote:
> qcow2_reopen_bitmaps_ro wants to store bitmaps and then mark them all
> readonly. But the latter don't work, as
> qcow2_store_persistent_dirty_bitmaps removes bitmaps after storing.
> It's OK for inactivation but bad idea for reopen-ro.
On 5/31/19 12:31 PM, Vladimir Sementsov-Ogievskiy wrote:
> The function is unused, drop it.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> block/qcow2.h| 2 --
> block/qcow2-bitmap.c | 15 +--
> 2 files changed, 1 insertion(+), 16 deletions(-)
>
> diff --git
On 5/31/19 12:31 PM, Vladimir Sementsov-Ogievskiy wrote:
> Two testcases with persistent bitmaps are not added here, as there are
> bugs to be fixed soon.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> tests/qemu-iotests/255 | 84 ++
>
On 5/31/19 12:31 PM, Vladimir Sementsov-Ogievskiy wrote:
> Support several names to wait for, which useful, when we don't sure
> which event will we get. For example when mirror fails we get
> BLOCK_JOB_COMPLETE otherwise we get BLOCK_JOB_READY (and only then,
> after completing block-job we
I've thought some more about this issue, and long term I think there are a
couple different useful configurations:
- For end users, having default firmware that loaded the OS from a block
device would be easiest
- Current invocation: impossible
- Proposed: empty command line
On 5/31/19 3:24 PM, Eduardo Habkost wrote:
> Long story short: I would really like to drop support for Python
> 2 in QEMU 4.1.
>
> What exactly prevents us from doing this? Does our deprecation
> policy really apply to build dependencies?
>
Normally I'd say it's only nice to also follow the
On Fri, May 31, 2019 at 05:05:26PM -0400, Michael S. Tsirkin wrote:
> On Fri, May 31, 2019 at 02:29:33PM -0600, Alex Williamson wrote:
> > I don't know what this frontend/backend rework would
> > look like for vfio-pci, but it seems non-trivial for this one use case
> > and I don't see that it
On Thu, May 30, 2019 at 04:56:45PM +0200, Jens Freimann wrote:
> On Tue, May 28, 2019 at 11:04:15AM -0400, Michael S. Tsirkin wrote:
> > On Tue, May 21, 2019 at 10:45:05AM +0100, Dr. David Alan Gilbert wrote:
> > > * Jens Freimann (jfreim...@redhat.com) wrote:
[...]
> > > > +}
> > > > +if
On Fri, May 31, 2019 at 04:43:44PM -0400, Michael S. Tsirkin wrote:
> On Fri, May 31, 2019 at 07:45:13PM +0100, Dr. David Alan Gilbert wrote:
> > * Michael S. Tsirkin (m...@redhat.com) wrote:
> > > On Fri, May 31, 2019 at 02:01:54PM -0300, Eduardo Habkost wrote:
> > > > > Yes. It's just lots of
On Fri, May 31, 2019 at 02:29:33PM -0600, Alex Williamson wrote:
> I don't know what this frontend/backend rework would
> look like for vfio-pci, but it seems non-trivial for this one use case
> and I don't see that it adds any value outside of this use case,
> perhaps quite the opposite, it's an
On Fri, May 31, 2019 at 07:45:13PM +0100, Dr. David Alan Gilbert wrote:
> * Michael S. Tsirkin (m...@redhat.com) wrote:
> > On Fri, May 31, 2019 at 02:01:54PM -0300, Eduardo Habkost wrote:
> > > > Yes. It's just lots of extremely low level interfaces
> > > > and all rather pointless.
> > > >
> >
On Fri, 31 May 2019 19:45:13 +0100
"Dr. David Alan Gilbert" wrote:
> * Michael S. Tsirkin (m...@redhat.com) wrote:
> > On Fri, May 31, 2019 at 02:01:54PM -0300, Eduardo Habkost wrote:
> > > > Yes. It's just lots of extremely low level interfaces
> > > > and all rather pointless.
> > > >
> > >
On Wed, May 29, 2019 at 06:07:47PM +0200, Laurent Vivier wrote:
> On pseries, core-ids are strongly binded to a node-id by the command
> line option. If an user tries to add a CPU to the wrong node, he has
> an error but it is not really helpful:
>
> qemu-system-ppc64 ... -smp
On 5/31/19 3:40 PM, Eduardo Habkost wrote:
> On Tue, May 28, 2019 at 04:42:19PM -0400, John Snow wrote:
>> It's not obvious that something named __init__.py actually houses
>> important code that isn't relevant to python packaging glue. Move the
>> QEMUMachine and related error classes out into
On Tue, May 28, 2019 at 04:42:19PM -0400, John Snow wrote:
> It's not obvious that something named __init__.py actually houses
> important code that isn't relevant to python packaging glue. Move the
> QEMUMachine and related error classes out into their own module.
>
> Adjust users to the new
On Tue, May 28, 2019 at 10:48:09AM +0800, Yongji Xie wrote:
> On Tue, 28 May 2019 at 02:54, Michael S. Tsirkin wrote:
> >
> > On Mon, May 27, 2019 at 12:44:46PM +0200, Greg Kurz wrote:
> > > On Fri, 24 May 2019 19:56:06 +0800
> > > Yongji Xie wrote:
> > >
> > > > On Fri, 24 May 2019 at 18:20,
Long story short: I would really like to drop support for Python
2 in QEMU 4.1.
What exactly prevents us from doing this? Does our deprecation
policy really apply to build dependencies?
--
Eduardo
* Markus Armbruster (arm...@redhat.com) wrote:
> David, got anything queued for the monitor? If yes, can you stick this
> in? If not, I can handle it.
I've not got anything else, so please take it;
am I right in thinking this supercedes
'monitor: Fix fdset_id & fd types for corresponding QMP
On 5/31/19 3:01 PM, Vladimir Sementsov-Ogievskiy wrote:
> 31.05.2019 21:16, John Snow wrote:
>>
>>
>> On 5/31/19 1:30 PM, Vladimir Sementsov-Ogievskiy wrote:
>>> Hi!
>>>
>>> 20.02.2019 21:01, John Snow wrote:
When bitmaps are persistent, they may incur a disk read or write when
31.05.2019 21:16, John Snow wrote:
>
>
> On 5/31/19 1:30 PM, Vladimir Sementsov-Ogievskiy wrote:
>> Hi!
>>
>> 20.02.2019 21:01, John Snow wrote:
>>> When bitmaps are persistent, they may incur a disk read or write when
>>> bitmaps
>>> are added or removed. For configurations like
* Michael S. Tsirkin (m...@redhat.com) wrote:
> On Fri, May 31, 2019 at 02:01:54PM -0300, Eduardo Habkost wrote:
> > > Yes. It's just lots of extremely low level interfaces
> > > and all rather pointless.
> > >
> > > And down the road extensions like surprise removal support will make it
> > >
On Fri, May 31, 2019 at 02:04:49PM -0400, Michael S. Tsirkin wrote:
> On Fri, May 31, 2019 at 02:01:54PM -0300, Eduardo Habkost wrote:
> > > Yes. It's just lots of extremely low level interfaces
> > > and all rather pointless.
> > >
> > > And down the road extensions like surprise removal support
On Fri, May 31, 2019 at 02:01:54PM -0300, Eduardo Habkost wrote:
> > Yes. It's just lots of extremely low level interfaces
> > and all rather pointless.
> >
> > And down the road extensions like surprise removal support will make it
> > all cleaner and more transparent. Floating things up to
On 5/31/19 12:58 PM, David Hildenbrand wrote:
> Are you aware of a HFP library?
No. It might be possible to shoehorn into softfloat, because I *think* to can
treat HFP as BFP with weird rounding. At least that's what I remember from my
old college daze on the esa/390.
Otherwise we could maybe
On 5/31/19 10:55 AM, Eric Blake wrote:
> On 5/30/19 11:26 AM, John Snow wrote:
>>
>>
>> On 5/30/19 10:39 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> Let's add a possibility to query dirty-bitmaps not only on root nodes.
>>> It is useful when dealing both with snapshots and incremental backups.
On 31.05.19 20:06, Richard Henderson wrote:
> On 5/31/19 12:58 PM, David Hildenbrand wrote:
>> Are you aware of a HFP library?
>
> No. It might be possible to shoehorn into softfloat, because I *think* to can
> treat HFP as BFP with weird rounding. At least that's what I remember from my
> old
On 5/31/19 1:30 PM, Vladimir Sementsov-Ogievskiy wrote:
> Hi!
>
> 20.02.2019 21:01, John Snow wrote:
>> When bitmaps are persistent, they may incur a disk read or write when bitmaps
>> are added or removed. For configurations like virtio-dataplane, failing to
>> acquire this lock will abort
On 31.05.19 19:48, Richard Henderson wrote:
> On 5/31/19 5:44 AM, David Hildenbrand wrote:
>> +static DisasJumpType op_vfpso(DisasContext *s, DisasOps *o)
>> +{
>> +const uint8_t fpf = get_field(s->fields, m3);
>> +const uint8_t m4 = get_field(s->fields, m4);
>> +const uint8_t m5 =
On 31.05.19 19:57, Richard Henderson wrote:
> On 5/31/19 5:44 AM, David Hildenbrand wrote:
>> We don't care about the other two missing base features:
>> - S390_FEAT_DFP_PACKED_CONVERSION
>> - S390_FEAT_GROUP_GEN13_PTFF
>>
>> Signed-off-by: David Hildenbrand
>> ---
>> hw/s390x/s390-virtio-ccw.c
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> We don't care about the other two missing base features:
> - S390_FEAT_DFP_PACKED_CONVERSION
> - S390_FEAT_GROUP_GEN13_PTFF
>
> Signed-off-by: David Hildenbrand
> ---
> hw/s390x/s390-virtio-ccw.c | 2 ++
> target/s390x/cpu_models.c | 4 ++--
>
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> Once we unlock S390_FEAT_VECTOR for TCG, we want linux-user to be
> able to make use of it.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/cpu.c | 3 +++
> 1 file changed, 3 insertions(+)
Reviewed-by: Richard Henderson
r~
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> Let's add it to the max model, so we can enable it.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/gen-features.c | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Richard Henderson
r~
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> We can reuse float64_dcmask().
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/helper.h | 2 ++
> target/s390x/insn-data.def | 2 ++
> target/s390x/translate_vx.inc.c | 21 ++
>
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> Similar to VECTOR FP ADD.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/helper.h | 2 ++
> target/s390x/insn-data.def | 2 ++
> target/s390x/translate_vx.inc.c | 3 +++
> target/s390x/vec_fpu_helper.c | 17
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> Simulate XxC=0 and ERM=0 (current mode), so we can use the existing
> helper function.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/helper.h | 2 ++
> target/s390x/insn-data.def | 2 ++
>
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> +static DisasJumpType op_vfpso(DisasContext *s, DisasOps *o)
> +{
> +const uint8_t fpf = get_field(s->fields, m3);
> +const uint8_t m4 = get_field(s->fields, m4);
> +const uint8_t m5 = get_field(s->fields, m5);
> +const bool se =
On 31.05.19 19:42, Richard Henderson wrote:
> On 5/31/19 5:44 AM, David Hildenbrand wrote:
>> +typedef uint64_t (*vop64_4_fn)(uint64_t a, uint64_t b, uint64_t c,
>> + float_status *s);
>> +static void vop64_4(S390Vector *v1, const S390Vector *v2, const S390Vector
>>
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> +typedef uint64_t (*vop64_4_fn)(uint64_t a, uint64_t b, uint64_t c,
> + float_status *s);
> +static void vop64_4(S390Vector *v1, const S390Vector *v2, const S390Vector
> *v3,
> +const S390Vector *v4,
On 31.05.19 12:44, David Hildenbrand wrote:
> We can reuse float64_dcmask().
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/helper.h | 2 ++
> target/s390x/insn-data.def | 2 ++
> target/s390x/translate_vx.inc.c | 21 ++
>
On 31.05.19 19:36, Richard Henderson wrote:
> On 5/31/19 12:35 PM, David Hildenbrand wrote:
>> On 31.05.19 19:33, Richard Henderson wrote:
>>> On 5/31/19 5:44 AM, David Hildenbrand wrote:
+for (i = 0; i < 2; i++) {
+/* load from even element */
+const float32 a =
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> We can reuse some of the infrastructure introduced for
> VECTOR FP CONVERT FROM FIXED 64-BIT and friends.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/helper.h | 2 ++
> target/s390x/insn-data.def | 2 ++
>
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> Very similar to VECTOR FP DIVIDE.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/helper.h | 2 ++
> target/s390x/insn-data.def | 2 ++
> target/s390x/translate_vx.inc.c | 3 +++
> target/s390x/vec_fpu_helper.c | 17
On 5/31/19 12:35 PM, David Hildenbrand wrote:
> On 31.05.19 19:33, Richard Henderson wrote:
>> On 5/31/19 5:44 AM, David Hildenbrand wrote:
>>> +for (i = 0; i < 2; i++) {
>>> +/* load from even element */
>>> +const float32 a = make_float32(s390_vec_read_element32(v2, i * 2));
On 31.05.19 19:33, Richard Henderson wrote:
> On 5/31/19 5:44 AM, David Hildenbrand wrote:
>> +for (i = 0; i < 2; i++) {
>> +/* load from even element */
>> +const float32 a = make_float32(s390_vec_read_element32(v2, i * 2));
>
> I suppose.
>
> You could also reuse vop64_2
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> +for (i = 0; i < 2; i++) {
> +/* load from even element */
> +const float32 a = make_float32(s390_vec_read_element32(v2, i * 2));
I suppose.
You could also reuse vop64_2 with
static uint64_t vfll(uint64_t a, float_status *s)
{
Interesting; I'd seen something similar - in rh
https://bugzilla.redhat.com/show_bug.cgi?id=1538078
and as well as the bogus date we'd had lots of log messages of the form:
CE: lapic increasing min_delta_ns to nsec
we were reckoning the clock jumped a bit during the migrate, and then
Hi!
20.02.2019 21:01, John Snow wrote:
> When bitmaps are persistent, they may incur a disk read or write when bitmaps
> are added or removed. For configurations like virtio-dataplane, failing to
> acquire this lock will abort QEMU when disk IO occurs.
>
> We used to acquire aio_context as part
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> We can reuse most of the infrastructure introduced for
> VECTOR FP CONVERT FROM FIXED 64-BIT and friends.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/helper.h | 2 ++
> target/s390x/insn-data.def | 2 ++
>
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/helper.h | 2 ++
> target/s390x/insn-data.def | 2 ++
> target/s390x/translate_vx.inc.c | 3 +++
> target/s390x/vec_fpu_helper.c | 23 +++
> 4 files
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> We can reuse most of the infrastructure added for VECTOR FP ADD.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/helper.h | 2 ++
> target/s390x/insn-data.def | 2 ++
> target/s390x/translate_vx.inc.c | 3 +++
>
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/helper.h | 2 ++
> target/s390x/insn-data.def | 2 ++
> target/s390x/translate_vx.inc.c | 3 +++
> target/s390x/vec_fpu_helper.c | 23 +++
> 4 files
On 31.05.19 18:53, Richard Henderson wrote:
> On 5/31/19 5:44 AM, David Hildenbrand wrote:
>> +static int vfc64(S390Vector *v1, const S390Vector *v2, const S390Vector *v3,
>> + CPUS390XState *env, bool s, bool test_equal, bool
>> test_high,
>> + uintptr_t retaddr)
On 31.05.19 19:15, Richard Henderson wrote:
> On 5/31/19 12:10 PM, Richard Henderson wrote:
>> On 5/31/19 5:44 AM, David Hildenbrand wrote:
>>> +static DisasJumpType op_vcdg(DisasContext *s, DisasOps *o)
>>> +{
>>> +const uint8_t fpf = get_field(s->fields, m3);
>>> +const uint8_t m4 =
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/helper.h | 2 ++
> target/s390x/insn-data.def | 2 ++
> target/s390x/translate_vx.inc.c | 3 +++
> target/s390x/vec_fpu_helper.c | 23 +++
> 4 files
On 5/31/19 12:10 PM, Richard Henderson wrote:
> On 5/31/19 5:44 AM, David Hildenbrand wrote:
>> +static DisasJumpType op_vcdg(DisasContext *s, DisasOps *o)
>> +{
>> +const uint8_t fpf = get_field(s->fields, m3);
>> +const uint8_t m4 = get_field(s->fields, m4);
>> +const uint8_t erm =
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> +static DisasJumpType op_vcdg(DisasContext *s, DisasOps *o)
> +{
> +const uint8_t fpf = get_field(s->fields, m3);
> +const uint8_t m4 = get_field(s->fields, m4);
> +const uint8_t erm = get_field(s->fields, m5);
> +const bool se =
On Fri, 31 May 2019 at 17:40, Philippe Mathieu-Daudé wrote:
> I'll see what happened to Samuel series "Support disabling TCG on ARM"
> and see if it can be salvaged:
> https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg02451.html
That would certainly be useful.
> I suppose in this thread:
On Fri, 31 May 2019 at 17:54, Miroslav Rezanina wrote:
> What about CONFIG_ARM_VIRT - can we use it to introduce dependency on
> CONFIG_SEMIHOSTING or is there valid scenario of qemu build with
> CONFIG_ARM_VIRT
> enabled and CONFIG_SEMIHOSTING disabled?
Semihosting is a feature that works on
Patchew URL: https://patchew.org/QEMU/20190531154735.20809-1-phi...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [RFC PATCH 0/2] target: Build with CONFIG_SEMIHOSTING
disabled
Type: series
Message-id:
On 31.05.19 18:26, Max Reitz wrote:
> On 16.04.19 12:02, Vladimir Sementsov-Ogievskiy wrote:
>> 10.04.2019 23:20, Max Reitz wrote:
>>> What bs->file and bs->backing mean depends on the node. For filter
>>> nodes, both signify a node that will eventually receive all R/W
>>> accesses. For format
On Thu, May 30, 2019 at 07:06:29PM -0400, Michael S. Tsirkin wrote:
> On Thu, May 30, 2019 at 03:22:10PM -0300, Eduardo Habkost wrote:
> > On Thu, May 30, 2019 at 02:09:42PM -0400, Michael S. Tsirkin wrote:
> > > On Thu, May 30, 2019 at 07:00:23PM +0100, Dr. David Alan Gilbert wrote:
> > > > *
I just noticed that it was a libvirt bug that caused the error.
-drive
file=/opt/ovmf/aarch64/AAVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \
-drive
file=/var/lib/libvirt/qemu/nvram/debiantesting_VARS.fd,if=pflash,format=raw,unit=1
\
debiantesting_VARS.fd was never removed or replaced
- Original Message -
> From: "Philippe Mathieu-Daudé"
> To: "Peter Maydell"
> Cc: "QEMU Developers" , "Paolo Bonzini"
> , "Miroslav Rezanina"
> , "Richard Henderson" ,
> "Aleksandar Rikalo"
> , "qemu-arm" , "Aleksandar
> Markovic" , "Aurelien
> Jarno" , "Alex Bennée" ,
> "Samuel
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> +static int vfc64(S390Vector *v1, const S390Vector *v2, const S390Vector *v3,
> + CPUS390XState *env, bool s, bool test_equal, bool test_high,
> + uintptr_t retaddr)
> +{
> +uint8_t vxc, vec_exc = 0;
> +
The AccelType type was converted to AccelClass QOM
object on b14a0b7469f, and the original data type had
a field to store the option name which in turn was
used to search an accelerator. The lookup method
(accel_find) changed too, making the option field
unnecessary but it became
- Original Message -
> From: "Alex Bennée"
> To: "Miroslav Rezanina"
> Cc: qemu-devel@nongnu.org, "Peter Maydell" , "Riku
> Voipio" ,
> qemu-...@nongnu.org, "Laurent Vivier"
> Sent: Friday, May 31, 2019 4:28:02 PM
> Subject: Re: [Qemu-devel] [RFC PATCH 06/11] target/arm: use the
On 5/31/19 6:21 PM, Peter Maydell wrote:
> On Fri, 31 May 2019 at 16:47, Philippe Mathieu-Daudé
> wrote:
>>
>> Amusingly Miroslav and myself hit this issue at the same time.
>>
>> Currently there is no way to pass a CONFIG_X to sources in target/,
>> except via a Makefile rule (and filling with
The AccelClass::opt_name is not used. Unless there is a reason
for keeping hat attribute, this patch remove it.
Git: https://github.com/wainersm/qemu
Branch: accel_del_opt_name
Travis: https://travis-ci.org/wainersm/qemu/builds/539721285
(Failed test case is not related with this change as well
- Original Message -
> From: "Peter Maydell"
> To: "Alex Bennée"
> Cc: "Miroslav Rezanina" , "QEMU Developers"
> , "Riku Voipio"
> , "qemu-arm" , "Laurent Vivier"
>
> Sent: Friday, May 31, 2019 4:38:04 PM
> Subject: Re: [Qemu-devel] [RFC PATCH 06/11] target/arm: use the common
>
* Wei Yang (richardw.y...@linux.intel.com) wrote:
> During migration, we would sync bitmap from ram_list.dirty_memory to
> RAMBlock.bmap in cpu_physical_memory_sync_dirty_bitmap().
>
> Since we set RAMBlock.bmap and ram_list.dirty_memory both to all 1, this
> means at the first round this sync is
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> As far as I can see, there is only a tiny difference.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/helper.h | 2 ++
> target/s390x/insn-data.def | 4
> target/s390x/translate_vx.inc.c | 21 +
>
Two testcases with persistent bitmaps are not added here, as there are
bugs to be fixed soon.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
tests/qemu-iotests/255 | 84 ++
tests/qemu-iotests/255.out | 17
tests/qemu-iotests/group | 1 +
3
The function is unused, drop it.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block/qcow2.h| 2 --
block/qcow2-bitmap.c | 15 +--
2 files changed, 1 insertion(+), 16 deletions(-)
diff --git a/block/qcow2.h b/block/qcow2.h
index 567375e56c..88a2030f54 100644
---
qcow2_reopen_bitmaps_ro wants to store bitmaps and then mark them all
readonly. But the latter don't work, as
qcow2_store_persistent_dirty_bitmaps removes bitmaps after storing.
It's OK for inactivation but bad idea for reopen-ro. And this leads to
the following bug:
Assume we have persistent
Firstly, no reason to optimize failure path. Then, function name is
ambiguous: it checks for readonly and similar things, but someone may
think that it will ignore normal bitmaps which was just unchanged, and
this is in bad relation with the fact that we should drop IN_USE flag
for unchanged
- Correct check for write access to file child, and in correct place
(only if we want to write).
- Support reopen rw -> rw (which will be used in furhter patches),
for example, !bdrv_dirty_bitmap_readonly() is not a corruption if
bitmap is marked IN_USE in the image.
- Consider unexpected
Currently reopening bitmaps to RW can't work, as qcow2 needs write
access to file child, to mark bitmaps in-image with IN_USE flag.
The possibility to write-access file child during reopen-RW was
implemented several patches ago with help of
.bdrv_need_rw_file_child_during_reopen_rw handler. Let's
Support several names to wait for, which useful, when we don't sure
which event will we get. For example when mirror fails we get
BLOCK_JOB_COMPLETE otherwise we get BLOCK_JOB_READY (and only then,
after completing block-job we get BLOCK_JOB_COMPLETE).
Also, add filtered version for convenient
On reopen to rw parent may need rw access to child in .prepare, for
example qcow2 needs to write IN_USE flags into stored bitmaps
(currently it is done in a hacky way after commit and don't work).
So, let's introduce such logic.
The drawback is that in worst case bdrv_reopen_set_read_only may
Since we have used .bdrv_need_rw_file_child_during_reopen_rw handler,
and have write access to file child in reopen-prepare, and we prepared
qcow2_reopen_bitmaps_rw to be called from reopening rw -> rw, we now
can simple move qcow2_reopen_bitmaps_rw() call to
qcow2_reopen_prepare() and handle
Hi all!
Bitmaps reopening is buggy, we may easily produce broken incremental
backup if we do temporary snapshot. Let's fix it!
v2:
01: new
02-03: test: splat into two patches, some wording
improvements and event_wait improved
04: add John's r-b
05: new
06-09: fixes: changed, splat, use
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> +void HELPER(gvec_vfa64)(void *v1, const void *v2, const void *v3,
> +CPUS390XState *env, uint32_t desc)
> +{
> +vop64_3(v1, v2, v3, env, false, vfa64, GETPC());
> +}
Given that make_float64 is banished, I guess you can
Jerry writes:
> [jerry@jerry-n1 aarch64]$ du -b *
> 67108864AAVMF_CODE.fd
> 67108864AAVMF_VARS.fd
> 67108864QEMU_EFI.fd
> 67108864QEMU_VARS.fd
>
> 2097152 QEMU_EFI.fd.orig
> 786432 QEMU_VARS.fd.orig
>
>
> Both files have been padded to 64MB. (if padding means
On 31.05.19 17:54, Richard Henderson wrote:
> On 5/31/19 5:44 AM, David Hildenbrand wrote:
>> +static uint64_t vfa64(uint64_t a, uint64_t b, float_status *s)
>> +{
>> +return float64_val(float64_add(make_float64(a), make_float64(b), s));
>> +}
>
>
> You don't need either make_float64 or
On 16.04.19 12:02, Vladimir Sementsov-Ogievskiy wrote:
> 10.04.2019 23:20, Max Reitz wrote:
>> What bs->file and bs->backing mean depends on the node. For filter
>> nodes, both signify a node that will eventually receive all R/W
>> accesses. For format nodes, bs->file contains metadata and data,
On Fri, 31 May 2019 at 16:47, Philippe Mathieu-Daudé wrote:
>
> Amusingly Miroslav and myself hit this issue at the same time.
>
> Currently there is no way to pass a CONFIG_X to sources in target/,
> except via a Makefile rule (and filling with stubs).
>
> Paolo says this is on purpose, CONFIG_X
Hi Alan,
Dmesg shows nothing special:
[29891577.708544] IPv6 addrconf: prefix with wrong length 48
[29891580.650637] IPv6 addrconf: prefix with wrong length 48
[29891582.013656] IPv6 addrconf: prefix with wrong length 48
[29891583.753246] IPv6 addrconf: prefix with wrong length 48
31.05.2019 18:49, Kevin Wolf wrote:
> Am 31.05.2019 um 16:10 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> 31.05.2019 13:51, Stefan Hajnoczi wrote:
>>> On Tue, May 28, 2019 at 11:45:44AM +0300, Vladimir Sementsov-Ogievskiy
>>> wrote:
We have similar padding code in bdrv_co_pwritev,
If a distribution wants to build QEMU without semihosting support,
it currently gets this build failure:
$ ./configure --target-list=mips64el-softmmu --without-default-devices
$ sed -i s/CONFIG_SEMIHOSTING=y/CONFIG_SEMIHOSTING=n/
default-configs/mips-softmmu-common.mak
$ make
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> +static uint64_t vfa64(uint64_t a, uint64_t b, float_status *s)
> +{
> +return float64_val(float64_add(make_float64(a), make_float64(b), s));
> +}
You don't need either make_float64 or float64_val.
I've been intending to strip them out entirely;
Hi Dion,
Since you've got a crash dump, can you check the dmesg in the guest to see if
there's any messages?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1831225
Title:
guest migration 100%
I'm quite sure that debian has done the padding procedure
https://salsa.debian.org/qemu-team/edk2/blob/debian/debian/rules#L82
** Changed in: qemu
Status: Invalid => New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Am 31.05.2019 um 16:10 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 31.05.2019 13:51, Stefan Hajnoczi wrote:
> > On Tue, May 28, 2019 at 11:45:44AM +0300, Vladimir Sementsov-Ogievskiy
> > wrote:
> >> We have similar padding code in bdrv_co_pwritev,
> >> bdrv_co_do_pwrite_zeroes and
Amusingly Miroslav and myself hit this issue at the same time.
Currently there is no way to pass a CONFIG_X to sources in target/,
except via a Makefile rule (and filling with stubs).
Paolo says this is on purpose, CONFIG_X selectors are meant for
devices and we try to avoid having
If a distribution wants to build QEMU without semihosting support,
it currently gets this build failure:
$ ./configure --target-list=aarch64-softmmu --without-default-devices
$ sed -i s/CONFIG_SEMIHOSTING=y/CONFIG_SEMIHOSTING=n/
default-configs/arm-softmmu.mak
$ make subdir-aarch64-softmmu
On Fri, 31 May 2019 15:28:07 +
Thanos Makatos wrote:
> > > When configuring device pass-through via VFIO to a VM, I noticed that
> > > QEMU tries to register (DMA_MAP) all memory regions of a guest (not
> > > only RAM). That includes firmware regions like "pc.rom".
> Would a
On 5/30/19 2:07 PM, Michael Rolnik wrote:
> +/* decode first instruction */
> +ctx.inst[0].cpc = pc_start;
> +decode_opc(, [0]);
> +do {
> +/* set curr/next PCs */
> +cpc = ctx.inst[0].cpc;
> +npc = ctx.inst[0].npc;
> +
> +/* decode next instruction
1 - 100 of 248 matches
Mail list logo
