Tried sending you a message @ginf, but haven't heard back from you so I'm
posting here instead;
What kind of debug trace do you want me to give you logs from?
$ /opt/qemu4/bin/qemu-system-x86_64 -d help
Log items (comma separated):
out_asm show generated host assembly code for each compile
On Thu, 12 Sep 2019 11:50:53 +1000
Alexey Kardashevskiy wrote:
>
>
> On 11/09/2019 19:16, Greg Kurz wrote:
> > On Wed, 11 Sep 2019 14:04:51 +1000
> > David Gibson wrote:
> >
> >> From: Alexey Kardashevskiy
> >>
> >> SLOF implements one itself so let's remove it from QEMU. It is one less
> >>
On Fri, 2019-09-06 at 14:11 +0100, Daniel P. Berrangé wrote:
> On Mon, Aug 26, 2019 at 04:50:59PM +0300, Maxim Levitsky wrote:
> > This is just to make qcrypto_block_luks_open more
> > reasonable in size.
> >
> > Signed-off-by: Maxim Levitsky
> > ---
> > crypto/block-luks.c | 254 +++
On Thu 12 Sep 2019 01:33:05 AM CEST, John Snow wrote:
>> This restriction comes from commit 095a9c58ce12afeeb90c2 from 2018.
>
> You accidentally typed a reasonably modern date. It's from *2008*!
Oh my, and I reviewed the message 3 times ... if this one gets committed
please correct the date.
Be
Patchew URL:
https://patchew.org/QEMU/20190912060701.4642-1-ys...@users.sourceforge.jp/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PATCH v24 00/22] Add RX archtecture support
Message-id: 20190912060701.4642-1-ys...@u
On Wed, Sep 11, 2019 at 05:51:24PM +0200, Eric Auger wrote:
> Host kernels that expose the KVM_CAP_ARM_IRQ_LINE_LAYOUT_2 capability
> allow injection of interrupts along with vcpu ids larger than 255.
> Let's encode the vpcu id on 12 bits according to the upgraded KVM_IRQ_LINE
> ABI when needed.
>
On Wed, Sep 11, 2019 at 05:51:25PM +0200, Eric Auger wrote:
> Host kernel within [4.18, 5.3] report an erroneous KVM_MAX_VCPUS=512
> for ARM. The actual capability to instantiate more than 256 vcpus
> was fixed in 5.4 with the upgrade of the KVM_IRQ_LINE ABI to support
> vcpu id encoded on 12 bits
On Fri, 2019-09-06 at 14:17 +0100, Daniel P. Berrangé wrote:
> On Mon, Aug 26, 2019 at 04:51:01PM +0300, Maxim Levitsky wrote:
> > Signed-off-by: Maxim Levitsky
> > ---
> > crypto/block-luks.c | 64 +
> > 1 file changed, 41 insertions(+), 23 deletions(-
Wei Yang wrote:
> Signed-off-by: Wei Yang
Reviewed-by: Juan Quintela
for(i = 0; i < 0; i++)
printf("Beginning is with double n, not double g");
Patchew URL:
https://patchew.org/QEMU/20190912060701.4642-1-ys...@users.sourceforge.jp/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PATCH v24 00/22] Add RX archtecture support
Message-id: 20190912060701.4642-1-ys...@u
Am 12.09.2019 um 00:08 hat Philippe Mathieu-Daudé geschrieben:
> The 'blockdev-create' QMP command was introduced as experimental
> feature in commit b0292b851b8, using the assert() debug call.
> It got promoted to 'stable' command in 3fb588a0f2c, but the
> assert call was not removed.
>
> Some bl
* Johannes Berg (johan...@sipsolutions.net) wrote:
> On Wed, 2019-09-11 at 20:15 +0100, Dr. David Alan Gilbert wrote:
>
> > > Extend the protocol slightly, so that a message can be used for kick
> > > and call instead, if VHOST_USER_PROTOCOL_F_IN_BAND_NOTIFICATIONS is
> > > negotiated. This in its
On Fri, 2019-09-06 at 14:34 +0100, Daniel P. Berrangé wrote:
> On Mon, Aug 26, 2019 at 04:51:03PM +0300, Maxim Levitsky wrote:
> > Check that keyslots don't overlap with the data,
> > and check that keyslots don't overlap with each other.
> > (this is done using naive O(n^2) nested loops,
> > but s
On Thu, 2019-09-12 at 09:09 +0100, Dr. David Alan Gilbert wrote:
>
> You're actually using the same trick of using
> REPLY_ACK/need_reply to make it synchronous that set_mem_table does;
I don't think it's really the same - though arguably I could have
spec'ed the inband signal to *require* an AC
Am 11.09.2019 um 23:33 hat Eric Blake geschrieben:
> On 9/11/19 12:21 PM, Eric Blake wrote:
> > On 9/11/19 11:15 AM, Sergio Lopez wrote:
> >> On creation, the export's AioContext is set to the same one as the
> >> BlockBackend, while the AioContext in the client QIOChannel is left
> >> untouched.
>
11.09.2019 20:59, John Snow wrote:
>
>
> On 9/11/19 11:13 AM, Vladimir Sementsov-Ogievskiy wrote:
>> 07.08.2019 19:27, John Snow wrote:
>>>
>>>
>>> On 8/6/19 12:19 PM, Vladimir Sementsov-Ogievskiy wrote:
06.08.2019 19:09, Max Reitz wrote:
> On 06.08.19 17:26, Vladimir Sementsov-Ogievskiy
Am 11.09.2019 um 18:15 hat Sergio Lopez geschrieben:
> On creation, the export's AioContext is set to the same one as the
> BlockBackend, while the AioContext in the client QIOChannel is left
> untouched.
>
> As a result, when using data-plane, nbd_client_receive_next_request()
> schedules corouti
Hi James,
OK, thanks - some questions:
a) What version of spice-server have you got on your host?
b) Does swapping the '-vga qxl' for '-device qxl-vga,max_outputs=1' help?
(try with and without the max_outputs=1)
c) Are you able to do bisect builds to try and track down which commit
On Wed, 11 Sep 2019 at 14:14, Alex Bennée wrote:
> It does seem a bit weird that userspace linux-user does do semihosting
> whereas EL0 in softmmu doesn't. Is that because we are effectively
> short-circuiting what a real ARM kernel would be doing for EL0?
It's because the "not for EL0" is a rath
On Wed, 11 Sep 2019 at 16:51, Eric Auger wrote:
>
> Host kernel within [4.18, 5.3] report an erroneous KVM_MAX_VCPUS=512
> for ARM. The actual capability to instantiate more than 256 vcpus
> was fixed in 5.4 with the upgrade of the KVM_IRQ_LINE ABI to support
> vcpu id encoded on 12 bits instead o
ping!
On 05.09.2019 12:31, Denis Plotnikov wrote:
> v6:
> * fixed zstd compressed length storing/loading [Eric]
> * fixed wording, spec section placement [Eric]
>
> v5:
> * type changed for compression_type at BDRVQcow2State [Kevin]
> * fixed typos, grammar [Kevin]
> * fixed default config zstd se
On Fri, Jul 5, 2019 at 5:05 PM Geert Uytterhoeven
wrote:
> GPIO controllers are exported to userspace using /dev/gpiochip*
> character devices. Access control to these devices is provided by
> standard UNIX file system permissions, on an all-or-nothing basis:
> either a GPIO controller is access
Hi Peter,
On 9/12/19 10:42 AM, Peter Maydell wrote:
> On Wed, 11 Sep 2019 at 16:51, Eric Auger wrote:
>>
>> Host kernel within [4.18, 5.3] report an erroneous KVM_MAX_VCPUS=512
>> for ARM. The actual capability to instantiate more than 256 vcpus
>> was fixed in 5.4 with the upgrade of the KVM_IRQ_
Hi Drew,
On 9/12/19 9:36 AM, Andrew Jones wrote:
> On Wed, Sep 11, 2019 at 05:51:24PM +0200, Eric Auger wrote:
>> Host kernels that expose the KVM_CAP_ARM_IRQ_LINE_LAYOUT_2 capability
>> allow injection of interrupts along with vcpu ids larger than 255.
>> Let's encode the vpcu id on 12 bits accor
Hi Linus,
On Thu, Sep 12, 2019 at 10:56 AM Linus Walleij wrote:
> On Fri, Jul 5, 2019 at 5:05 PM Geert Uytterhoeven
> wrote:
> > GPIO controllers are exported to userspace using /dev/gpiochip*
> > character devices. Access control to these devices is provided by
> > standard UNIX file system pe
Hi Richard,
On Wed, Sep 4, 2019 at 9:39 PM Richard Henderson
wrote:
>
> Since all of the inputs and outputs are i32, dispense with
> the intermediate promotion to i64 and use tcg_gen_add2_i32.
>
> Reviewed-by: Peter Maydell
> Signed-off-by: Richard Henderson
> ---
> target/arm/translate.c | 15
On Thu, 12 Sep 2019 at 09:57, Auger Eric wrote:
>
> Hi Peter,
> On 9/12/19 10:42 AM, Peter Maydell wrote:
> > Is there really no place to put this check in common code?
> Not sure what you mean by common code here? Do you mean in a common code
> for ARM machines (I don't think we have any atm) o
Markus Armbruster writes:
> Alex Bennée writes:
>
>> Markus Armbruster writes:
> [...]
>>> Please advise why TCG plugins don't undermine the GPL. Any proposal to
>>> add a plugin interface needs to do that.
>>
>> I'm not sure what we can say about this apart from "ask your lawyer".
>
> I'm n
On Wed, 11 Sep 2019 at 11:36, Dr. David Alan Gilbert
wrote:
>
> * Beata Michalska (beata.michal...@linaro.org) wrote:
> > On Tue, 10 Sep 2019 at 14:16, Dr. David Alan Gilbert
> > wrote:
> > >
> > > * Beata Michalska (beata.michal...@linaro.org) wrote:
> > > > On Tue, 10 Sep 2019 at 12:26, Dr. Dav
Let the caller allocate masterkey
Always use master key len from the header
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
crypto/block-luks.c | 44 +---
1 file changed, 21 insertions(+), 23 deletions(-)
diff --git a/crypto/block-luks.
Hi!
This patch series is the refactoring/preparation part of the
former patch series I had sent which adds support for luks
key management.
This series includes all the feedback from the last review iteration
and one new patch that removes errno values from .open
callback of luks crypto driver si
Another minor refactoring
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
crypto/block-luks.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/crypto/block-luks.c b/crypto/block-luks.c
index 9e59a791a6..b759cc8d19 100644
--- a/crypto/block-luks.c
+++ b
Prior to that patch, the parsed encryption settings
were already stored into the QCryptoBlockLUKS but not
used anywhere but in qcrypto_block_luks_get_info
Using them simplifies the code
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
crypto/block-luks.c | 169
* rename the write_func to create_write_func,
and init_func to create_init_func
this is preparation for other write_func that will
be used to update the encryption keys.
No functional changes
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
block/crypto.c | 12 ++---
Signed-off-by: Maxim Levitsky
---
crypto/block-luks.c | 158 ++--
1 file changed, 94 insertions(+), 64 deletions(-)
diff --git a/crypto/block-luks.c b/crypto/block-luks.c
index ba63e9b442..c3f3488222 100644
--- a/crypto/block-luks.c
+++ b/crypto/block-luks
On Wed, Jul 31, 2019 at 05:06:39PM +0100, Alex Bennée wrote:
> From: "Emilio G. Cota"
>
> Signed-off-by: Emilio G. Cota
> [AJB: moved directory and merged various fixes]
> Signed-off-by: Alex Bennée
> +static int plugin_load(struct qemu_plugin_desc *desc)
> +{
> +qemu_plugin_install_func_
* key_bytes -> master_key_len
* payload_offset = payload_offset_sector (to emphasise that this isn't byte
offset)
* key_offset -> key_offset_sector - same as above for luks slots
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
crypto/block-luks.c | 91 +++-
This is just to make qcrypto_block_luks_open more
reasonable in size.
Signed-off-by: Maxim Levitsky
---
crypto/block-luks.c | 235
1 file changed, 127 insertions(+), 108 deletions(-)
diff --git a/crypto/block-luks.c b/crypto/block-luks.c
index c3f348
This function will be used later to store
new keys to the luks metadata
Signed-off-by: Maxim Levitsky
---
crypto/block-luks.c | 304 ++--
1 file changed, 181 insertions(+), 123 deletions(-)
diff --git a/crypto/block-luks.c b/crypto/block-luks.c
index 24c1
This way we can store the header we loaded, which
will be used in key management code
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
crypto/block-luks.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/crypto/block-luks.c b/crypto/block-luks.c
inde
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
crypto/block-luks.c | 63 -
1 file changed, 40 insertions(+), 23 deletions(-)
diff --git a/crypto/block-luks.c b/crypto/block-luks.c
index c6045da33e..0d155c6614 100644
--- a/crypto/blo
Hi Peter,
On 9/12/19 11:00 AM, Peter Maydell wrote:
> On Thu, 12 Sep 2019 at 09:57, Auger Eric wrote:
>>
>> Hi Peter,
>> On 9/12/19 10:42 AM, Peter Maydell wrote:
>
>>> Is there really no place to put this check in common code?
>
>> Not sure what you mean by common code here? Do you mean in a co
These values are not used by generic crypto code anyway
Signed-off-by: Maxim Levitsky
---
crypto/block-luks.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/crypto/block-luks.c b/crypto/block-luks.c
index f3bfc921b2..ba63e9b442 100644
--- a/crypt
Patchew URL:
https://patchew.org/QEMU/20190912060701.4642-1-ys...@users.sourceforge.jp/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PATCH v24 00/22] Add RX archtecture support
Message-id: 20190912060701.4642-1-ys...@u
https://lists.gnu.org/archive/html/qemu-block/2019-09/msg00481.html
fix issue and migration work fine
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1842038
Title:
qemu 4.0/4.1 segfault on live migr
Am 12.09.2019 um 09:25 hat Alberto Garcia geschrieben:
> On Thu 12 Sep 2019 01:33:05 AM CEST, John Snow wrote:
> >> This restriction comes from commit 095a9c58ce12afeeb90c2 from 2018.
> >
> > You accidentally typed a reasonably modern date. It's from *2008*!
>
> Oh my, and I reviewed the message
Check that keyslots don't overlap with the data,
and check that keyslots don't overlap with each other.
(this is done using naive O(n^2) nested loops,
but since there are just 8 keyslots, this doesn't really matter.
Signed-off-by: Maxim Levitsky
---
crypto/block-luks.c | 52 +
During PowerNV boot skiboot populates the device tree by
retrieving base address of homer/occ common area from
PBA BARs and prd ipoll mask by accessing xscom read/write
accesses.
Reviewed-by: Cédric Le Goater
Signed-off-by: Balamuruhan S
---
hw/ppc/pnv_xscom.c | 34 +++
On Thu, 12 Sep 2019 at 10:03, Alex Bennée wrote:
>
> Well the first thing will be we are not intending to offer a guaranteed
> ABI. While we don't want to be changing it at a whim there shouldn't be
> an expectation that the plugin interface will maintain backwards
> compatibility (unlike the comm
On Wed, Sep 11, 2019 at 08:06:19PM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> Use the automatic read unlocker in migration/ram.c;
> only for the cases where the unlock is at the end of the function.
>
> Signed-off-by: Dr. David Alan Gilbert
> ---
> migratio
a) spice 0.14.2. Also spice-gtk 0.37, and spice-protocol 0.14.0.
b) Swapping with "-device qxl-vga,max_outputs=1" does fix the problem.
Swapping with "-device qxl-vga" still has the bug.
c) Knowing b, would the bisect still help? If needed, sure, I will.
--
You received this bug notification
On Wed, Sep 11, 2019 at 08:06:18PM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> RCU_READ_LOCK_AUTO takes the rcu_read_lock and then uses glib's
> g_auto infrastructure (and thus whatever the compiler's hooks are) to
> release it on all exits of the block.
>
> S
On Wed, Sep 11, 2019 at 08:06:20PM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> Use the automatic read unlocker in migration/rdma.c.
>
> Signed-off-by: Dr. David Alan Gilbert
> ---
> migration/rdma.c | 57 ++--
> 1
Hi All,
This is follow-up patch that implements HOMER and OCC SRAM device
models to emulate homer memory and occ common area access for pstate
table, occ sensors, runtime data and slw.
Currently skiboot disables the homer/occ code path with `QUIRK_NO_PBA`,
this quirk have to be removed in skiboot
There were few trailing comments after `/*` instead in
new line and line more than 80 character, these fixes are
trivial and doesn't change any logic in code.
Reviewed-by: Cédric Le Goater
Signed-off-by: Balamuruhan S
---
hw/ppc/pnv.c | 49 -
1 fi
On Wed, Sep 11, 2019 at 08:06:21PM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> Only in the cases where nothing else interesting happens
> after the unlock.
>
> Signed-off-by: Dr. David Alan Gilbert
> ---
> exec.c | 46 +--
emulate occ common area region with occ sram device model which
occ and skiboot uses it to communicate regarding sensors, slw
and HWMON in PowerNV emulated host.
Reviewed-by: Cédric Le Goater
Signed-off-by: Balamuruhan S
---
hw/ppc/pnv.c | 8 +
hw/ppc/pnv_occ.c | 78 +++
add PnvHomer device model to emulate homer memory access
for pstate table, occ-sensors, slw, occ static and dynamic
values for Power8 and Power9 chips.
Signed-off-by: Balamuruhan S
---
hw/ppc/Makefile.objs | 1 +
hw/ppc/pnv.c | 30 +
hw/ppc/pnv_homer.c | 272 ++
Patchew URL:
https://patchew.org/QEMU/20190912060701.4642-1-ys...@users.sourceforge.jp/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PATCH v24 00/22] Add RX archtecture support
Message-id: 20190912060701.4642-1-ys...@u
On Thu, Sep 12, 2019 at 10:03:48AM +0100, Alex Bennée wrote:
>
> Markus Armbruster writes:
>
> > Alex Bennée writes:
> >
> >> Markus Armbruster writes:
> > [...]
> >>> Please advise why TCG plugins don't undermine the GPL. Any proposal to
> >>> add a plugin interface needs to do that.
> >>
>
OK that's interesting - I've got another bug I've been following that's
also fixed by (b).
A bisect would still be interesting; but one place to start might be to try
before and after commit
be812c0
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subs
On Wed, Sep 11, 2019 at 08:06:22PM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> Error path missing an unlock.
>
> Signed-off-by: Dr. David Alan Gilbert
> ---
> migration/ram.c | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Daniel P. Berrangé
Regards
On Fri, 2019-09-06 at 14:55 +0100, Daniel P. Berrangé wrote:
> On Fri, Aug 30, 2019 at 11:56:01PM +0300, Maxim Levitsky wrote:
> > Signed-off-by: Maxim Levitsky
> > ---
> > crypto/block-luks.c | 366 +++-
> > 1 file changed, 364 insertions(+), 2 deletions(-
On 12/09/2019 11:30, Balamuruhan S wrote:
> add PnvHomer device model to emulate homer memory access
> for pstate table, occ-sensors, slw, occ static and dynamic
> values for Power8 and Power9 chips.
>
> Signed-off-by: Balamuruhan S
Reviewed-by: Cédric Le Goater
Thanks,
C.
> ---
> hw/ppc/
On 12/09/2019 11:30, Balamuruhan S wrote:
> Hi All,
>
> This is follow-up patch that implements HOMER and OCC SRAM device
> models to emulate homer memory and occ common area access for pstate
> table, occ sensors, runtime data and slw.
So, now, we can write directly to the OCC SRAM memory region
On Fri, 2019-09-06 at 14:59 +0100, Daniel P. Berrangé wrote:
> On Fri, Aug 30, 2019 at 11:56:02PM +0300, Maxim Levitsky wrote:
>
> This could do with some text to explain what this will be
> used for.
I actually added an explanation to the man page
"
+--force allows some unsafe operations. Curre
Queued
* Ivan Ren (reny...@gmail.com) wrote:
> From: Ivan Ren
>
> When encounter error, multifd_send_thread should always notify who pay
> attention to it before exit. Otherwise it may block migration_thread
> at multifd_send_sync_main forever.
>
> Error as follow:
> ---
* Wei Yang (richardw.y...@linux.intel.com) wrote:
> During migration, there are several places to iterate on
> savevm.handlers. And on each iteration, we need to check its ops and
> related callbacks before invoke it.
>
> Generally, ops is the first element to check, and it is only necessary
> to
Peter Maydell writes:
> On Thu, 12 Sep 2019 at 10:03, Alex Bennée wrote:
>>
>> Well the first thing will be we are not intending to offer a guaranteed
>> ABI. While we don't want to be changing it at a whim there shouldn't be
>> an expectation that the plugin interface will maintain backwards
On Fri, 2019-09-06 at 15:04 +0100, Daniel P. Berrangé wrote:
> On Fri, Aug 30, 2019 at 11:56:03PM +0300, Maxim Levitsky wrote:
> > This implements the encryption key management
> > using the generic code in qcrypto layer
> > (currently only for qemu-img amend)
> >
> > This code adds another 'write
Kevin Wolf writes:
> Am 11.09.2019 um 18:15 hat Sergio Lopez geschrieben:
>> On creation, the export's AioContext is set to the same one as the
>> BlockBackend, while the AioContext in the client QIOChannel is left
>> untouched.
>>
>> As a result, when using data-plane, nbd_client_receive_next_
* Dr. David Alan Gilbert (git) (dgilb...@redhat.com) wrote:
> From: "Dr. David Alan Gilbert"
>
> Commit 78dd48df3 reworked vmxnet3's live migration but left a straggling
> unregister_savevm call. Remove it, although it doesn't seem to have
> any bad effect.
>
> Signed-off-by: Dr. David Alan Gil
* Dr. David Alan Gilbert (git) (dgilb...@redhat.com) wrote:
> From: "Dr. David Alan Gilbert"
>
> Commit 11808bb removed the non-iovec based write support,
> the comment hung on.
>
> Signed-off-by: Dr. David Alan Gilbert
Queued
> ---
> migration/qemu-file.c | 5 ++---
> 1 file changed, 2 inse
On Wed, Sep 11, 2019 at 03:36:16PM +0100, Paul Durrant wrote:
> Xenstore watch call-backs are already abstracted away from XenBus using
> the XenWatch data structure but the associated NotifierList manipulation
> and file handle registation is still open coded in various xen_bus_...()
On Thu, Sep 12, 2019 at 11:07:07AM +0100, Alex Bennée wrote:
>
> Peter Maydell writes:
>
> > On Thu, 12 Sep 2019 at 10:03, Alex Bennée wrote:
> >>
> >> Well the first thing will be we are not intending to offer a guaranteed
> >> ABI. While we don't want to be changing it at a whim there shouldn
On Thu, 12 Sep 2019 at 11:07, Alex Bennée wrote:
> Peter Maydell writes:
> > Wait, what? From my perspective the whole point of the plugin
> > interface is that it should be stable, in that at least there's
> > a good chance that a plugin you built will work against multiple
> > versions of QEMU,
On Sun, Sep 08, 2019 at 11:22:00PM +0200, Kővágó, Zoltán wrote:
> Hi,
>
> This is the v2 of my patch series that makes mixeng optional and enables
> more than two audio channels.
>
> Changes from v1:
>
> * renamed "mixeng" option to "mixing-engine"
> * dropped patch "audio: remove hw->samples, b
* Yury Kotov (yury-ko...@yandex-team.ru) wrote:
> Hi,
> V2:
> * Remove x- prefix from capability name
> * Fix expected status checking
> * Fix description of capability
>
> This series adds an UUID validation at the start of the migration
> on the target side. The idea is to identify the source o
* Peter Xu (pet...@redhat.com) wrote:
> We've got max-postcopy-bandwidth parameter but it's not applied
> correctly after a postcopy recovery so the recovered migration stream
> will still eat the whole net bandwidth. Fix that up.
>
> Reported-by: Xiaohui Li
> Signed-off-by: Peter Xu
Queued
>
On Thu, 12 Sep 2019 at 11:17, Daniel P. Berrangé wrote:
> I think forcing recompile for each release is reasonable protection
> to make it less atttractive to create license violating closed source
> plugins.
I'm just not sure that a plugin that, for instance, does
"whenever the guest makes a mem
On Thu, Sep 12, 2019 at 11:54:00AM +0200, Cédric Le Goater wrote:
> On 12/09/2019 11:30, Balamuruhan S wrote:
> > Hi All,
> >
> > This is follow-up patch that implements HOMER and OCC SRAM device
> > models to emulate homer memory and occ common area access for pstate
> > table, occ sensors, runti
* Wei Yang (richard.weiy...@gmail.com) wrote:
> Two cleanup:
>
> Patch #1 make code consistent on calling add_to_iovec
> Patch #2 refine the code to handle the case when buf already flushed
Queued
> v2:
> * wrap common steps into add_buf_to_iovec()
>
> Wei Yang (2):
> migration/qemu-file: r
* Wei Yang (richardw.y...@linux.intel.com) wrote:
> Signed-off-by: Wei Yang
Queued
> ---
> migration/migration.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/migration/migration.c b/migration/migration.c
> index fbdabd34d9..cae3e894ad 100644
> --- a/migration/migrat
On Fri, Aug 30, 2019 at 03:44:45PM -0300, Eduardo Habkost wrote:
> On Fri, Aug 30, 2019 at 10:30:56AM +0100, Stefan Hajnoczi wrote:
> > Neither stat(2) nor lseek(2) report the size of Linux devdax pmem
> > character device nodes. Commit 314aec4a6e06844937f1677f6cba21981005f389
> > ("hostmem-file:
Patchew URL:
https://patchew.org/QEMU/20190912060701.4642-1-ys...@users.sourceforge.jp/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PATCH v24 00/22] Add RX archtecture support
Message-id: 20190912060701.4642-1-ys...@u
Am 12.09.2019 um 12:13 hat Sergio Lopez geschrieben:
>
> Kevin Wolf writes:
>
> > Am 11.09.2019 um 18:15 hat Sergio Lopez geschrieben:
> >> On creation, the export's AioContext is set to the same one as the
> >> BlockBackend, while the AioContext in the client QIOChannel is left
> >> untouched.
P.S. Looks like I can use --disable-docs to hopefully get around the
json parsing error, but that still doesn't help with the gluster error
or that something is still looking the .so given --disable-glusterfs.
--
You received this bug notification because you are a member of qemu-
devel-ml, which
Bisection is not going well at all with this code base!
Before your last reply, I started, and the first between 4.0.0 and 4.1.0
is aae6500972 which fails compilation:
==
...
CC stubs/pci-host-piix.o
CC stubs/ram-block.o
CC stubs/ramfb.o
CC stubs/fw_cfg.o
CC
Kevin Wolf writes:
> Am 11.09.2019 um 23:33 hat Eric Blake geschrieben:
>> On 9/11/19 12:21 PM, Eric Blake wrote:
>> > On 9/11/19 11:15 AM, Sergio Lopez wrote:
>> >> On creation, the export's AioContext is set to the same one as the
>> >> BlockBackend, while the AioContext in the client QIOChann
Am 11.09.2019 um 13:00 hat Max Reitz geschrieben:
> On 11.09.19 12:31, Kevin Wolf wrote:
> > Am 11.09.2019 um 12:00 hat Max Reitz geschrieben:
> >> So all in all I think it’s best to make the callback mandatory and add
> >> two global helper functions. That’s simple enough and should prevent
> >>
Peter Maydell writes:
> On Thu, 12 Sep 2019 at 11:07, Alex Bennée wrote:
>> Peter Maydell writes:
>> > Wait, what? From my perspective the whole point of the plugin
>> > interface is that it should be stable, in that at least there's
>> > a good chance that a plugin you built will work agains
Peter Maydell writes:
> The set_swi_errno() function is called to capture the errno
> from a host system call, so that we can return -1 from the
> semihosting function and later allow the guest to get a more
> specific error code with the SYS_ERRNO function. It comes in
> two versions, one for
hmm, disable-glusterfs *should* work around that; sometimes it's worth
nuking the build directory and trying a fresh configure with these
things.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1843151
Peter Maydell writes:
> If we fail a semihosting call we should always set the
> semihosting errno to something; we were failing to do
> this for some of the "check inputs for sanity" cases.
>
> Signed-off-by: Peter Maydell
Reviewed-by: Alex Bennée
although:
> ---
> target/arm/arm-semi.c
On Thu, 12 Sep 2019 at 11:40, Alex Bennée wrote:
>
>
> Peter Maydell writes:
>
> > The set_swi_errno() function is called to capture the errno
> > from a host system call, so that we can return -1 from the
> > semihosting function and later allow the guest to get a more
> > specific error code wi
On Thu, 12 Sep 2019 at 11:42, Alex Bennée wrote:
>
>
> Peter Maydell writes:
>
> > If we fail a semihosting call we should always set the
> > semihosting errno to something; we were failing to do
> > this for some of the "check inputs for sanity" cases.
> >
> > Signed-off-by: Peter Maydell
>
> R
Alex Bennée writes:
> The gdbstub should allow you do full introspection and adding
> additional registers is fairly easy, see mips_cpu_gdb_read_register function
> in target/mips/gdbstub.c.
Hi Alex and Aleksandar,
Now I can connect gdb to qemu successfully. And I can use this command to s
Peter Maydell writes:
> Currently the Arm semihosting code returns the guest file descriptors
> (handles) which are simply the fd values from the host OS or the
> remote gdbstub. Part of the semihosting 2.0 specification requires
> that we implement special handling of opening a ":semihosting-f
For AArch64 CPUs with a CBAR register, we have two views for it:
- in AArch64 state, the CBAR_EL1 register (S3_1_C15_C3_0), returns the
full 64 bits CBAR value
- in AArch32 state, the CBAR register (cp15, opc1=1, CRn=15, CRm=3, opc2=0)
returns a 32 bits view such that:
CBAR = CBAR
On creation, the export's AioContext is set to the same one as the
BlockBackend, while the AioContext in the client QIOChannel is left
untouched.
As a result, when using data-plane, nbd_client_receive_next_request()
schedules coroutines in the IOThread AioContext, while the client's
QIOChannel is
1 - 100 of 300 matches
Mail list logo
