Il 10/05/2014 08:45, Brad Smith ha scritto:
Having your feature in-tree is a privilege, not a right. You earn it by
helping to maintain it. "it's not really maintained right now" means it
has not been earning its keep. You're encouraged to remedy that.
Huh? "my feature"? I have nothing to d
Peter Lieven wrote:
>> Am 09.05.2014 um 11:43 schrieb "Dr. David Alan Gilbert"
>> :
>>
>> * Peter Lieven (p...@kamp.de) wrote:
>>> Hi,
>>>
>>> while working on ram migration and reading through the code I realized that
>>> qemu does not stop loading a saved VM or rejecting an incoming migration
On 10 May 2014 08:07, Paolo Bonzini wrote:
> Why don't you send a patch?
Or just test the one I sent yesterday:
http://patchwork.ozlabs.org/patch/347443/
thanks
-- PMM
On 10 May 2014 10:16, Doug Kwan wrote:
> diff --git a/linux-user/uname.c b/linux-user/uname.c
> index f5d4c66..cb1f9a3 100644
> --- a/linux-user/uname.c
> +++ b/linux-user/uname.c
> @@ -65,6 +65,12 @@ const char *cpu_to_uname_machine(void *cpu_env)
> return "i586";
> }
> return
On 10 May 2014 10:16, Doug Kwan wrote:
> Signed-off-by: Doug Kwan
> ---
> configure | 6 ++
> default-configs/ppc64le-linux-user.mak | 1 +
> 2 files changed, 7 insertions(+)
> create mode 100644 default-configs/ppc64le-linux-user.mak
>
> diff --git a/configure
On 10 May 2014 10:16, Doug Kwan wrote:
> Look at ELF header to determin ABI version on PPC64. This is required
typo: "determine".
> for executing the first instruction correctly. Also print correct machine
> name in uname() system call.
thanks
-- PMM
On 10 May 2014 10:16, Doug Kwan wrote:
> This allow running PPC64 little-endian in user mode if target is configured
> that way. In PPC64 LE user mode we set MSR.LE during initialization.
> Overhaul handling of byteswapping in code generation and mem helpers.
This looks pretty good to me (I'll l
if a saved vm has unknown flags in the memory data qemu
currently simply ignores this flag and continues which
yields in an unpredictable result.
this patch catches all unknown flags and
aborts the loading of the vm.
CC: qemu-sta...@nongnu.org
Signed-off-by: Peter Lieven
---
arch_init.c |7
we currently look up the ram ptr for each single page. Cache
the pointer while we operate on the same block.
Signed-off-by: Peter Lieven
---
arch_init.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 582b716..ce338aa
We were returning the incorrect uname string (with a hyphen, not
an underscore) for x86_64. Fix this by removing the x86_64 special
case, since the default "just use UNAME_MACHINE" behaviour suffices.
This leaves cpu_to_uname_machine() special cases for only those
architectures which need to vary t
Hi,
The patch is correct. There is a small improved point.
>
> /* In doubt sent page as normal */
> bytes_sent = -1;
> @@ -990,16 +996,17 @@ static inline void *host_from_stream_offset(QEMUFile *f,
> int flags)
> {
> static RA
On Wed, 7 May 2014, Mark Cave-Ayland wrote:
On 07/05/14 18:00, BALATON Zoltan wrote:
On Wed, 7 May 2014, Mark Cave-Ayland wrote:
I'm not sure if your problem related to s->lba == -1 should be solved
just for macio or higher up in the block layer, but the block people
will be on qemu-devel and n
On Fri, May 9, 2014 at 4:46 AM, Peter Maydell wrote:
> We don't implement very much of the GPTM TAR register, and what we
> do is wrong. The "are we in RT mode?" field is in s->config, not
> s->control. Correct this, use LOG_UNIMP rather than hw_error()
> for the cases we don't support, and avoid
> if a saved vm has unknown flags in the memory data qemu
> currently simply ignores this flag and continues which
> yields in an unpredictable result.
>
> this patch catches all unknown flags and
> aborts the loading of the vm.
>
> CC: qemu-sta...@nongnu.org
> Signed-off-by: Peter Lieven
> --
For xbzrle_decode_buffer(), when decoding contents will exceed writing
buffer, it will return -1, so need not check the return value whether
large than writing buffer.
And when failure occurs within load_xbzrle(), it always return -1
without any resources which need release.
So can remove the rel
On Fri, May 9, 2014 at 4:46 AM, Peter Maydell wrote:
> In fill_prefetch_fifo(), if the device we are reading from is 16 bit,
> then we must not try to transfer an odd number of bytes into the FIFO.
> This could otherwise have resulted in our overrunning the prefetch.fifo
> array by one byte.
>
> S
Am 10.05.2014 13:38, schrieb 陈梁:
> Hi,
> The patch is correct. There is a small improved point.
>> /* In doubt sent page as normal */
>> bytes_sent = -1;
>> @@ -990,16 +996,17 @@ static inline void *host_from_stream_offset(QEMUFile
>> *f,
>>
On Sat, May 10, 2014 at 9:55 AM, Le Tan wrote:
> Replace fprintf(stderr,...) with error_report() in files block/*, block.c,
> block-migration.c and blockdev.c. The trailing "\n"s of the @fmt argument
> have been removed because @fmt of error_report() should not contain newline.
>
> Signed-off-by:
On 10 May 2014 13:33, Peter Crosthwaite wrote:
> On Fri, May 9, 2014 at 4:46 AM, Peter Maydell
> wrote:
>> We don't implement very much of the GPTM TAR register, and what we
>> do is wrong. The "are we in RT mode?" field is in s->config, not
>> s->control. Correct this, use LOG_UNIMP rather than
On Fri, May 09, 2014 at 05:06:21PM +0200, Bernhard Walle wrote:
> Hello,
>
> I'm using QEmu 2.0.0 on a Linux host (x86-64) with a quite special
> target system that uses uvesafb ('video=uvesafb:1024x768-32'). I get
> following errors in the target system:
>
> uvesafb: Getting mode info block
Il 10/05/2014 12:51, Peter Lieven ha scritto:
we currently look up the ram ptr for each single page. Cache
the pointer while we operate on the same block.
Why don't you instead cache the result in the MemoryRegion, so that
memory_region_get_ram_ptr becomes a simple, inline field access?
Paol
You mean,
a) extent the MemoryRegion stuct with a pointer?
b) on the first call to memory_region_get_ram_ptr cache the result in the
struct?
Peter
Am 10.05.2014 17:33, schrieb Paolo Bonzini:
> Il 10/05/2014 12:51, Peter Lieven ha scritto:
>> we currently look up the ram ptr for each single pag
Am 10.05.2014 17:33, schrieb Paolo Bonzini:
> Il 10/05/2014 12:51, Peter Lieven ha scritto:
>> we currently look up the ram ptr for each single page. Cache
>> the pointer while we operate on the same block.
>
> Why don't you instead cache the result in the MemoryRegion, so that
> memory_region_get
This patch fixed the following bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1084302 .
path_combine can not calculate the correct full path name for backing_file.
Such as:
create a snapshot chain:
sn2->sn1->$BASE_IMG
backing file is : /home/wookpecker/img.qcow2
sn1 : /home/woodpecker/tmp/sn1
sn
From: Jun Li
This patch fixed the following bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1084302 .
path_combine can not calculate the correct full path name for backing_file.
Such as:
create a snapshot chain:
sn2->sn1->$BASE_IMG
backing file is : /home/wookpecker/img.qcow2
sn1 : /home/woodpe
or even this:
diff --git a/include/exec/memory.h b/include/exec/memory.h
index 1d55ad9..3003875 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -161,6 +161,7 @@ struct MemoryRegion {
unsigned ioeventfd_nb;
MemoryRegionIoeventfd *ioeventfds;
NotifierList iommu_notif
This device is ridiculous. It has two MMIO BARs, BAR4 and BAR2. BAR4
hosts the MSI-X table, so oviously it would be too easy to access it
directly, instead it creates a window register in BAR2 that, among
other things, provides access to the MSI-X table. This means MSI-X
doesn't work in the gues
On 10/05/14 3:07 AM, Paolo Bonzini wrote:
Il 10/05/2014 08:45, Brad Smith ha scritto:
Having your feature in-tree is a privilege, not a right. You earn it by
helping to maintain it. "it's not really maintained right now" means it
has not been earning its keep. You're encouraged to remedy tha
This patch fixed the following bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1084302 .
path_combine can not calculate the correct full path name for backing_file.
Such as:
create a snapshot chain:
sn2->sn1->$BASE_IMG
backing file is : /home/wookpecker/img.qcow2
sn1 : /home/woodpecker/tmp/sn1
sn
On 04/22/2014 05:21 PM, Marcel Apfelbaum wrote:
On Wed, 2014-04-16 at 22:20 +0800, Jun Li wrote:
Add remove_boot_device_path() function to remove bootindex when hot-unplug
a device. This patch fixed virtio-blk/virtio-net/scsi-disk/scsi-generic device.
So it has fixed bug1086603, ref:
https://bu
30 matches
Mail list logo
