On 01.10.19 06:54, Thomas Huth wrote:
> On 27/09/2019 11.58, David Hildenbrand wrote:
>> Let's use consitent names for the region/section/page table entries and
>> for the macros to extract relevant parts from virtual address. Make them
>> match the definitions in the PoP - e.g., how the relevant b
On 26/09/19 20:35, Alex Bennée wrote:
> From: John Snow
>
> Fedora23 is but a distant twinkle. The sanitizer works again, and even
> if not, we have --enable-sanitizers now.
>
> Signed-off-by: John Snow
> Message-Id: <20190912014442.5757-1-js...@redhat.com>
> Signed-off-by: Alex Bennée
>
> di
On 01/10/2019 08:47, David Gibson wrote:
> On Tue, Oct 01, 2019 at 07:43:51AM +0200, Cédric Le Goater wrote:
>> On 01/10/2019 04:31, David Gibson wrote:
>>> On Mon, Sep 30, 2019 at 12:13:14PM +0200, Cédric Le Goater wrote:
On 30/09/2019 08:14, David Gibson wrote:
> On Mon, Sep 30, 2019 at
On Fri, Jul 19, 2019 at 07:06:51PM +0100, Dr. David Alan Gilbert wrote:
>* Paolo Bonzini (pbonz...@redhat.com) wrote:
>> On 19/07/19 19:54, Dr. David Alan Gilbert wrote:
>> >> -if ((uintptr_t)host_endaddr & (rb->page_size - 1)) {
>> >> -error_report("ram_block_discard_range: Una
Eduardo Habkost writes:
> On Mon, Sep 30, 2019 at 12:22:22PM +0200, Sergio Lopez wrote:
>>
>> Alex Bennée writes:
>>
>> > Sergio Lopez writes:
>> >
>> >> Hi,
>> >>
>> >> Commit 137b5cb6ab565cb3781d5337591e155932b4230e (hmp: change
>> >> hmp_info_cpus to use query-cpus-fast) updated the "info
On 27.09.19 21:39, Richard Henderson wrote:
> Based-on: <20190925125236.4043-1-da...@redhat.com> \
> ("s390x/mmu: DAT translation rewrite")
>
> Based-on: <20190926101627.23376-1-da...@redhat.com> \
> ("s390x/mmu: Implement more facilities") \
> With the suggested follow-up for patch 2 re ile
On 27/09/2019 11.58, David Hildenbrand wrote:
> A non-recursive implementation allows to make better use of the
> branch predictor, avoids function calls, and makes the implementation of
> new features only for a subset of region table levels easier.
>
> We can now directly compare our implementat
>> break;
>> case ASCE_TYPE_SEGMENT:
>> if (VADDR_REGION1_TX(vaddr) || VADDR_REGION2_TX(vaddr) ||
>> @@ -253,11 +164,112 @@ static int mmu_translate_asce(CPUS390XState *env,
>> target_ulong vaddr,
>> if (VADDR_SEGMENT_TL(vaddr) > asce_tl) {
>> return
Kevin, can you give any hint on using blockdev through the command line?
Pavel Dovgalyuk
> -Original Message-
> From: Pavel Dovgalyuk [mailto:dovga...@ispras.ru]
> Sent: Wednesday, September 25, 2019 12:03 PM
> To: 'Kevin Wolf'
> Cc: qemu-devel@nongnu.org; peter.mayd...@linaro.org;
> cr
On 01/10/2019 10.17, David Hildenbrand wrote:
>
>>> break;
>>> case ASCE_TYPE_SEGMENT:
>>> if (VADDR_REGION1_TX(vaddr) || VADDR_REGION2_TX(vaddr) ||
>>> @@ -253,11 +164,112 @@ static int mmu_translate_asce(CPUS390XState *env,
>>> target_ulong vaddr,
>>> if (VADDR_S
* Felipe Franciosi (fel...@nutanix.com) wrote:
>
>
> > On Sep 30, 2019, at 6:59 PM, Dr. David Alan Gilbert
> > wrote:
> >
> > * Felipe Franciosi (fel...@nutanix.com) wrote:
> >>
> >>
> >>> On Sep 30, 2019, at 6:11 PM, Dr. David Alan Gilbert
> >>> wrote:
> >>>
> >>> * Felipe Franciosi (fel
On 01.10.19 10:23, Thomas Huth wrote:
> On 01/10/2019 10.17, David Hildenbrand wrote:
>>
break;
case ASCE_TYPE_SEGMENT:
if (VADDR_REGION1_TX(vaddr) || VADDR_REGION2_TX(vaddr) ||
@@ -253,11 +164,112 @@ static int mmu_translate_asce(CPUS390XState *env,
On Tue, Oct 01, 2019 at 09:41:27AM +0200, Cédric Le Goater wrote:
> On 01/10/2019 08:47, David Gibson wrote:
> > On Tue, Oct 01, 2019 at 07:43:51AM +0200, Cédric Le Goater wrote:
> >> On 01/10/2019 04:31, David Gibson wrote:
> >>> On Mon, Sep 30, 2019 at 12:13:14PM +0200, Cédric Le Goater wrote:
>
30.09.2019 19:39, Kevin Wolf wrote:
> Am 30.09.2019 um 18:26 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> 30.09.2019 19:00, Kevin Wolf wrote:
>>> Am 30.09.2019 um 17:19 hat Vladimir Sementsov-Ogievskiy geschrieben:
30.09.2019 18:12, Kevin Wolf wrote:
> Am 24.09.2019 um 22:08 hat Vladim
On 26/09/2019 12.18, David Hildenbrand wrote:
> On 26.09.19 12:16, David Hildenbrand wrote:
>> This only adds basic support to the DAT translation, but no EDAT2 support
>> for TCG. E.g., the gdbstub under kvm uses this function, too, to
>> translate virtual addresses.
>>
>> Reviewed-by: Thomas Huth
Paolo Bonzini writes:
> On 30/09/19 21:20, Alex Bennée wrote:
>> Does seem to imply the vCPU CPUState is where the queue is. That's not
>> to say there shouldn't be a single work queue for thread=single.
>
> Indeed it doesn't. I confused this with commit a8efa60633 ("cpus: run
> work items for
Am 01.10.2019 um 02:24 hat John Snow geschrieben:
>
>
> On 9/30/19 3:26 PM, Craig Mull wrote:
> > How can have QEMU backup write the output to an encrypted target?
> >
> > Blocks in the dirty bitmap are unencrypted, and as such when I write
> > them with QEMU backup they are written to the targ
On 27/09/2019 14.30, David Hildenbrand wrote:
> On 26.09.19 12:16, David Hildenbrand wrote:
>> We already implement ESOP-1. For ESOP-2, we only have to indicate all
>> protection exceptions properly. Due to EDAT-1, we already indicate DAT
>> exceptions properly. We don't trigger KCP/ALCP/IEP except
On 01.10.19 10:41, Thomas Huth wrote:
> On 26/09/2019 12.18, David Hildenbrand wrote:
>> On 26.09.19 12:16, David Hildenbrand wrote:
>>> This only adds basic support to the DAT translation, but no EDAT2 support
>>> for TCG. E.g., the gdbstub under kvm uses this function, too, to
>>> translate virtu
On 01/10/2019 10.51, David Hildenbrand wrote:
> On 01.10.19 10:41, Thomas Huth wrote:
>> On 26/09/2019 12.18, David Hildenbrand wrote:
>>> On 26.09.19 12:16, David Hildenbrand wrote:
This only adds basic support to the DAT translation, but no EDAT2 support
for TCG. E.g., the gdbstub under
On 01.10.19 10:55, Thomas Huth wrote:
> On 01/10/2019 10.51, David Hildenbrand wrote:
>> On 01.10.19 10:41, Thomas Huth wrote:
>>> On 26/09/2019 12.18, David Hildenbrand wrote:
On 26.09.19 12:16, David Hildenbrand wrote:
> This only adds basic support to the DAT translation, but no EDAT2 s
When vCPUs are hotplugged, they are added to the QEMU CPU list before
being fully realized. This can crash the XIVE presenter because the
'tctx' pointer is not necessarily initialized when looking for a
matching target.
These vCPUs are not valid targets for the presenter. Skip them.
Signed-off-by
Sergio Lopez writes:
> Michael S. Tsirkin writes:
>
>> On Tue, Sep 24, 2019 at 02:44:33PM +0200, Sergio Lopez wrote:
>>> +static void microvm_fix_kernel_cmdline(MachineState *machine)
>>> +{
>>> +X86MachineState *x86ms = X86_MACHINE(machine);
>>> +BusState *bus;
>>> +BusChild *kid;
01.10.2019 3:09, John Snow wrote:
> Hi folks, I identified a problem with the migration code that Red Hat QE
> found and thought you'd like to see it:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1652424#c20
>
> Very, very briefly: drive-mirror inserts a filter node that changes what
> bdrv_ge
On 9/30/19 11:01 AM, Andreas Schwab wrote:
Signed-off-by: Andreas Schwab
---
linux-user/strace.list | 3 +++
1 file changed, 3 insertions(+)
diff --git a/linux-user/strace.list b/linux-user/strace.list
index 63a946642d..863283418e 100644
--- a/linux-user/strace.list
+++ b/linux-user/strace.l
Hi Samuel,
On 9/29/19 8:13 PM, Samuel Thibault wrote:
This can be used to set a DNS server to be used by the guest which is
different from the one configured on the host.
This fixes LP 1010484.
Wow, 7 years old...
Can you use this format, easier to understand for newcomers:
Fixes: https://b
On 26/09/2019 12.16, David Hildenbrand wrote:
> IEP support in the mmu is fairly easy. Set the right permissions for TLB
> entries and properly report an exception.
>
> Make sure to handle EDAT-2 by setting bit 56/60/61 of the TEID (TEC) to
> the right values.
>
> Let's keep s390_cpu_get_phys_pag
On 9/30/19 5:04 PM, Thomas Huth wrote:
Currently, isa-superio.c is always compiled as soon as CONFIG_ISA_BUS
is enabled. But there are also machines that have an ISA BUS without
any of the superio chips attached to it, so we should not compile
isa-superio.c in case we only compile a QEMU for such
01.10.2019 7:28, Peter Krempa wrote:
> On Mon, Sep 30, 2019 at 20:09:28 -0400, John Snow wrote:
>> Hi folks, I identified a problem with the migration code that Red Hat QE
>> found and thought you'd like to see it:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1652424#c20
>>
>> Very, very brief
On 01/10/19 10:42, Alex Bennée wrote:
>
> Paolo Bonzini writes:
>
>> On 30/09/19 21:20, Alex Bennée wrote:
>>> Does seem to imply the vCPU CPUState is where the queue is. That's not
>>> to say there shouldn't be a single work queue for thread=single.
>>
>> Indeed it doesn't. I confused this wit
01.10.2019 3:09, John Snow wrote:
> Hi folks, I identified a problem with the migration code that Red Hat QE
> found and thought you'd like to see it:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1652424#c20
>
> Very, very briefly: drive-mirror inserts a filter node that changes what
> bdrv_ge
On 30/09/19 17:04, Thomas Huth wrote:
> Currently, isa-superio.c is always compiled as soon as CONFIG_ISA_BUS
> is enabled. But there are also machines that have an ISA BUS without
> any of the superio chips attached to it, so we should not compile
> isa-superio.c in case we only compile a QEMU for
On Fri, Sep 13, 2019 at 11:54:33PM +, Wei Yang wrote:
>On Wed, Jul 17, 2019 at 08:53:41AM +0800, Wei Yang wrote:
>>Wrap the check into a function to make it easy to read.
>>
>
>Hi, Dave & Juan
>
>Do you like this one :-) ?
>
Sorry for ping again.
>>Signed-off-by: Wei Yang
>>---
>> include/mi
Am 01.10.2019 um 10:39 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 30.09.2019 19:39, Kevin Wolf wrote:
> > Am 30.09.2019 um 18:26 hat Vladimir Sementsov-Ogievskiy geschrieben:
> >> 30.09.2019 19:00, Kevin Wolf wrote:
> >>> Am 30.09.2019 um 17:19 hat Vladimir Sementsov-Ogievskiy geschrieben:
> >
On 30/09/19 18:16, Jiri Denemark wrote:
> On Mon, Sep 30, 2019 at 17:16:27 +0200, Paolo Bonzini wrote:
>> On 30/09/19 16:31, Hu, Robert wrote:
This might be a problem if there are plans to eventually make KVM support
pconfig, though. Paolo, Robert, are there plans to support pconfig in K
On 01/10/2019 11.04, Philippe Mathieu-Daudé wrote:
> Hi Samuel,
>
> On 9/29/19 8:13 PM, Samuel Thibault wrote:
>> This can be used to set a DNS server to be used by the guest which is
>> different from the one configured on the host.
>>
>> This fixes LP 1010484.
>
> Wow, 7 years old...
>
> Can y
On 9/26/19 7:34 PM, Philippe Mathieu-Daudé wrote:
Add basic support for BCM283x CPRMAN. Provide support for reading and
writing CPRMAN registers and initialize registers with sensible default
values. During runtime retain any written values.
Basic CPRMAN support is necessary and sufficient to bo
Am 01.10.2019 um 10:57 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 01.10.2019 3:09, John Snow wrote:
> > Hi folks, I identified a problem with the migration code that Red Hat QE
> > found and thought you'd like to see it:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1652424#c20
> >
> >
> On Oct 1, 2019, at 9:23 AM, Dr. David Alan Gilbert
> wrote:
>
> * Felipe Franciosi (fel...@nutanix.com) wrote:
>>
>>
>>> On Sep 30, 2019, at 6:59 PM, Dr. David Alan Gilbert
>>> wrote:
>>>
>>> * Felipe Franciosi (fel...@nutanix.com) wrote:
> On Sep 30, 2019, at 6:11 PM,
Function postcopy_ram_incoming_setup and postcopy_ram_incoming_cleanup
is a pair. Rename to make it clear for audience.
Signed-off-by: Wei Yang
---
migration/postcopy-ram.c | 4 ++--
migration/postcopy-ram.h | 2 +-
migration/savevm.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-
The first one just tries to make function name more easy for reading and
understanding.
The next two patches are related to PostcopyState.
Wei Yang (3):
migration/postcopy: rename postcopy_ram_enable_notify to
postcopy_ram_incoming_setup
migration/postcopy: not necessary to do postcopy_ra
* Felipe Franciosi (fel...@nutanix.com) wrote:
>
>
> > On Oct 1, 2019, at 9:23 AM, Dr. David Alan Gilbert
> > wrote:
> >
> > * Felipe Franciosi (fel...@nutanix.com) wrote:
> >>
> >>
> >>> On Sep 30, 2019, at 6:59 PM, Dr. David Alan Gilbert
> >>> wrote:
> >>>
> >>> * Felipe Franciosi (fel.
postcopy_ram_incoming_cleanup() does cleanup for
postcopy_ram_incoming_setup(), while the setup happens only after
migration enters LISTEN state.
This means there is nothing to cleanup when migration is still ADVISE
state.
Signed-off-by: Wei Yang
---
migration/migration.c | 1 -
1 file changed,
Currently, we set PostcopyState blindly to RUNNING, even we found the
previous state is not LISTENING. This will lead to a corner case.
First let's look at the code flow:
qemu_loadvm_state_main()
ret = loadvm_process_command()
loadvm_postcopy_handle_run()
return -1;
if
01.10.2019 12:54, Kevin Wolf wrote:
> Am 01.10.2019 um 10:57 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> 01.10.2019 3:09, John Snow wrote:
>>> Hi folks, I identified a problem with the migration code that Red Hat QE
>>> found and thought you'd like to see it:
>>>
>>> https://bugzilla.redhat.co
On Tue, Oct 01, 2019 at 09:56:17AM +, Felipe Franciosi wrote:
>
>
> > On Oct 1, 2019, at 9:23 AM, Dr. David Alan Gilbert
> > wrote:
> >
> > * Felipe Franciosi (fel...@nutanix.com) wrote:
> >>
> >>
> >>> On Sep 30, 2019, at 6:59 PM, Dr. David Alan Gilbert
> >>> wrote:
> >>>
> >>> * Fel
On Mon, 30 Sep 2019 at 22:01, Richard Henderson
wrote:
>
> On 9/30/19 12:29 PM, Richard Henderson wrote:
> > This is a workaround for a ppc64le host kernel bug.
> > However, the host kernel has supplied si_code == SEGV_MAPERR,
> > which is obviously incorrect.
> It is disappointing about the ker
On Mon, 30 Sep 2019 at 14:20, Christian Borntraeger
wrote:
>
> Peter,
>
> The following changes since commit 786d36ad416c6c199b18b78cc31eddfb784fe15d:
>
> Merge remote-tracking branch
> 'remotes/pmaydell/tags/pull-target-arm-20190927' into staging (2019-09-30
> 11:02:22 +0100)
>
> are availabl
Hi Daniel!
> On Oct 1, 2019, at 11:31 AM, Daniel P. Berrangé wrote:
>
> On Tue, Oct 01, 2019 at 09:56:17AM +, Felipe Franciosi wrote:
>>
>>
>>> On Oct 1, 2019, at 9:23 AM, Dr. David Alan Gilbert
>>> wrote:
>>>
>>> * Felipe Franciosi (fel...@nutanix.com) wrote:
> On Sep
On Mon, Sep 30, 2019 at 07:23:47PM +, Felipe Franciosi wrote:
>
>
> > On Sep 30, 2019, at 6:59 PM, Dr. David Alan Gilbert
> > wrote:
> >
> > * Felipe Franciosi (fel...@nutanix.com) wrote:
> >>
> >>
> >>> On Sep 30, 2019, at 6:11 PM, Dr. David Alan Gilbert
> >>> wrote:
> >>>
> >>> * Fe
From: Marc-André Lureau
Fixes commit
e5758de4e836c3b2edc2befd904651fc6967d74f ("tests/libqtest: Make
qtest_qmp_device_add/del independent from global_qtest")
and commit
dd210749727530cdef7c335040edbf81c3c5d041 ("tests/libqtest: Use
libqtest-single.h in tests that require global_qtest").
Cc: Tho
Both, "rom->addr" and "addr" are derived from the binary image
that can be loaded with the "-kernel" paramer. The code in
rom_copy() then calculates:
d = dest + (rom->addr - addr);
and uses "d" as destination in a memcpy() some lines later. Now with
bad kernel images, it is possible that rom-
From: Marc-André Lureau
While at it, simplify using $(land).
Signed-off-by: Marc-André Lureau
Message-Id: <20190926111955.17276-3-marcandre.lur...@redhat.com>
Reviewed-by: Laurent Vivier
Reviewed-by: Thomas Huth
Fixes: dad5ddcea3b661 ("check: Only test usb-ehci when it is compiled in")
Signed
Hi Peter!
The following changes since commit 95e9d74fe4281f7ad79a5a7511400541729aa44a:
Merge remote-tracking branch 'remotes/borntraeger/tags/s390x-20190930' into
staging (2019-09-30 14:21:56 +0100)
are available in the Git repository at:
https://gitlab.com/huth/qemu.git tags/pull-request
Everybody who used something like "-machine accel=kvm:tcg" in the past
might be tempted to specify a similar list with the -accel parameter,
too, for example "-accel kvm:tcg". However, this is not how this
options is thought to be used, since each "-accel" should only take care
of one specific acce
From: Thomas Huth
Coverity currently complains that the "if (0x00 & (0x80 >> (phase - 8))"
in next-cube.c can never be true. Right it is. The "0x00" is meant as value
of the control register of the RTC, which is currently not implemented yet.
Thus, let's add a register variable for this now. Howe
The need for specifying "-hda" together with "-kernel" has been removed in
commit 57a46d057995 ("Convert linux bootrom to external rom and fw_cfg"),
almost 10 years ago, so let's remove this description from our documentation
now, too.
Signed-off-by: Thomas Huth
---
qemu-doc.texi | 4
1 fil
On Tue, 1 Oct 2019 10:57:22 +0200
Cédric Le Goater wrote:
> When vCPUs are hotplugged, they are added to the QEMU CPU list before
> being fully realized. This can crash the XIVE presenter because the
> 'tctx' pointer is not necessarily initialized when looking for a
> matching target.
>
Ouch..
On Tue, Oct 01, 2019 at 10:46:24AM +, Felipe Franciosi wrote:
> Hi Daniel!
>
>
> > On Oct 1, 2019, at 11:31 AM, Daniel P. Berrangé wrote:
> >
> > On Tue, Oct 01, 2019 at 09:56:17AM +, Felipe Franciosi wrote:
>
> (Apologies for the mangled URL, nothing I can do about that.) :(
>
> Ther
On Tue, Oct 01, 2019 at 01:01:11PM +0200, Thomas Huth wrote:
> The need for specifying "-hda" together with "-kernel" has been removed in
> commit 57a46d057995 ("Convert linux bootrom to external rom and fw_cfg"),
> almost 10 years ago, so let's remove this description from our documentation
> now,
Le 01/10/2019 à 12:34, Peter Maydell a écrit :
> On Mon, 30 Sep 2019 at 22:01, Richard Henderson
> wrote:
>>
>> On 9/30/19 12:29 PM, Richard Henderson wrote:
>>> This is a workaround for a ppc64le host kernel bug.
>
>>> However, the host kernel has supplied si_code == SEGV_MAPERR,
>>> which is ob
> On Oct 1, 2019, at 12:10 PM, Daniel P. Berrangé wrote:
>
> On Tue, Oct 01, 2019 at 10:46:24AM +, Felipe Franciosi wrote:
>> Hi Daniel!
>>
>>
>>> On Oct 1, 2019, at 11:31 AM, Daniel P. Berrangé wrote:
>>>
>>> On Tue, Oct 01, 2019 at 09:56:17AM +, Felipe Franciosi wrote:
>>
>> (Apo
On Tue, Oct 01, 2019 at 10:45:53 +0200, Kevin Wolf wrote:
> Am 01.10.2019 um 02:24 hat John Snow geschrieben:
> >
> >
> > On 9/30/19 3:26 PM, Craig Mull wrote:
> > > How can have QEMU backup write the output to an encrypted target?
> > >
> > > Blocks in the dirty bitmap are unencrypted, and as
On 01/10/2019 10:11, David Gibson wrote:
> On Tue, Oct 01, 2019 at 09:41:27AM +0200, Cédric Le Goater wrote:
>> On 01/10/2019 08:47, David Gibson wrote:
>>> On Tue, Oct 01, 2019 at 07:43:51AM +0200, Cédric Le Goater wrote:
On 01/10/2019 04:31, David Gibson wrote:
> On Mon, Sep 30, 2019 at
On Tue, Oct 01, 2019 at 08:57:37 +, Vladimir Sementsov-Ogievskiy wrote:
> 01.10.2019 3:09, John Snow wrote:
> > Hi folks, I identified a problem with the migration code that Red Hat QE
> > found and thought you'd like to see it:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1652424#c20
>
On Tue, 1 Oct 2019 at 12:19, Laurent Vivier wrote:
> Is it possible to update the farm to Centos 8?
>
> Or as the kernel involved is specifically for POWER9, is it possible to
> use only POWER8?
My experience is that the gcc cfarm admins aren't in
principle against the idea of upgrading farm mach
On 01/10/2019 13:06, Greg Kurz wrote:
> On Tue, 1 Oct 2019 10:57:22 +0200
> Cédric Le Goater wrote:
>
>> When vCPUs are hotplugged, they are added to the QEMU CPU list before
>> being fully realized. This can crash the XIVE presenter because the
>> 'tctx' pointer is not necessarily initialized w
On Tue, Oct 01, 2019 at 01:01:11PM +0200, Thomas Huth wrote:
> The need for specifying "-hda" together with "-kernel" has been removed in
> commit 57a46d057995 ("Convert linux bootrom to external rom and fw_cfg"),
> almost 10 years ago, so let's remove this description from our documentation
> now,
Hello,
does it have a reason why the file vl.c lacks reference
#include "qemu/module.h" ?
but still uses the defines include their(for example the enum value:
MODULE_INIT_OPTS)?
I'm using eclipse so I was notified by the IDE immediately.
Thanks for yours help :)
On Mon, 30 Sep 2019 at 18:47, Paolo Bonzini wrote:
> On 30/09/19 17:37, Peter Maydell wrote:
> > Side note -- this use of run_on_cpu() means that we now drop
> > the iothread lock within memory_region_snapshot_and_clear_dirty(),
> > which we didn't before. This means that a vCPU thread can now
> >
Hello,
does it have a reason why the file vl.c lacks reference
#include "qemu/module.h" ?
but still uses the defines include their(for example the enum value:
MODULE_INIT_OPTS)?
I'm using eclipse so I was notified by the IDE immediately.
Thanks for yours help :)
On Mon, 30 Sep 2019 at 11:48, Peter Maydell wrote:
>
> On Sat, 28 Sep 2019 at 19:45, Markus Armbruster wrote:
> >
> > The following changes since commit c6f5012ba5fa834cbd5274b1b8369e2c5d2f5933:
> >
> > Merge remote-tracking branch
> > 'remotes/stsquad/tags/pull-testing-next-260919-1' into sta
On Tue, 1 Oct 2019 at 11:51, Thomas Huth wrote:
>
> Hi Peter!
>
> The following changes since commit 95e9d74fe4281f7ad79a5a7511400541729aa44a:
>
> Merge remote-tracking branch 'remotes/borntraeger/tags/s390x-20190930' into
> staging (2019-09-30 14:21:56 +0100)
>
> are available in the Git repo
On Tue, Oct 01, 2019 at 03:12:17PM +0300, Toe Dev wrote:
> Hello,
> does it have a reason why the file vl.c lacks reference
> #include "qemu/module.h" ?
> but still uses the defines include their(for example the enum value:
> MODULE_INIT_OPTS)?
qemu/module.h is included by qom/object.h which is
Since Linux kernel v5.2-rc1 KVM has support for enabling SVE in guests.
This series provides the QEMU bits for that enablement. First, we
select existing CPU properties representing features we want to
advertise in addition to the SVE vector lengths and prepare
them for a qmp query. Then we introdu
Now that Arm CPUs have advertised features lets add tests to ensure
we maintain their expected availability with and without KVM.
Signed-off-by: Andrew Jones
Reviewed-by: Eric Auger
---
tests/Makefile.include | 5 +-
tests/arm-cpu-features.c | 242 +++
2
Since 97a28b0eeac14 ("target/arm: Allow VFP and Neon to be disabled via
a CPU property") we can disable the 'max' cpu model's VFP and neon
features, but there's no way to disable SVE. Add the 'sve=on|off'
property to give it that flexibility. We also rename
cpu_max_get/set_sve_vq to cpu_max_get/set
Introduce cpu properties to give fine control over SVE vector lengths.
We introduce a property for each valid length up to the current
maximum supported, which is 2048-bits. The properties are named, e.g.
sve128, sve256, sve384, sve512, ..., where the number is the number of
bits. See the updates t
Add support for the query-cpu-model-expansion QMP command to Arm. We
do this selectively, only exposing CPU properties which represent
optional CPU features which the user may want to enable/disable.
Additionally we restrict the list of queryable cpu models to 'max',
'host', or the current type whe
These are the SVE equivalents to kvm_arch_get/put_fpsimd. Note, the
swabbing is different than it is for fpsmid because the vector format
is a little-endian stream of words.
Signed-off-by: Andrew Jones
---
target/arm/kvm64.c | 183 ++---
1 file changed, 15
Allow cpu 'host' to enable SVE when it's available, unless the
user chooses to disable it with the added 'sve=off' cpu property.
Also give the user the ability to select vector lengths with the
sve properties. We don't adopt 'max' cpu's other sve property,
sve-max-vq, because that property is diffi
kvm_arm_create_scratch_host_vcpu() takes a struct kvm_vcpu_init
parameter. Rather than just using it as an output parameter to
pass back the preferred target, use it also as an input parameter,
allowing a caller to pass a selected target if they wish and to
also pass cpu features. If the caller doe
Extend the SVE vq map initialization and validation with KVM's
supported vector lengths when KVM is enabled. In order to determine
and select supported lengths we add two new KVM functions for getting
and setting the KVM_REG_ARM64_SVE_VLS pseudo-register.
This patch has been co-authored with Richa
Enable SVE in the KVM guest when the 'max' cpu type is configured
and KVM supports it. KVM SVE requires use of the new finalize
vcpu ioctl, so we add that now too. For starters SVE can only be
turned on or off, getting all vector lengths the host CPU supports
when on. We'll add the other SVE CPU pr
Move synchronization mechanism to block-copy, to be able to use one
block-copy instance from backup job and backup-top filter in parallel.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
include/block/block-copy.h | 8 ++
block/backup.c | 52 -
Hi all!
These series introduce backup-top driver. It's a filter-node, which
do copy-before-write operation. Mirror uses filter-node for handling
guest writes, let's move to filter-node (from write-notifiers) for
backup too.
Preparation patches are queued in Max's block branch:
Based-on: https://
On 10/1/19 3:36 AM, Paolo Bonzini wrote:
> On 26/09/19 20:35, Alex Bennée wrote:
>> From: John Snow
>>
>> Fedora23 is but a distant twinkle. The sanitizer works again, and even
>> if not, we have --enable-sanitizers now.
>>
>> Signed-off-by: John Snow
>> Message-Id: <20190912014442.5757-1-js..
This is logic-less refactoring, which simplifies further patch, as
we'll need write_flags for backup-top filter creation and backup-top
should be created before block job creation.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block/backup.c | 30 +++---
1 file changed,
Backup-top filter caches write operations and does copy-before-write
operations.
The driver will be used in backup instead of write-notifiers.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block/backup-top.h | 41 +++
block/backup-top.c | 281 +++
Split block_copy_set_callbacks out of block_copy_state_new. It's needed
for further commit: block-copy will use BdrvChildren of backup-top
filter, so it will be created from backup-top filter creation function.
But callbacks will still belong to backup job and will be set in
separate.
Signed-off-b
Le 01/10/2019 à 13:46, Peter Maydell a écrit :
> On Tue, 1 Oct 2019 at 12:19, Laurent Vivier wrote:
>> Is it possible to update the farm to Centos 8?
>>
>> Or as the kernel involved is specifically for POWER9, is it possible to
>> use only POWER8?
>
> My experience is that the gcc cfarm admins ar
Drop write notifiers and use filter node instead.
= Changes =
1. Add filter-node-name argument for backup qmp api. We have to do it
in this commit, as 257 needs to be fixed.
2. There are no more write notifiers here, so is_write_notifier
parameter is dropped from block-copy paths.
3. To sync wi
On Tue, Oct 01, 2019 at 11:54:16 +0200, Kevin Wolf wrote:
> Am 01.10.2019 um 10:57 hat Vladimir Sementsov-Ogievskiy geschrieben:
> > 01.10.2019 3:09, John Snow wrote:
> > > Hi folks, I identified a problem with the migration code that Red Hat QE
> > > found and thought you'd like to see it:
> > >
On Mon 26 Aug 2019 04:21:37 PM CEST, Tony Nguyen wrote:
> For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
> targets from the set of target/hw/*/device.o.
>
> If the set of targets are all little or all big endian, re-declare
> as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN respect
In general, WSAEWOULDBLOCK can be mapped to EAGAIN as done by
socket_error() (or EWOULDBLOCK). But for connect() with non-blocking
sockets, it actually means the operation is in progress:
https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-connect
"The socket is marked as nonbl
Hi,
Here are a few patches that should fix some busy looping issues
already reported >2y ago
(https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg00420.html),
and fixing test-char on win32.
hmm, do we have any automated testing/CI on Windows (beside just
cross-compilation)?
thanks
Marc-And
Serial test is currently hard-coded to /dev/null.
On Windows, serial chardev expect a COM: device, which may not be
availble.
Signed-off-by: Marc-André Lureau
---
tests/test-char.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/test-char.c b/tests/test-char.c
inde
Commit 05e514b1d4d5bd4209e2c8bbc76ff05c85a235f3 introduced an AIO
context optimization to avoid calling event_notifier_test_and_clear() on
ctx->notifier. On Windows, the same notifier is being used to wakeup the
wait on socket events (see commit
d3385eb448e38f828c78f8f68ec5d79c66a58b5d).
The ctx->
Currently offloads disabled by guest via the VIRTIO_NET_CTRL_GUEST_OFFLOADS_SET
command are not preserved on VM migration.
Instead all offloads reported by guest features (via VIRTIO_PCI_GUEST_FEATURES)
get enabled.
What happens is: first the VirtIONet::curr_guest_offloads gets restored and
offloa
Hi all,
I've recently faced an issue that the offloads settings of my Windows VM's
tap devices reported with "ethtool -k" get changed after the VM migration.
After a quick look it appears that the offloads always get resent
to the complete set of features the guest has reported.
Here I'm sending
1 - 100 of 562 matches
Mail list logo
