As I know, this is not a good way to submit a patch. You need to read
the guideline first: http://wiki.qemu.org/Contribute/SubmitAPatch
--
Sincerely,
Cao jin
On 12/30/2016 10:41 AM, Junkang Fu wrote:
>>From 74e913fc41ea98d1dde692175f1e3fb6729342aa Mon Sep 17 00:00:00 2001
> From: "junkang.fjk"
>From 74e913fc41ea98d1dde692175f1e3fb6729342aa Mon Sep 17 00:00:00 2001
From: "junkang.fjk"
Date: Wed, 24 Aug 2016 19:36:53 +0800
Subject: [PATCH] virtio-blk: add disk-name device property
Current virtio-blk disk name(ex. /dev/vdb) has nothing to do with the
target dev
name specified in libvirt x
2016-12-29 22:57 GMT+08:00 Marc-André Lureau :
> Hi
>
> - Original Message -
> > In the resource attach backing function, everytime it will
> > allocate 'res->iov' thus can leading a memory leak. This
> > patch avoid this.
> >
> > Signed-off-by: Li Qiang
> > ---
> > hw/display/virtio-gpu
> -Original Message-
> From: Peter Xu [mailto:pet...@redhat.com]
> Sent: Friday, December 30, 2016 11:44 AM
> To: Liu, Yi L
> Cc: Tian, Kevin ; Lan, Tianyu ;
> 'qemu-
> de...@nongnu.org' ; 'bd.a...@gmail.com'
>
> Subject: Re: [Qemu-devel] [RFC PATCH 11/13] intel_iommu: provide its own
>
On Thu, Dec 29, 2016 at 10:23:21AM +, Liu, Yi L wrote:
[...]
> > >
> > > Hereby, I have a minor concern on this part.
> > > The replay would be performed in vfio_listener_region_add() when device is
> > > assigned. Since guest is just started, so there will be no valid context
> > > entry fo
2016-12-29 21:56 GMT+08:00 Marc-André Lureau :
> Hi
>
> - Original Message -
> > If the virgl_renderer_resource_attach_iov function fails the
> > 'res_iovs' will be leaked. Add check of the return value to
> > free the 'res_iovs' when failing.
> >
> > Signed-off-by: Li Qiang
>
> Reviewed-
On Thu, 12/29 04:09, Tian, Kevin wrote:
> is it a tradeoff between performance (better than linux-aio) and composability
> (snapshot and live migration which not supported by direct passthrough)?
Yes.
Fam
The "hotplugged" property is user visible, but it was never meant
to be set by the user. There are probably multiple ways to break
or crash device code by overriding the property. One example:
$ qemu-system-x86_64 -cpu qemu64,hotplugged=true
Segmentation fault (core dumped)
The DeviceState::h
Part of the functionality is copied from hw/ppc/prep.c.
Also add support for board identification/equipment registers.
Signed-off-by: Hervé Poussineau
---
hw/ppc/Makefile.objs | 1 +
hw/ppc/prep_systemio.c | 302 +
hw/ppc/trace-events| 4
Hi,
This patchset adds the emulation of the IBM RS/6000 7020 (40p). The real
machine is
able to run AIX (up to 4.3.3), Windows NT (up to 4.0 SP1), the beta of OS/2
PowerPC,
Solaris, Linux, NetBSD/PReP ...
I've tested current emulation with Open Hack'Ware, OpenBIOS and official
firmware.
Linux
VGA device registers vram as BAR 0. If this BAR is activated as a very low
address which
crosses 0xa-0xb, low memory region is not accessible anymore.
This fixes display on PReP machine if we enable PCI mapping at address 0.
Signed-off-by: Hervé Poussineau
---
hw/display/vga.c | 2 +-
Machine supports both Open Hack'Ware and OpenBIOS.
Open Hack'Ware is the default because OpenBIOS is currently unable to boot
PReP boot partitions or PReP kernels.
Signed-off-by: Hervé Poussineau
---
default-configs/ppc-softmmu.mak | 1 +
hw/ppc/prep.c | 231 +
Signed-off-by: Hervé Poussineau
---
default-configs/ppc-softmmu.mak | 1 +
hw/ppc/Makefile.objs| 1 +
hw/ppc/rs6000_mc.c | 232
hw/ppc/trace-events | 7 ++
4 files changed, 241 insertions(+)
create mode 100644 hw
Signed-off-by: Hervé Poussineau
---
hw/ppc/prep.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/ppc/prep.c b/hw/ppc/prep.c
index 054af1e..9fb89d3 100644
--- a/hw/ppc/prep.c
+++ b/hw/ppc/prep.c
@@ -339,13 +339,13 @@ static PortioList prep_port_list;
/* NVRAM helpers *
This is in fact a split of pci_vga_init() function in two parts.
Signed-off-by: Hervé Poussineau
---
hw/pci/pci.c | 22 --
include/hw/pci/pci.h | 1 +
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 24fae16..0d5a862 1
Programs running inside of QEMU can sometimes use more CPU time than is really
needed. To solve this problem, we just need to throttle the virtual CPU. This
feature will stop laptops from burning up.
This patch adds a menu called Speed that has menu items from 100% to 1% that
represent the speed
On Tue, Dec 27, 2016 at 05:21:17PM -0200, Eduardo Habkost wrote:
> Instead of searching the table we have just built, we can check
> the env->features field directly.
>
> Signed-off-by: Eduardo Habkost
> ---
> target/i386/kvm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> dif
Hi folks,
I saw on this page
http://wiki.qemu.org/Features/LibvirtWiresharkDissector that someone
was planning on writing a dissector generator for XDR.
I wish I had known about it when I started the following effort, which
is now at a Version 1 level:
https://gitlab.com/realrichardsharpe/wiresh
On Dec 29, 2016, at 12:35 PM, Eric Blake wrote:
> On 12/29/2016 11:24 AM, Programmingkid wrote:
>> Programs running inside of QEMU can sometimes use more CPU time than is
>> really
>> needed. To solve this problem, we just need to throttle the virtual CPU. This
>> feature will stop laptops from
On 12/29/2016 11:24 AM, Programmingkid wrote:
> Programs running inside of QEMU can sometimes use more CPU time than is really
> needed. To solve this problem, we just need to throttle the virtual CPU. This
> feature will stop laptops from burning up.
>
> This patch adds a menu called Speed that
Programs running inside of QEMU can sometimes use more CPU time than is really
needed. To solve this problem, we just need to throttle the virtual CPU. This
feature will stop laptops from burning up.
This patch adds a menu called Speed that has menu items from 10 to 1. They
represent the speed op
29.12.2016 19:08, Alex Bligh wrote:
Vladimir,
On 26 Dec 2016, at 15:57, Vladimir Sementsov-Ogievskiy
wrote:
OK, so first of all, one of the changes I made earlier was that now
each of the commands carries a list of queries, the way you list
everything is not 'having a query that doesn't con
Thank you very much for helping, but I found out what to do. There is a
function called cpu_throttle_set() that does exactly what I needed.
Happy Holidays.
On Dec 29, 2016, at 3:30 AM, Vincenzo Romano wrote:
> I think you have to provide much more details:
> Qemu version
> Host CPU and OS
>
29.12.2016 19:04, Alex Bligh wrote:
On 28 Dec 2016, at 00:18, Wouter Verhelst wrote:
On Mon, Dec 26, 2016 at 05:52:54PM +0300, Vladimir Sementsov-Ogievskiy wrote:
Shouldn't we add some flags to REP_META_CONTEXT, for client to be insure, is
returned string a direct context name or some kind of
> On 27 Dec 2016, at 14:09, Vladimir Sementsov-Ogievskiy
> wrote:
>
> What was the reason for it? Why not to negotiate forced structured read
> separately? Actually, this spec forces any server, which wants to implement
> structured reply implement structured read too. But what if it don't wa
Vladimir,
> On 26 Dec 2016, at 15:57, Vladimir Sementsov-Ogievskiy
> wrote:
>
>> OK, so first of all, one of the changes I made earlier was that now
>> each of the commands carries a list of queries, the way you list
>> everything is not 'having a query that doesn't contain a namespace'
>> but
> On 28 Dec 2016, at 00:18, Wouter Verhelst wrote:
>
> On Mon, Dec 26, 2016 at 05:52:54PM +0300, Vladimir Sementsov-Ogievskiy wrote:
>> Shouldn't we add some flags to REP_META_CONTEXT, for client to be insure, is
>> returned string a direct context name or some kind of wildcard? Just a flags
>>
Hi
- Original Message -
> In the resource attach backing function, everytime it will
> allocate 'res->iov' thus can leading a memory leak. This
> patch avoid this.
>
> Signed-off-by: Li Qiang
> ---
> hw/display/virtio-gpu.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/
On 12/28/2016 02:04 PM, Christopher Covington wrote:
It's best when posting a v3 to do so as a new thread, rather than buried
in-reply-to an earlier thread, as some maintainers' tools overlook
deeply-threaded patches. Probably won't matter too much in this case,
but it's useful information for fu
Hi
- Original Message -
> If the virgl_renderer_resource_attach_iov function fails the
> 'res_iovs' will be leaked. Add check of the return value to
> free the 'res_iovs' when failing.
>
> Signed-off-by: Li Qiang
Reviewed-by: Marc-André Lureau
Interestingly, in vrend_renderer_resource
On 12/29/2016 07:52 AM, Eric Blake wrote:
> On 12/29/2016 07:42 AM, Eric Blake wrote:
>> On 12/28/2016 12:51 PM, Christopher Pereira wrote:
>>> Hi Eric,
>>>
>>> There is something I don't understand.
>>>
>>> We are doing: "virsh save", "qemu-img convert", "qemu-img rebase" and
>>> "virsh restore".
On 12/29/2016 07:42 AM, Eric Blake wrote:
> On 12/28/2016 12:51 PM, Christopher Pereira wrote:
>> Hi Eric,
>>
>> There is something I don't understand.
>>
>> We are doing: "virsh save", "qemu-img convert", "qemu-img rebase" and
>> "virsh restore".
>> We only touch the backing chain by doing the reb
On 12/28/2016 11:07 AM, Peter Maydell wrote:
> On 28 December 2016 at 16:10, Eric Blake wrote:
>> On 12/28/2016 08:53 AM, Christopher Covington wrote:
>>> The definition of the major() and minor() macros are moving within glibc to
>>> . Include this header to avoid the following sorts of
>>> build
On 12/28/2016 12:51 PM, Christopher Pereira wrote:
> Hi Eric,
>
> There is something I don't understand.
>
> We are doing: "virsh save", "qemu-img convert", "qemu-img rebase" and
> "virsh restore".
> We only touch the backing chain by doing the rebase while the VM is down.
> Is there any chance t
On 12/19/2016 10:24 AM, Christopher Pereira wrote:
> Hi Eric,
>
> Thanks for your great answer.
>
> On 19-Dec-16 12:48, Eric Blake wrote:
>
>>
>>> Then we do the rebase while the VM is suspended to make sure the image
>>> files are reopened.
>> That part is where you are liable to break things.
I think you have to provide much more details:
Qemu version
Host CPU and OS
Guest CPU and OS
Application details
Il 29 dic 2016 07:27, "Programmingkid" ha
scritto:
> There is a program that I run inside of QEMU that doesn't use the virtual
> CPU very efficiently. It causes QEMU to use 100% of t
FWIW, this affects me too.
Ubuntu 14.04
QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.30), Copyright (c)
2003-2008 Fabrice Bellard
OS X 10.9.5.
The observed behavior is that when I hit "Connect" a spinning circle
appears nearby but nothing else ever happens.
There are reports online:
From c2f1631132821d61e1942a8723ba596f91d3e672 Mon Sep 17 00:00:00 2001
From: Zhang Qian
Date: Thu, 29 Dec 2016 20:00:01 +0800
Subject: [PATCH] scsi-disk: fix crash on VERIFY command Commit 166dbda
"scsi-disk: fix VERIFY for scsi-block" add a process of VERIFY in
scsi_block_dma_command. But, the
Hi all,
There is something to explain in this RFC PATCH.
On Thu, Dec 29, 2016 at 05:16:19PM +0800, Chao Fan wrote:
>This RFC PATCH is my demo about the new feature, here is my POC mail:
>https://lists.gnu.org/archive/html/qemu-devel/2016-12/msg00646.html
>
>When migration_bitmap_sync executed, ge
> -Original Message-
> From: Peter Xu [mailto:pet...@redhat.com]
> Sent: Thursday, December 29, 2016 6:00 PM
> To: Liu, Yi L
> Cc: Tian, Kevin ; Lan, Tianyu ;
> 'qemu-
> de...@nongnu.org' ; 'bd.a...@gmail.com'
>
> Subject: Re: [Qemu-devel] [RFC PATCH 12/13] intel_iommu: do replay when
>
> -Original Message-
> From: Peter Xu [mailto:pet...@redhat.com]
> Sent: Thursday, December 29, 2016 5:56 PM
> To: Liu, Yi L
> Cc: Tian, Kevin ; Lan, Tianyu ;
> 'qemu-
> de...@nongnu.org' ; 'bd.a...@gmail.com'
>
> Subject: Re: [Qemu-devel] [RFC PATCH 11/13] intel_iommu: provide its own
On Thu, Dec 29, 2016 at 08:02:16AM -, Hansni Bu wrote:
> Public bug reported:
...
> https://bugs.launchpad.net/bugs/1653063
...
> After console prints the message below:
> "Uncompressing
> Linux..
> done, booting the
On Thu, Dec 29, 2016 at 07:38:38AM +, Liu, Yi L wrote:
> > Before this one we only invalidate context cache when we receive context
> > entry invalidations. However it's possible that the invalidation also
> > contains a domain switch (only if cache-mode is enabled for vIOMMU). In
> > that case
On Thu, Dec 29, 2016 at 07:38:20AM +, Liu, Yi L wrote:
[...]
> > +static void vtd_iommu_replay(MemoryRegion *mr, IOMMUNotifier *n)
> > +{
> > +VTDAddressSpace *vtd_as = container_of(mr, VTDAddressSpace, iommu);
> > +IntelIOMMUState *s = vtd_as->iommu_state;
> > +uint8_t bus_n = pc
In the resource attach backing function, everytime it will
allocate 'res->iov' thus can leading a memory leak. This
patch avoid this.
Signed-off-by: Li Qiang
---
hw/display/virtio-gpu.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
ind
This RFC PATCH is my demo about the new feature, here is my POC mail:
https://lists.gnu.org/archive/html/qemu-devel/2016-12/msg00646.html
When migration_bitmap_sync executed, get the time and read bitmap to
calculate how many dirty pages born between two sync.
Use inst_dirty_pages / (time_now - ti
On Wed, 28 Dec 2016 15:08:42 -0200
Eduardo Habkost wrote:
> On Fri, Nov 18, 2016 at 12:02:54PM +0100, Igor Mammedov wrote:
> > so it won't impose an additional limits on max_cpus limits
> > supported by different targets.
> >
> > It removes global MAX_CPUMASK_BITS constant and need to
> > bump i
Public bug reported:
I tested with the latest git repo, (commit:
dbe2b65566e76d3c3a0c3358285c0336ac61e757).
My configure options when building QEMU:
'../configure' '--prefix=$HOME/local/qemu.git'
'--target-list=aarch64-softmmu,arm-softmmu' '--cpu=x86_64' '--cc=gcc'
'--disable-user' '--disable-s
If the virgl_renderer_resource_attach_iov function fails the
'res_iovs' will be leaked. Add check of the return value to
free the 'res_iovs' when failing.
Signed-off-by: Li Qiang
---
hw/display/virtio-gpu-3d.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/hw/display/
49 matches
Mail list logo
