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:
> +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 = extrac
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 ++
> target/s390x/translate_vx.inc.c
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:
> 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 ++
> target/s390x/vec_fpu_helper.
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:
> 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:
> 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 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 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 = get_
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 c
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 QEM
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 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 s
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 libvi
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
* 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
> > > all
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 virtio-dataplan
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
bitmap
* 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
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
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, Gre
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 impo
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 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 1,maxcpus=64,cores
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 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, 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 o
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 ext
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 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 adds
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
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 (i.e
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 get
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 ++
> tests/qe
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 a/b
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 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.
> >
> > R
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
x86_64-softmm
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
On Tue, May 21, 2019 at 6:43 AM Pankaj Gupta wrote:
>
> This patch sets dax device 'DAXDEV_SYNC' flag if all the target
> devices of device mapper support synchrononous DAX. If device
> mapper consists of both synchronous and asynchronous dax devices,
> we don't set 'DAXDEV_SYNC' flag.
>
> Sig
201 - 241 of 241 matches
Mail list logo
