On Fri, Jul 18, 2014 at 10:15 AM, Slava Pestov
wrote:
> Public bug reported:
>
> If the list of requests passed to multiwrite_merge() contains two
> requests where the first is for a range of sectors that is a strict
> subset of the second's, the second request is truncated to end where the
> firs
Peter Maydell wrote:
> On 25 July 2014 15:22, Paolo Bonzini wrote:
>> Since Igor hasn't sent his patches, and I'm leaving the office, I pushed
>> this to
>>
>>git://github.com/bonzini/qemu.git tags/for-upstream-full
>>
>> I don't know about tests/acpi-test-data/pc. It makes sense that this
>
Il 28/07/2014 13:39, Sebastian Tanase ha scritto:
> When trying to print data to the pty, we first check if it is connected.
> If not, we try to reconnect, but we drop the pending data even if we
> have successfully reconnected; this makes us lose the first byte of the very
> first transmission.
>
On 16.07.14 03:40, Gavin Shan wrote:
On Wed, Jul 16, 2014 at 11:32:13AM +1000, Alexey Kardashevskiy wrote:
On 07/16/2014 11:16 AM, Gavin Shan wrote:
On Wed, Jul 16, 2014 at 11:09:44AM +1000, Alexey Kardashevskiy wrote:
On 07/16/2014 10:20 AM, Gavin Shan wrote:
This updates kernel header (vfi
On 16.07.14 02:20, Gavin Shan wrote:
From: Alexey Kardashevskiy
This makes find_phb()/find_dev() public and changed its names
to spapr_pci_find_phb()/spapr_pci_find_dev() as they are going to
be used from other parts of QEMU such as VFIO DDW (dynamic DMA window)
or VFIO PCI error injection or
Il 28/07/2014 13:45, Michael S. Tsirkin ha scritto:
>> +/* These are used to size the ACPI tables for -M pc-i440fx-1.7 and
>> + * -M pc-i440fx-2.0.
>
> Let's just say 2.0 and earlier?
This would give the idea that 1.6 is broken, but it isn't.
>> Even if the actual amount of AML generated grows
Hi,
As it was posted earlier the output of reading /proc/self/maps is not
correct for a guest. There are some issues:
https://bugs.launchpad.net/qemu/+bug/1346784
http://lists.nongnu.org/archive/html/qemu-devel/2014-07/msg03085.html
http://lists.nongnu.org/archive/html/qemu-devel/2014-07/msg0279
On Thu, Jul 24, 2014 at 04:32:09PM +0200, Paolo Bonzini wrote:
> Changing the ACPI table size causes migration to break, and the memory
> hotplug work opened our eyes on how horribly we were breaking things in
> 2.0 already.
>
> The ACPI table size is rounded to the next 4k, which one would think
When trying to print data to the pty, we first check if it is connected.
If not, we try to reconnect, but we drop the pending data even if we
have successfully reconnected; this makes us lose the first byte of the very
first transmission.
This small fix addresses the issue by checking once more if
MIPS registers an unassigned access handler which raises a guest bus
error exception. However this causes QEMU to crash when KVM is enabled
as it isn't called from the main execution loop so longjmp() gets called
without a corresponding setjmp().
Until the KVM API can be updated to trigger a guest
On 21.07.14 05:02, Alexey Kardashevskiy wrote:
At the moment RTAS and device tree are located at 256MB max
which leaves too little space for huge initramdisk images and kernels.
This relaxes the limitation.
This is checkpatch.pl'ed version of:
[PATCH 1/2] loader: Add load_image_size() to replac
On 21.07.14 05:15, Alexey Kardashevskiy wrote:
On 07/03/2014 01:10 PM, Alexey Kardashevskiy wrote:
c4177479 "spapr: make sure RMA is in first mode of first memory node"
introduced regression which prevents from running guests with memoryless
NUMA node#0 which may happen on real POWER8 boxes and
On 25.07.14 08:52, arei.gong...@huawei.com wrote:
From: Gonglei
get_boot_devices_list() will malloc memory, spapr_finalize_fdt
doesn't free it.
Signed-off-by: Chenliang
Signed-off-by: Gonglei
Thanks, applied to ppc-next-2.2.
Alex
On 26 July 2014 08:18, Michael Tokarev wrote:
> There's just one trivial patch this time, fixing another
> occurence of "allows to" in help text. Please consider
> applying for 2.1.
>
> Thanks,
>
> /mjt
>
> The following changes since commit c60a57ff497667780132a3fcdc1500c83af5d5c0:
>
> Merge r
> -Original Message-
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Monday, July 28, 2014 6:02 PM
> Subject: Re: [PATCH v2 1/7] bootindex: add modify_boot_device_path function
>
> Hi,
>
> > > > > I think it is ok to allow only *changing* the bootindex.
> > > > >
> > > > Yes, t
El Fri, 25 Jul 2014 23:37:43 +0200
Marc Marí escribió:
> +
> +data = g_malloc0(512);
> +memread(r_req+16, data, 512);
> +g_assert_cmpstr(data, ==, "TEST");
> +g_free(data);
> +
guest_free() for both requests should be added here. Will be added for
v3
> +/* End test */
> +
Il 28/07/2014 09:50, Pavel Dovgaluk ha scritto:
>> - patches 2 to 13 probably should try to use subsections, so that VMs
>> that do not use the devices try not to save the extra data and keep
>> backwards migration compatibility (at least try to)
>
> Could you give me and example?
> As I know, s
Il 28/07/2014 11:54, Pavel Dovgaluk ha scritto:
>>> > > +VMSTATE_TIMER_V(timer, RTL8139State, 5),
>> >
>> > timer need not be migrated, because it is reinstated by rtl8139_post_load.
>> >
> That's true for normal execution.
> In replay execution mode post_load can be called before cac
Hi,
> > > > I think it is ok to allow only *changing* the bootindex.
> > > >
> > > Yes, that's no problem.
> >
> > But then yoy always will have a old entry where you can take the suffix
> > from, and you don't need the suffix as parameter for the monitor
> > command.
> >
> No, optional.
>
Il 17/07/2014 13:02, Pavel Dovgalyuk ha scritto:
> +.fields = (VMStateField []) {
> +VMSTATE_UINT8(state.dataw, ISAParallelState),
> +VMSTATE_UINT8(state.datar, ISAParallelState),
> +VMSTATE_UINT8(state.status, ISAParallelState),
> +VMSTATE_UINT8(state.contr
On 28 July 2014 10:49, Stefan Hajnoczi wrote:
> On Mon, Jul 28, 2014 at 06:03:45AM +, Gonglei (Arei) wrote:
>> Hi,
>>
>> Should be easy to fix though. Does the following help?
>>
>> (Cc'ing Stefan & Kevin)
>>
>> -->
>> xen_disk: fix possible null-ptr dereference
>>
>> Signed-off-by: Gonglei
Il 17/07/2014 13:02, Pavel Dovgalyuk ha scritto:
> -.version_id = 3,
> +.version_id = 4,
> .minimum_version_id = 2,
> .pre_save = serial_pre_save,
> .post_load = serial_post_load,
> .fields = (VMStateField[]) {
> VMSTATE_UINT16_V(divider, SerialState, 2),
>
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Il 17/07/2014 13:02, Pavel Dovgalyuk ha scritto:
> > This patch adds virtual clock-dependent timers to VMState to allow correct
> > saving and restoring the state of RTL8139 network controller.
> >
> > Signed-off
> -Original Message-
> From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> Sent: Monday, July 28, 2014 5:49 PM
> To: Gonglei (Arei)
> Cc: mateusz.krzywi...@windowslive.com; qemu-devel@nongnu.org;
> kw...@redhat.com
> Subject: Re: [Qemu-devel] Possible null-ptr dereference
>
> On Mon, Jul
On Mon, Jul 28, 2014 at 06:03:45AM +, Gonglei (Arei) wrote:
> Hi,
>
> Should be easy to fix though. Does the following help?
>
> (Cc'ing Stefan & Kevin)
>
> -->
> xen_disk: fix possible null-ptr dereference
>
> Signed-off-by: Gonglei
> ---
> hw/block/xen_disk.c | 1 +
> 1 file changed, 1 i
Il 17/07/2014 13:02, Pavel Dovgalyuk ha scritto:
> VMState added by this patch preserves correct
> loading of the FDC device state.
>
> Signed-off-by: Pavel Dovgalyuk
> ---
> hw/block/fdc.c | 11 +--
> 1 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/hw/block/fdc.c b/
Il 17/07/2014 13:03, Pavel Dovgalyuk ha scritto:
> This patch adds irq_reinject_on_ack_count field to VMState to allow correct
> saving/loading the state of MC146818 RTC.
>
> Signed-off-by: Pavel Dovgalyuk
> ---
> hw/timer/mc146818rtc.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions
Il 17/07/2014 13:02, Pavel Dovgalyuk ha scritto:
> This patch adds virtual clock-dependent timers to VMState to allow correct
> saving and restoring the state of RTL8139 network controller.
>
> Signed-off-by: Pavel Dovgalyuk
> ---
> hw/net/rtl8139.c |5 -
> 1 files changed, 4 insertions(
Hi,
> -Original Message-
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Monday, July 28, 2014 5:28 PM
> Subject: Re: [PATCH v2 1/7] bootindex: add modify_boot_device_path function
>
> > > I think it is ok to allow only *changing* the bootindex.
> > >
> > Yes, that's no problem.
Il 17/07/2014 13:02, Pavel Dovgalyuk ha scritto:
> This patch adds outport to VMState to allow correct saving and restoring
> the state of PC keyboard controller.
>
> Signed-off-by: Pavel Dovgalyuk
> ---
> hw/input/pckbd.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff
> > I think it is ok to allow only *changing* the bootindex.
> >
> Yes, that's no problem.
But then yoy always will have a old entry where you can take the suffix
from, and you don't need the suffix as parameter for the monitor
command.
cheers,
Gerd
On Fri, Jul 25, 2014 at 07:01:47PM +0200, Marc Marí wrote:
> > > @@ -73,3 +97,11 @@ QVirtioPCIDevice
> > > *qvirtio_pci_device_find(QPCIBus *bus, uint16_t device_type)
> > > return dev;
> > > }
> > > +
> > > +void qvirtio_pci_enable_device(QVirtioPCIDevice *d)
> > > +{
> > > +qpci_device
It fixes migration failure for machine type pc-i440fx-1.7 from
QEMU 1.7/2.0 to QEMU 2.1
Migration fails due to ACPI tables size grows across 1.7-2.1
versions. That causes ACPI tables ROM blob to change its size
differently for the same configurations on different QEMU versions.
As result migration
ping...
All the 6 patches have reviewed-by now.
On Fri, Jul 11, 2014 at 02:09:57PM +0800, Hu Tao wrote:
> This series adds two preallocation mode to qcow2 and raw:
>
> Option preallocation=full preallocates disk space for image by writing
> zeros to disk, this ensures disk space in any cases.
>
Il 17/07/2014 13:02, Pavel Dovgalyuk ha scritto:
> vapic state should not be synchronized with APIC while loading,
> because APIC state could be not loaded yet at that moment.
> We just save vapic_paddr in APIC VMState instead of synchronization.
This comment is now obsolete:
include/hw/i386/apic
On Mon, 28 Jul 2014 08:03:25 +
Igor Mammedov wrote:
> It fixes migration failure for machine type pc-i440fx-1.7 from
> QEMU 1.7/2.0 to QEMU 2.1
>
> Migration fails due to ACPI tables size grows across 1.7-2.1
> versions. That causes ACPI tables ROM blob to change its size
> differently for t
> -Original Message-
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Monday, July 28, 2014 4:31 PM
> Subject: Re: [PATCH v2 1/7] bootindex: add modify_boot_device_path function
>
> Hi,
>
> > > ... because you can just copy the suffix from the old entry here,
> > > instead of ex
Il 17/07/2014 13:02, Pavel Dovgalyuk ha scritto:
> VM clock does not run while saving, so there is no need for saving the ticks
> in HPET. Also added saving of hpet_offset field.
>
> Signed-off-by: Pavel Dovgalyuk
> ---
> hw/timer/hpet.c | 13 +
> 1 files changed, 1 insertions(+),
Hi,
> > ... because you can just copy the suffix from the old entry here,
> > instead of expecting the caller pass it in.
> >
> Okay, agreed.
>
> But we should also think about the situation which a device don't have
> old entry in global fw_boot_order list.
Throw an error?
I think it is ok
Hey,
Yup, thanks, task closed ;-)
Best regards,
Mateusz Krzywicki
From: arei.gong...@huawei.com
To: mateusz.krzywi...@windowslive.com; qemu-devel@nongnu.org
CC: stefa...@redhat.com; kw...@redhat.com
Subject: RE: [Qemu-devel] Possible null-ptr dereference
Date: Mon, 28 Jul 2014 06:03:45 +
On 07/28/14 10:03, Igor Mammedov wrote:
> Add API to mark memory region as extend-able on migration,
> to allow migration code to load smaller RAMBlock into
> a bigger one on destination QEMU instance.
>
> This will allow to fix broken migration from QEMU 1.7/2.0 to
> QEMU 2.1 due to ACPI tables
Il 28/07/2014 09:56, Igor Mammedov ha scritto:
>> > It doesn't handle the case of ACPI tables that shrink, which can happen
>> > as well. I guess if this ever happens we can just hard-code the table
>> > size of the "old" versions to something big enough (64K?) and keep using
>> > fine-grained siz
On 2014-07-28 10:11, Paolo Bonzini wrote:
> Il 27/07/2014 08:57, Jan Kiszka ha scritto:
>> From: Jan Kiszka
>>
>> According to ICH9 spec, the MSI capability is located at 0x60. This is
>> important for guest drivers that do not parse the capability chain and
>> use absolute addresses instead.
>>
>
Il 27/07/2014 09:08, Jan Kiszka ha scritto:
> From: Jan Kiszka
>
> The spec says (and real HW confirms this) that, if the bus master bit
> is 0, the device will not generate any PCI accesses. MSI and MSI-X
> messages fall among these, so we should use the corresponding address
> space to deliver
Il 27/07/2014 08:57, Jan Kiszka ha scritto:
> From: Jan Kiszka
>
> According to ICH9 spec, the MSI capability is located at 0x60. This is
> important for guest drivers that do not parse the capability chain and
> use absolute addresses instead.
>
> Signed-off-by: Jan Kiszka
> ---
> hw/audio/in
On 07/28/14 09:40, Igor Mammedov wrote:
> On Fri, 25 Jul 2014 19:56:40 +0200
> Laszlo Ersek wrote:
>
>> On 07/25/14 17:48, Igor Mammedov wrote:
>>
>>> Add API to mark memory region as extend-able on migration,
>>> to allow migration code to load smaller RAMBlock into
>>> a bigger one on destinati
On Mon, 28 Jul 2014 15:13:06 +0800
Chen Fan wrote:
> Signed-off-by: Chen Fan
> ---
> target-i386/cpu.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
> index 6d008ab..217500c 100644
> --- a/target-i386/cpu.c
> +++ b/tar
Changes since v2:
- addressed Laszlo's comments
* fixing typos, rewording comments
* dropping enum-ification of RAMBlock flags
* adding zeroing out destination ramblock
* replacing 'if' with assert()
Changing the ACPI table size causes migration to break, and the memory
Add API to mark memory region as extend-able on migration,
to allow migration code to load smaller RAMBlock into
a bigger one on destination QEMU instance.
This will allow to fix broken migration from QEMU 1.7/2.0 to
QEMU 2.1 due to ACPI tables size changes across 1.7/2.0/2.1
versions by marking
It fixes migration failure for machine type pc-i440fx-1.7 from
QEMU 1.7/2.0 to QEMU 2.1
Migration fails due to ACPI tables size grows across 1.7-2.1
versions. That causes ACPI tables ROM blob to change its size
differently for the same configurations on different QEMU versions.
As result migration
On Fri, 25 Jul 2014 19:37:41 +0200
Paolo Bonzini wrote:
> Il 25/07/2014 17:48, Igor Mammedov ha scritto:
> > It fixes migration failure for machine type pc-i440fx-1.7 from
> > QEMU 1.7/2.0 to QEMU 2.1
> >
> > Migration fails due to ACPI tables size grows across 1.7-2.1
> > versions. That causes
> Am 28.07.2014 um 08:47 schrieb Alexey Kardashevskiy :
>
>> On 07/24/2014 11:15 PM, Alexander Graf wrote:
>>
>>> On 18.07.14 06:31, cyril...@gmail.com wrote:
>>> It may prove useful know which Linux distribution version the host machine
>>> is running when an issue in the guest arises but a us
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Il 17/07/2014 13:01, Pavel Dovgalyuk ha scritto:
> > This set of patches is related to the reverse execution and deterministic
> > replay of qemu execution Our implementation of deterministic replay can
> > be u
On Fri, 25 Jul 2014 19:56:40 +0200
Laszlo Ersek wrote:
> On 07/25/14 17:48, Igor Mammedov wrote:
>
> > Add API to mark memory region as extend-able on migration,
> > to allow migration code to load smaller RAMBlock into
> > a bigger one on destination QEMU instance.
> >
> > This will allow to fi
Signed-off-by: Chen Fan
---
target-i386/cpu.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 6d008ab..217500c 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1716,9 +1716,9 @@ static void x86_set_hv_spinlocks(O
101 - 155 of 155 matches
Mail list logo
