On 06/25/2018 05:42 AM, Philippe Mathieu-Daudé wrote:
> It eases code review, unit is explicit.
>
> Patch generated using:
>
> $ git grep -E '(1024|2048|4096|8192|(<<|>>).?(10|20|30))' hw/ include/hw/
>
> and modified manually.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/nios2/boot
On 06/25/2018 05:42 AM, Philippe Mathieu-Daudé wrote:
> It eases code review, unit is explicit.
>
> Patch generated using:
>
> $ git grep -E '(1024|2048|4096|8192|(<<|>>).?(10|20|30))' hw/ include/hw/
>
> and modified manually.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/cris/axis_
On 06/25/2018 05:42 AM, Philippe Mathieu-Daudé wrote:
> It eases code review, unit is explicit.
>
> Patch generated using:
>
> $ git grep -E '(1024|2048|4096|8192|(<<|>>).?(10|20|30))' hw/ include/hw/
>
> and modified manually.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/sh4/r2d.c
On Tue, Jun 26, 2018 at 11:49 PM, Samudrala, Sridhar
wrote:
> On 6/26/2018 11:21 PM, Siwei Liu wrote:
>>
>> On Tue, Jun 26, 2018 at 5:29 PM, Michael S. Tsirkin
>> wrote:
>>>
>>> On Tue, Jun 26, 2018 at 04:38:26PM -0700, Siwei Liu wrote:
On Mon, Jun 25, 2018 at 6:50 PM, Michael S. Tsirki
On 06/25/2018 05:42 AM, Philippe Mathieu-Daudé wrote:
> -#define VSCARD_IN_SIZE 65536
> +#define VSCARD_IN_SIZE (64 * KiB)
>
> /* maximum size of ATR - from 7816-3 */
> #define MAX_ATR_SIZE40
> @@ -276,7 +277,7 @@ static void ccid_card_vscard_read(void *opaque, const
> uint8_t *bu
On 06/25/2018 05:42 AM, Philippe Mathieu-Daudé wrote:
> It eases code review, unit is explicit.
>
> Patch generated using:
>
> $ git grep -E '(1024|2048|4096|8192|(<<|>>).?(10|20|30))' hw/ include/hw/
>
> and modified manually.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/sd/sd.c
On Tue, Jun 26, 2018 at 9:06 PM, Michael S. Tsirkin wrote:
> On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
>> The patch set "Enable virtio_net to act as a standby for a passthru
>> device" [1] deals with live migration of guests that use passthrough
>> devices. However, that sche
On 27.06.2018 08:51, Gerd Hoffmann wrote:
>>> Signed-off-by: Martin Schrodt
>>> Signed-off-by: Gerd Hoffmann
>>> Message-id: 20180622111200.30561-2-kra...@redhat.com
>>> Message-id: 20171015184033.2951-3-mar...@schrodt.org
>>>
>>> [ kraxel: keep old code for compatibility with older qemu versions
On 06/25/2018 05:42 AM, Philippe Mathieu-Daudé wrote:
> It eases code review, unit is explicit.
>
> Patch generated using:
>
> $ git grep -E '(1024|2048|4096|8192|(<<|>>).?(10|20|30))' hw/ include/hw/
>
> and modified manually.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/vfio/pci-q
On Wed, Jun 27, 2018 at 11:38:17AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2018-06-27 at 03:35 +0300, Michael S. Tsirkin wrote:
> >
> > > +
> > > +/* Extract field fname from val */
> > > +#define GETFIELD(fname, val)\
> > > +(((val) & fname##_MASK) >> fname##_LS
Signed-off-by: Steffen Görtz
---
hw/arm/nrf51_soc.c | 18 +-
include/hw/arm/nrf51_soc.h | 4 +++-
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/hw/arm/nrf51_soc.c b/hw/arm/nrf51_soc.c
index 1f7c159edf..175a009e65 100644
--- a/hw/arm/nrf51_soc.c
+++ b/hw/
This is a series of changes to the NRF51 SOC and the microbit board.
The changes can not be posted as patches as the nrf51 is not mergable
yet due to missing cortex-m0/armv6 support.
"arm: Add NRF51 random number generator peripheral" was already
posted to devel and is being discussed in
<2018062
The base address determines a peripherals id, which identifies its
interrupt line, see NRF51 reference manual section 10 peripheral
interface. This little gem calculates the peripheral id based
on its base address.
Signed-off-by: Steffen Görtz
---
hw/arm/nrf51_soc.c | 12
1 file cha
Signed-off-by: Steffen Görtz
---
hw/arm/microbit.c | 8 ++--
hw/arm/nrf51_soc.c | 98 +++---
include/hw/arm/nrf51_soc.h | 24 --
3 files changed, 95 insertions(+), 35 deletions(-)
diff --git a/hw/arm/microbit.c b/hw/arm/microbit.c
index b
Changes since V1:
- Code style changes
Signed-off-by: Steffen Görtz
---
hw/nvram/Makefile.objs| 1 +
hw/nvram/nrf51_nvmc.c | 168 ++
include/hw/nvram/nrf51_nvmc.h | 51 +++
3 files changed, 220 insertions(+)
create mode 100644 hw/nvram/
Add a model of the NRF51 random number generator peripheral.
Changes since v2:
- Add missing 'qapi/error.h' for error_abort
Changes since v1:
- Add implementation access size hints to MemoryRegionOps
- Fail on error if qcrypto_random_bytes fails
- Add references to Nrf51 datasheets
Signe
Signed-off-by: Steffen Görtz
---
hw/arm/nrf51_soc.c | 30 ++
hw/char/nrf51_uart.c | 10 ++
include/hw/char/nrf51_uart.h | 26 --
3 files changed, 36 insertions(+), 30 deletions(-)
diff --git a/hw/arm/nrf51_soc.c b/hw/a
Signed-off-by: Steffen Görtz
---
hw/arm/nrf51_soc.c | 50 +++---
include/hw/arm/nrf51_soc.h | 3 ++-
2 files changed, 32 insertions(+), 21 deletions(-)
diff --git a/hw/arm/nrf51_soc.c b/hw/arm/nrf51_soc.c
index 82e4c2d833..9ff622b792 100644
--- a/hw/arm/n
Another lose end: event COMMAND_DROPPED seems to lack test coverage.
This patch maps preallocated user/factory information
configuration registers to the NRF51 SOC.
See NRF51 reference manual section 7 and 8.
Signed-off-by: Steffen Görtz
---
hw/arm/nrf51_soc.c | 174 ++---
include/hw/arm/nrf51_soc.h | 5 +-
2 files change
Markus Armbruster writes:
> I fooled around a bit, and I think there are a few lose ends.
[...]
> Talking to a QMP monitor that supports OOB:
>
> $ socat UNIX:test-qmp READLINE,history=$HOME/.qmp_history,prompt='QMP> '
> {"QMP": {"version": {"qemu": {"micro": 50, "minor": 12, "major": 2},
On 06/27/2018 09:28 AM, David Gibson wrote:
> On Wed, Jun 27, 2018 at 11:38:17AM +1000, Benjamin Herrenschmidt wrote:
>> On Wed, 2018-06-27 at 03:35 +0300, Michael S. Tsirkin wrote:
>>>
+
+/* Extract field fname from val */
+#define GETFIELD(fname, val)\
+
On Tue, 26 Jun 2018, Sebastian Bauer wrote:
Fetching qtd with the NULL address most likely makes no sense so from now
on, we handle it this case similarly as if the terminate (T) bit is not
set, which is already an exception as according to section 3.6 of the EHCI
spec there is no T bit defined f
Thomas Huth writes:
> On 27.06.2018 08:51, Gerd Hoffmann wrote:
[...]
>> Drop support for 32bit hosts in qemu?
>
> I guess the only way to answer that question reliably is to send a patch
> to mark 32-bit hosts as deprecated...
>
> Anyway, you still have got to fix that problem with -m32 now some
On 06/26/2018 05:40 PM, Paolo Bonzini wrote:
> Let management know if there were any problems communicating with
> qemu-pr-helper. The event is edge-triggered, and is sent every time
> the connection status of the pr-manager-helper object changes.
>
> Signed-off-by: Paolo Bonzini
> ---
> qapi/b
On 27.06.2018 09:57, Markus Armbruster wrote:
> Thomas Huth writes:
>
>> On 27.06.2018 08:51, Gerd Hoffmann wrote:
> [...]
>>> Drop support for 32bit hosts in qemu?
>>
>> I guess the only way to answer that question reliably is to send a patch
>> to mark 32-bit hosts as deprecated...
>>
>> Anyway
On Wed, 27 Jun 2018, Markus Armbruster wrote:
Thomas Huth writes:
On 27.06.2018 08:51, Gerd Hoffmann wrote:
[...]
Drop support for 32bit hosts in qemu?
I guess the only way to answer that question reliably is to send a patch
to mark 32-bit hosts as deprecated...
Anyway, you still have got
On Wed, 27 Jun 2018 07:06:42 +0300
"Michael S. Tsirkin" wrote:
> On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
> > The patch set "Enable virtio_net to act as a standby for a passthru
> > device" [1] deals with live migration of guests that use passthrough
> > devices. However, t
virtio-rng device causing old guest kernels(2.6.32) to hang on latest qemu.
The driver attempts to read from the virtio-rng device too early in it's
initialization. Qemu detects guest is not ready and returns, resulting in
hang. Below patches fix this.
Stefan Hajnoczi(1):
virtio-rng: proces
To process pending requests for driver status 'VIRTIO_CONFIG_S_DRIVER_OK',
virtio-rng 'set_status' calls 'is_guest_ready' function. This checks if
virtqueue is ready and status is set to 'VIRTIO_CONFIG_S_DRIVER_OK'.
This call is made before new status is updated in VirtIODevice parent object
virtio-rng device causing old guest kernels(2.6.32) to hang on latest qemu.
The driver attempts to read from the virtio-rng device too early in it's
initialization. Qemu detects guest is not ready and returns, resulting in
hang.
Fix is to handle pending request when guest is running and drive
Stefan Hajnoczi wrote:
> Only one existing trace event uses a floating point type. Unfortunately
> float and double cannot be supported since SystemTap does not have
> floating point types.
>
> Remove float and double from the whitelist and document this limitation.
> Update the migrate_transferr
On 26/06/2018 22:29, Auger Eric wrote:
>>
>> Fixes: 48564041a73a (exec: reintroduce MemoryRegion caching)
>> Signed-off-by: Eric Auger
> gentle reminder, just to make sure someone is going to pick up this
> patch before the freeze ;-) Or please let me know if I miss some concerns.
Yes, it's alrea
Hi Paolo,
On 06/27/2018 10:26 AM, Paolo Bonzini wrote:
> On 26/06/2018 22:29, Auger Eric wrote:
>>>
>>> Fixes: 48564041a73a (exec: reintroduce MemoryRegion caching)
>>> Signed-off-by: Eric Auger
>> gentle reminder, just to make sure someone is going to pick up this
>> patch before the freeze ;-)
Markus Armbruster writes:
> Another lose end: event COMMAND_DROPPED seems to lack test coverage.
Hmm, dropping commands serves to limit the request queue. What limits
the response queue?
Before OOB, the monitor read at most one command, and wrote its response
with monitor_puts().
For input, t
On 26/06/2018 18:06, Eduardo Habkost wrote:
>> On the other hand I see no benefit in changing a default that people are
>> obviously not using (since most people use KVM, not TCG). Distros will
>> keep shipping, and people will keep using qemu-kvm even if we change the
>> default.
>
> Not changing
On Wed, 2018-06-27 at 09:46 +0200, Cédric Le Goater wrote:
> So the "IBM PHB3 PCIE Root Port" is already user createable.
>
> I can take a look at user createable PHB3s. I think this is OK from a model
> perspective. The object is rather standalone, it needs the machine for
> the XICS fabric and
Markus Armbruster writes:
> Markus Armbruster writes:
>
>> I fooled around a bit, and I think there are a few lose ends.
> [...]
>> Talking to a QMP monitor that supports OOB:
>>
>> $ socat UNIX:test-qmp READLINE,history=$HOME/.qmp_history,prompt='QMP> '
>> {"QMP": {"version": {"qemu": {
On 26/06/2018 18:43, Markus Armbruster wrote:
>>> Not sure how serious you meant that, but I actually quite like the
>>> idea :)
>> Also, this mode could be enabled by default if stderr is a tty.
> It could be enabled by default, period.
I agree, summarizing the configuration to stderr on startup
Hi,
> > Is QEMU still useful on 32-bit hosts? Honest question!
>
> I guess it depends on what 32-bit hosts you consider. If you look at only
> x86 vs. x86_64 then probably x86 is not that important any more but for some
> embedded systems/SoCs 32bit might still be common and QEMU useful for th
Hi,
> > "Compiles on host X" is also a need, but it's a different one.
> > Evidence: "Supported build platforms" has its own appendix, separate
> > from "Deprecated features". It's mum on 32-bit hosts.
>
> Theoretically I'd agree, but actually it's more than that: If we drop
> support for 32-b
On Tue, Jun 26, 2018 at 12:49:43PM +0200, Steffen Görtz wrote:
> Add a model of the NRF51 random number generator peripheral.
>
> Changes since v1:
> - Add implementation access size hints to MemoryRegionOps
> - Fail on error if qcrypto_random_bytes fails
> - Add references to Nrf51 datashee
David Hildenbrand wrote:
> Not needed. Don't expose last_ram_page().
>
> Signed-off-by: David Hildenbrand
> ---
> include/exec/ram_addr.h | 1 -
> migration/postcopy-ram.c | 4 ++--
> migration/postcopy-ram.h | 2 +-
> migration/ram.c | 4 +---
> 4 files changed, 4 insertions(+), 7 del
David Hildenbrand wrote:
> Not needed. Don't expose last_ram_page().
>
> Signed-off-by: David Hildenbrand
> ---
>
> v1 -> v2:
> - Make "last_ram_page" static
And there was already an v2 of the patch ...
Reviewed-by: Juan Quintela
** Changed in: qemu (Ubuntu)
Status: Confirmed => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1129571
Title:
libreoffice armhf FTBFS
Status in QEMU:
Won't Fix
Status in qemu
Peter Xu wrote:
> Before this patch we firstly setup the postcopy-paused state then we
> clean up the QEMUFile handles. That can be racy if there is a very fast
> "migrate-recover" command running in parallel. Fix that up.
>
> Reported-by: Peter Maydell
> Signed-off-by: Peter Xu
Reviewed-by:
On 27.06.2018 10:52, Gerd Hoffmann wrote:
> Hi,
>
>>> Is QEMU still useful on 32-bit hosts? Honest question!
>>
>> I guess it depends on what 32-bit hosts you consider. If you look at only
>> x86 vs. x86_64 then probably x86 is not that important any more but for some
>> embedded systems/SoCs 3
On Tue, 26 Jun 2018 20:50:20 +0300
"Michael S. Tsirkin" wrote:
> On Tue, Jun 26, 2018 at 05:08:13PM +0200, Cornelia Huck wrote:
> > On Fri, 22 Jun 2018 17:05:04 -0700
> > Siwei Liu wrote:
> >
> > > On Fri, Jun 22, 2018 at 3:33 PM, Michael S. Tsirkin
> > > wrote:
> > > > I suspect the dive
Clearing old bugs: No more occurring in any of my recent KVMs, setting
this old bug to incomplete.
** Changed in: qemu-kvm (Ubuntu)
Status: Confirmed => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.l
* Juan Quintela (quint...@redhat.com) wrote:
> We used to include in this calculation the setup time, but that can be
> quite big in rdma or multifd.
>
> Signed-off-by: Juan Quintela
Reviewed-by: Dr. David Alan Gilbert
> ---
> migration/migration.c | 6 --
> 1 file changed, 4 insertions(+
On 29/05/2018 12:19, Alexandro Sanchez Bach wrote:
> The function `gen_sse` assumes all of its instructions require CR0.TS=0.
> However, integer extensions at `0F 38 F[0-F]` and `0F 3A F[0-F]` such as
> CRC32, MOVBE, ADX, BMI1, BMI2 that are handled by `gen_sse` are not supposed
> to throw an excep
On Tue, Jun 26, 2018 at 09:19:09AM -0700, Richard Henderson wrote:
> This allows faults from MO_ALIGN to have the same effect
> as from gen_check_align.
>
> Signed-off-by: Richard Henderson
So, most powerpc cpus can handle most unaligned accesses without an
exception. I'm assuming this series w
On 17/05/2018 18:23, Viktor Prutyanov wrote:
> Recently a Windows guest driver has been added with the ability to
> publish the data needed to produce useful guest dumps on the
> hypervisor side. The data is wrapped in a standard VMCOREINFO
> container and is exposed to the hypervisor via FwCfg (s
On Tue, Jun 26, 2018 at 11:32:04AM +0200, Steffen Görtz wrote:
> Changes since V1:
> - Code style changes
Please put the changelog below '---'.
> diff --git a/hw/nvram/nrf51_nvmc.c b/hw/nvram/nrf51_nvmc.c
> new file mode 100644
> index 00..5dde3088a8
> --- /dev/null
> +++ b/hw/nvram/nrf51
On Wed, Jun 27, 2018 at 09:33:43AM +0200, Steffen Görtz wrote:
> This is a series of changes to the NRF51 SOC and the microbit board.
> The changes can not be posted as patches as the nrf51 is not mergable
> yet due to missing cortex-m0/armv6 support.
>
> "arm: Add NRF51 random number generator pe
* Juan Quintela (quint...@redhat.com) wrote:
> Right now we use the "position" inside the QEMUFile, but things like
> RDMA already do weird things to be able to maintain that counter
> right, and multifd will have some similar problems.
>
> Signed-off-by: Juan Quintela
Reviewed-by: Dr. David Ala
On Wed, Jun 27, 2018 at 09:33:44AM +0200, Steffen Görtz wrote:
This looks like code that can be squashed into to Joel's 'microbit'
machine type series. Please agree with Joel how to include this in his
upcoming v2 patch series.
There are several things going on here and the patch could be split
Peter Xu wrote:
> It was broken due to recent changes in two parts:
>
> - migration_incoming_process() will be called now even for postcopy
> recovery sessions (while we shouldn't)
>
> - Now we don't call migrate_fd_process_incoming() any more (unless in
> RDMA code), so actually the postcopy
On Wed, Jun 27, 2018 at 09:33:49AM +0200, Steffen Görtz wrote:
> This patch maps preallocated user/factory information
> configuration registers to the NRF51 SOC.
> See NRF51 reference manual section 7 and 8.
>
> Signed-off-by: Steffen Görtz
> ---
> hw/arm/nrf51_soc.c | 174 +
* Juan Quintela (quint...@redhat.com) wrote:
> This will include how many bytes they are sent through multifd.
>
> Signed-off-by: Juan Quintela
Reviewed-by: Dr. David Alan Gilbert
> ---
> hmp.c | 2 ++
> migration/migration.c | 1 +
> qapi/migration.json | 5 -
> 3 files
On 26/06/2018 16:18, Emanuele Giuseppe Esposito wrote:
> server->bus in _test_server_free() could be NULL, since TestServer *dest in
> test_migrate() was not properly initialized like TestServer *s.
> Added init_virtio_dev(dest) and uninit_virtio_dev(dest), so the fields are
> properly set and wh
On Thu, Jun 21, 2018 at 04:02:54PM +0100, Stefan Hajnoczi wrote:
> Only one existing trace event uses a floating point type. Unfortunately
> float and double cannot be supported since SystemTap does not have
> floating point types.
>
> Remove float and double from the whitelist and document this
On Sat, 23 Jun 2018 00:43:24 +0300
"Michael S. Tsirkin" wrote:
> On Fri, Jun 22, 2018 at 05:09:55PM +0200, Cornelia Huck wrote:
> > Would it be more helpful to focus on generic
> > migration support for vfio instead of going about it device by device?
>
> Just to note this approach is actually
This patch introduces a new Arm machine type 'SBSA' with features:
- Based on legacy 'virt' machine type.
- Newly designed memory map.
- EL2 and EL3 are enabled by default.
- AHCI controller attached to system bus, and then CDROM and hard disc
can be added to it.
- EHCI controller attached
On 06/26/2018 05:40 PM, Paolo Bonzini wrote:
> Let management know if there were any problems communicating with
> qemu-pr-helper. The event is edge-triggered, and is sent every time
> the connection status of the pr-manager-helper object changes.
>
> Signed-off-by: Paolo Bonzini
> ---
> qapi/b
On 22.05.2018 10:30, Thomas Huth wrote:
> Peter reported that the boot-serial tester sometimes runs into timeouts
> with SPARC guests. It's currently completely unclear whether this is due
> to too much load on the host machine (so that the guest really just ran
> too slow), or whether there is som
On Wed, Jun 27, 2018 at 10:41:38AM +0200, Markus Armbruster wrote:
> Markus Armbruster writes:
>
> > Markus Armbruster writes:
> >
> >> I fooled around a bit, and I think there are a few lose ends.
> > [...]
> >> Talking to a QMP monitor that supports OOB:
> >>
> >> $ socat UNIX:test-qmp REA
On Wed, Jun 27, 2018 at 01:52:48PM +0530, Pankaj Gupta wrote:
> To process pending requests for driver status 'VIRTIO_CONFIG_S_DRIVER_OK',
> virtio-rng 'set_status' calls 'is_guest_ready' function. This checks if
> virtqueue is ready and status is set to 'VIRTIO_CONFIG_S_DRIVER_OK'.
>
> This
On Tue, 2018-06-26 at 19:02 +0200, Cédric Le Goater wrote:
> On 06/26/2018 05:57 PM, Andrea Bolognani wrote:
> > On Tue, 2018-06-26 at 15:59 +0200, Cédric Le Goater wrote:
> > > This is a model of the PCIe host bridge found on Power8 chips,
> > > including PowerBus logic interface, IOMMU support, P
On Wed, Jun 27, 2018 at 11:57:55AM +0200, Juan Quintela wrote:
> Peter Xu wrote:
> > It was broken due to recent changes in two parts:
> >
> > - migration_incoming_process() will be called now even for postcopy
> > recovery sessions (while we shouldn't)
> >
> > - Now we don't call migrate_fd_pro
On Wed, Jun 27, 2018 at 11:57:50AM +0800, Fam Zheng wrote:
>
>
> Fam Zheng (2):
> qcow2: Remove dead check on !ret
> block: Move request tracking to children in copy offloading
>
> block/io.c| 59 ---
> block/qcow2.c | 2 +-
> 2 files cha
Hi, I found a bug that disk missing (not all disks missing ) in the
guest contingently when hotplug several virtio scsi disks
consecutively. After rebooting the guest,
the missing disks appear again.
The guest is centos7.3 running on a centos7.3 host and the scsi
controllers are configed wit
On Wed, 2018-06-27 at 18:41 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2018-06-27 at 09:46 +0200, Cédric Le Goater wrote:
> > So the "IBM PHB3 PCIE Root Port" is already user createable.
> >
> > I can take a look at user createable PHB3s. I think this is OK from a model
> > perspective. The ob
* Juan Quintela (quint...@redhat.com) wrote:
> We know quit with shutdwon in the QIO.
>
> Signed-off-by: Juan Quintela
Reviewed-by: Dr. David Alan Gilbert
> --
> Add comment
> Use shutdown() instead of unref()
> ---
> migration/ram.c | 14 +-
> 1 file changed, 5 insertions(+), 9 d
On 27 June 2018 at 09:52, Gerd Hoffmann wrote:
> Hi,
>
>> > Is QEMU still useful on 32-bit hosts? Honest question!
>>
>> I guess it depends on what 32-bit hosts you consider. If you look at only
>> x86 vs. x86_64 then probably x86 is not that important any more but for some
>> embedded systems/
RDMA does not support postcopy recovery, so no need to go into such
logic. Instead of calling migration_fd_process_incoming(), let's call
the two functions that setup the incoming migration. There should have
no functional change at all.
Signed-off-by: Peter Xu
---
migration/rdma.c | 3 ++-
1
v2:
- break the first patch into several
- fix a QEMUFile leak
Please review. Thanks,
Peter Xu (5):
migration: delay postcopy paused state
migration: move income process out of multifd
migration: do explicit incoming setup for rdma
migration: unbreak postcopy recovery
migration: unify
Before this patch we firstly setup the postcopy-paused state then we
clean up the QEMUFile handles. That can be racy if there is a very fast
"migrate-recover" command running in parallel. Fix that up.
Reported-by: Peter Maydell
Reviewed-by: Juan Quintela
Signed-off-by: Peter Xu
---
migration
This is the 2nd patch to unbreak postcopy recovery.
Let's unify the migration_incoming_process() call at a single place
rather than calling it in connection setup codes. This fixes a problem
that we will go into incoming migration procedure even if we are trying
to recovery from a paused postcopy
Move the call to migration_incoming_process() out of multifd code. It's
a bit strange that we can migration generic calls in multifd code.
Instead, let multifd_recv_new_channel() return a boolean showing whether
it's ready to continue the incoming migration.
Signed-off-by: Peter Xu
---
migratio
The whole postcopy recovery logic was accidentally broken. We need to
fix it in two steps.
This is the first step that we should do the recovery when needed. It
was bypassed before after commit 36c2f8be2c.
Since at it, rename the function migration_fd_process_incoming() into
postcopy_try_recove
>
> On Wed, Jun 27, 2018 at 01:52:48PM +0530, Pankaj Gupta wrote:
> > To process pending requests for driver status 'VIRTIO_CONFIG_S_DRIVER_OK',
> > virtio-rng 'set_status' calls 'is_guest_ready' function. This checks if
> > virtqueue is ready and status is set to 'VIRTIO_CONFIG_S_DRIVER_OK'.
Thomas Huth writes:
> On 27.06.2018 09:57, Markus Armbruster wrote:
>> Thomas Huth writes:
>>
>>> On 27.06.2018 08:51, Gerd Hoffmann wrote:
>> [...]
Drop support for 32bit hosts in qemu?
>>>
>>> I guess the only way to answer that question reliably is to send a patch
>>> to mark 32-bit ho
* Peter Maydell (peter.mayd...@linaro.org) wrote:
> On 27 June 2018 at 09:52, Gerd Hoffmann wrote:
> > Hi,
> >
> >> > Is QEMU still useful on 32-bit hosts? Honest question!
> >>
> >> I guess it depends on what 32-bit hosts you consider. If you look at only
> >> x86 vs. x86_64 then probably x86
On 27.06.2018 13:08, Alex Bennée wrote:
>
> Thomas Huth writes:
>
>> On 27.06.2018 09:57, Markus Armbruster wrote:
>>> Thomas Huth writes:
>>>
On 27.06.2018 08:51, Gerd Hoffmann wrote:
>>> [...]
> Drop support for 32bit hosts in qemu?
I guess the only way to answer that quest
On Wed, Jun 27, 2018 at 09:57:09AM +0200, Markus Armbruster wrote:
> Thomas Huth writes:
>
> > On 27.06.2018 08:51, Gerd Hoffmann wrote:
> [...]
> >> Drop support for 32bit hosts in qemu?
> >
> > I guess the only way to answer that question reliably is to send a patch
> > to mark 32-bit hosts as
Hi,
> Given the code runs under big qemu lock anyway the atomics are not
> needed, so we could drop just them. I left them in nevertheless because
>
> (a) we might want try run the code in a thread instead of using a timer, and
> (b) I was too lazy to rewrite the code to drop the atomics.
On 25.06.2018 13:53, David Hildenbrand wrote:
> Let's stop the timer and delete any pending CKC IRQ before doing
> anything else.
>
> While at it, add a comment while the check for ckc == -1ULL is needed.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/misc_helper.c | 7 +++
> 1 f
On 25.06.2018 13:53, David Hildenbrand wrote:
> This allows a guest to change its TOD. We already take care of updating
> all CKC timers from within S390TODClass.
>
> Use MO_ALIGN to load the operand manually - this will properly trigger a
> SPECIFICATION exception.
>
> Signed-off-by: David Hilde
Signed-off-by: Gerd Hoffmann
---
hw/audio/hda-codec.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/audio/hda-codec.c b/hw/audio/hda-codec.c
index fc4945086b..8a8214de74 100644
--- a/hw/audio/hda-codec.c
+++ b/hw/audio/hda-codec.c
@@ -204,6 +204,9 @@ static inline void hda_timer_sync_
Doesn't build on 32bit clang. And because we run under qemu mutex
anyway they are not needed.
Signed-off-by: Gerd Hoffmann
---
hw/audio/hda-codec.c | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/hw/audio/hda-codec.c b/hw/audio/hda-codec.c
i
On 25.06.2018 13:53, David Hildenbrand wrote:
> run_on_cpu() doesn't seem to work reliably until the CPU has been fully
> created if the single-threaded TCG main loop is already running.
>
> Therefore, hotplugging a CPU under single-threaded TCG does currently
> not work. We should use the direct
On Fri, 22 Jun 2018 16:40:45 +0200
David Hildenbrand wrote:
> Right now, there is some inconsistency between hotplugged and
> coldplugged memory. DIMMs added via "-device" result in different stats
> than DIMMs added using "device_add".
>
> E.g.
> [...]
> -numa node,nodeid=0,cpus=0-1 -nu
Daniel P. Berrangé writes:
> On Wed, Jun 27, 2018 at 10:41:38AM +0200, Markus Armbruster wrote:
>> Markus Armbruster writes:
>>
>> > Markus Armbruster writes:
>> >
>> >> I fooled around a bit, and I think there are a few lose ends.
>> > [...]
>> >> Talking to a QMP monitor that supports OOB:
>
virtio-rng device causing old guest kernels(2.6.32) to hang on latest qemu.
The driver attempts to read from the virtio-rng device too early in it's
initialization. Qemu detects guest is not ready and returns, resulting in
hang.
Fix is to handle pending request when guest is running and drive
On Mon, 25 Jun 2018 09:42:04 -0300
Philippe Mathieu-Daudé wrote:
> It eases code review, unit is explicit.
>
> Patch generated using:
>
> $ git grep -E '(1024|2048|4096|8192|(<<|>>).?(10|20|30))' hw/ include/hw/
>
> and modified manually.
>
> Signed-off-by: Philippe Mathieu-Daudé
> Reviewe
Support of IA32_PRED_CMD MSR already be enumerated by same CPUID bit as
SPEC_CTRL.
Signed-off-by: Robert Hoo
---
target/i386/cpu.c | 2 +-
target/i386/cpu.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index e6c2f8a..953098c 100644
--
WBNOINVD: Write back and do not invalidate cache, enumerated by
CPUID.(EAX=8008H, ECX=0):EBX[bit 9].
Signed-off-by: Robert Hoo
---
target/i386/cpu.c | 2 +-
target/i386/cpu.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index c2c3
On Wed, Jun 27, 2018 at 04:55:20PM +0530, Pankaj Gupta wrote:
> virtio-rng device causing old guest kernels(2.6.32) to hang on latest qemu.
> The driver attempts to read from the virtio-rng device too early in it's
> initialization. Qemu detects guest is not ready and returns, resulting in
> ha
IA32_PRED_CMD MSR gives software a way to issue commands that affect the state
of indirect branch predictors. Enumerated by CPUID.(EAX=7H,ECX=0):EDX[26].
IA32_ARCH_CAPABILITIES MSR enumerates architectural features of RDCL_NO and
IBRS_ALL. Enumerated by CPUID.(EAX=07H, ECX=0):EDX[29].
https://soft
1 - 100 of 481 matches
Mail list logo
