Hi,
I (or we) prefer to use GPLv2 for our product. but if qemu commuinty need to
use "GPLv2 or later", it's okay.
BTW, are there any issues to use GPLv2 for qemu. does it mandatory to use
"GPLv2 or later'?
Thank you,
Kyungmin Park
--- Original Message ---
Sender : Peter Crosthwaite
Da
Hi all,
Could someone help me to confirm that I understand how the QEMU cross page
boundary checking correctly or not? Below is the source code I am looking at,
static inline void gen_goto_tb(DisasContext *s, int tb_num, target_ulong eip)
{
if ((pc & TARGET_PAGE_MASK) == (tb->pc & TARGET_
On Sun, Apr 08, 2012 at 08:30:47AM -0400, Ayal Baron wrote:
>
>
> - Original Message -
> > N.B. This is a small patch with significant implications. Please
> > read
> > carefully.
> >
> > Right now, '-M pc' is the default and, in general, this machine type
> > has guest
> > visible ABI
On Thu, Apr 05, 2012 at 05:42:57PM +0200, Paolo Bonzini wrote:
> QED's opaque data includes a pointer back to the BlockDriverState.
> Creating a snapshot whose format is QED breaks the relationship when
> bdrv_append shuffles data between bs_new and bs_top. To avoid this,
> add a "rebind" function
Hi all,
on the current git master, I cannot compile any more.
The error is:
qapi/qmp-input-visitor.c: In function 'qmp_input_pop':
qapi/qmp-input-visitor.c:92: error: 'GHashTableIter' undeclared (first use
in this function)
qapi/qmp-input-visitor.c:92: error: (Each undeclared identifier is repor
On 2012-04-09 17:36, Serge E. Hallyn wrote:
> Hi,
>
> at https://bugs.launchpad.net/debian/+source/qemu-kvm/+bug/975240 there is
> reported a problem in 1.0.0 with running unaccelerated qemu with hpet.
> This is fixed upstream as of commit ce967e2f33861b0e17753f97fa4527b5943c94b6.
> However, that
On 04/09/2012 09:26 PM, Xiao Guangrong wrote:
> Yes, if Xwindow is not enabled, the benefit is limited. :)
I'm more interested in migration.
We could optimize the framebuffer by disabling dirty logging when
VNC/Spice is not connected (which should usually be the case), or when
the SDL window is m
On 04/09/2012 10:19 PM, Blue Swirl wrote:
> Rename functions with memory_region_ prefix to avoid future clashes.
>
> Change the RAM/ROM/ROMD test functions to take MemoryRegion
> instead of MemoryRegionSection.
> -
> #endif
> #endif
> diff --git a/exec.c b/exec.c
> index 0dda7b5..5080dde 100644
>
Il 10/04/2012 11:18, Erik Rull ha scritto:
> Hi all,
>
> on the current git master, I cannot compile any more.
>
> The error is:
> qapi/qmp-input-visitor.c: In function 'qmp_input_pop':
> qapi/qmp-input-visitor.c:92: error: 'GHashTableIter' undeclared (first use
> in this function)
> qapi/qmp-in
Am 03.04.2012 21:38, schrieb Anthony Liguori:
> Right now, '-M pc' is the default and, in general, this machine type has guest
> visible ABI changes in each version of QEMU. At some point in each release,
> we create a '-M pc-X.Y' corresponding to the last release and attempt to make
> that look l
10.04.2012 13:18, Erik Rull wrote:
Hi all,
on the current git master, I cannot compile any more.
Debian 4.0 is rather old - it is etch, which was before
lenny which was discontinued about a month ago. Note
that on etch, for example kvm will not work due to completely
missing kernel support.
On 10 April 2012 11:30, Andreas Färber wrote:
> Independent of what frequency of machine versions we offer, I think
> defaulting to pc-1.0 is a bad idea. The people fiddling with QEMU
> command lines are mostly developers, others can be expected to use a
> more convenient frontend, such as libvirt
On Tue, Apr 10, 2012 at 02:29:56PM +0400, Michael Tokarev wrote:
> 10.04.2012 13:18, Erik Rull wrote:
> > Hi all,
> >
> >on the current git master, I cannot compile any more.
>
> Debian 4.0 is rather old - it is etch, which was before
> lenny which was discontinued about a month ago. Note
> that
On 10 April 2012 11:32, Daniel P. Berrange wrote:
> Check the above docs - IME they're usually pretty good at telling you
> exactly what version things appeared in.
Last time I needed to check that kind of detail (in the threading
APIs) the docs and the actual implementation disagreed...
-- PMM
On Tue, Apr 10, 2012 at 11:18:56AM +0200, Erik Rull wrote:
> Hi all,
>
> on the current git master, I cannot compile any more.
>
> The error is:
> qapi/qmp-input-visitor.c: In function 'qmp_input_pop':
> qapi/qmp-input-visitor.c:92: error: 'GHashTableIter' undeclared (first use
> in this functio
On Tue, Apr 10, 2012 at 11:18:56AM +0200, Erik Rull wrote:
> Hi all,
>
> on the current git master, I cannot compile any more.
>
> The error is:
> qapi/qmp-input-visitor.c: In function 'qmp_input_pop':
> qapi/qmp-input-visitor.c:92: error: 'GHashTableIter' undeclared (first use
> in this functio
10.04.2012 14:32, Daniel P. Berrange wrote:
On Tue, Apr 10, 2012 at 02:29:56PM +0400, Michael Tokarev wrote:
10.04.2012 13:18, Erik Rull wrote:
Hi all,
on the current git master, I cannot compile any more.
Debian 4.0 is rather old - it is etch, which was before
lenny which was discontinued
On 04/10/2012 05:30 AM, Andreas Färber wrote:
Am 03.04.2012 21:38, schrieb Anthony Liguori:
Right now, '-M pc' is the default and, in general, this machine type has guest
visible ABI changes in each version of QEMU. At some point in each release,
we create a '-M pc-X.Y' corresponding to the las
On 10 April 2012 12:24, Anthony Liguori wrote:
> The only thing that a developer needs to do is add:
>
> [machine]
> type=pc-next
>
> In /etc/qemu/target-x86_64.conf to change the default to pc-next. Then you
...can confuse everybody else when you report bugs/issues and
forget to mention this :-
On Wed, Apr 4, 2012 at 2:23 PM, Ori Mamluk wrote:
> Hi Stephan,
> Thanks again for the thorough and detailed review.
> Some answers embedded below, generally I took all the points you mentioned.
> Main changes were:
> - Use qemu-thread
> * WRT to this - I didn't find any recv() function there.
On 04/10/2012 06:27 AM, Peter Maydell wrote:
On 10 April 2012 12:24, Anthony Liguori wrote:
The only thing that a developer needs to do is add:
[machine]
type=pc-next
In /etc/qemu/target-x86_64.conf to change the default to pc-next. Then you
...can confuse everybody else when you report bu
Am 10.04.2012 13:24, schrieb Anthony Liguori:
> The only thing that a developer needs to do is add:
>
> [machine]
> type=pc-next
>
> In /etc/qemu/target-x86_64.conf to change the default to pc-next. Then
> you never need to type it again.
Isn't that file overwritten with each `make install`?
A
Am 10.04.2012 12:32, schrieb Peter Maydell:
> On 10 April 2012 11:30, Andreas Färber wrote:
>> Independent of what frequency of machine versions we offer, I think
>> defaulting to pc-1.0 is a bad idea. The people fiddling with QEMU
>> command lines are mostly developers, others can be expected to
On 04/05/2012 11:42 AM, Paolo Bonzini wrote:
> QED's opaque data includes a pointer back to the BlockDriverState.
> Creating a snapshot whose format is QED breaks the relationship when
> bdrv_append shuffles data between bs_new and bs_top. To avoid this,
> add a "rebind" function that tells the dr
On April 10, 2012 at 12:57 PM Michael Tokarev wrote:
> 10.04.2012 14:32, Daniel P. Berrange wrote:
> > On Tue, Apr 10, 2012 at 02:29:56PM +0400, Michael Tokarev wrote:
> >> 10.04.2012 13:18, Erik Rull wrote:
> >>> Hi all,
> >>>
> >>> on the current git master, I cannot compile any more.
> >>
On April 10, 2012 at 12:29 PM Paolo Bonzini wrote:
> Il 10/04/2012 11:18, Erik Rull ha scritto:
> > Hi all,
> >
> > on the current git master, I cannot compile any more.
> >
> > The error is:
> > qapi/qmp-input-visitor.c: In function 'qmp_input_pop':
> > qapi/qmp-input-visitor.c:92: error: 'G
On 04/10/2012 02:40 PM, Anthony Liguori wrote:
>> ...can confuse everybody else when you report bugs/issues and
>> forget to mention this :-)
>
>
> Can't make everyone happy :-)
As a second choice, we can try to make everyone unhappy, which has the
desirable property of fairness.
--
error compil
Combination ping^2 and apology for forgetting to cc qemu-ppc.
-- PMM
On 3 April 2012 12:57, Peter Maydell wrote:
> Ping?
>
> -- PMM
>
> On 12 March 2012 16:24, Peter Maydell wrote:
>> Synchronize the CPU state via cpu_sychronize_state() unconditionally
>> in gdb_set_cpu_pc() rather than only in
On Wed, Apr 04, 2012 at 03:02:06PM +1000, David Gibson wrote:
> The VIOsPAPRBus structure, used on the pseries machine contains some old
> fields which are no longer used anywhere. This patch removes them.
>
> Cc: qemu-triv...@nongnu.org
>
> Signed-off-by: David Gibson
> ---
> hw/spapr_vio.h |
On Wed, Apr 04, 2012 at 05:03:15PM +0100, Peter Maydell wrote:
> Remove some useless uses of ARCH_CFLAGS -- this variable was never set
> so will always be empty. The uses were accidental: in commit 0c439cbf8
> Juan Quintela removed ARCH_CFLAGS in favour of CFLAGS (which in turn
> became QEMU_CFLAG
On Fri, Apr 06, 2012 at 09:33:20PM +0200, Stefan Weil wrote:
> #abort is not a preprocessor statement. It aborts, but the preprocessor
> statement #error is more common to abort a compilation.
>
> Signed-off-by: Stefan Weil
> ---
> configure |2 +-
> 1 files changed, 1 insertions(+), 1 delet
Am 30.03.2012 14:51, schrieb Peter Maydell:
> Register subclasses for each ARM CPU implementation (with the
> exception of "pxa270", which is an alias for "pxa270-a0").
>
> Let arm_cpu_list() enumerate CPU subclasses in alphabetical order,
> except for special value "any".
>
> Replace cpu_arm_fin
On 04/03/2012 09:41 AM, Michael S. Tsirkin wrote:
On Mon, Mar 19, 2012 at 01:11:16PM -0500, Anthony Liguori wrote:
On 03/15/2012 06:49 PM, Michael S. Tsirkin wrote:
I'm trying a signed pull request now. You can check the signature
on for_anthony if you like, and if your git is recent enough
it
Were you able to find any clues...?
Rahul N.
On Tuesday, April 10, 2012, Rahul Nair wrote:
> Please check the attached screenshot that I took during the issue.
> I cant find anything useful in the logs.
>
> -Rahul N.
>
> On Tue, Apr 10, 2012 at 3:31 AM, Christopher M. Penalver <
christopher.penal
On 10 April 2012 14:09, Andreas Färber wrote:
> Am 30.03.2012 14:51, schrieb Peter Maydell:
>> Register subclasses for each ARM CPU implementation (with the
>> exception of "pxa270", which is an alias for "pxa270-a0").
>>
>> Let arm_cpu_list() enumerate CPU subclasses in alphabetical order,
>> exc
Hi,
Eagerly waiting for your suggestions. Can anyone please respond on this?
Is there any chat available for qemu-devel group?
Thanks\Naga.
From: Naga Mohan Pothula
To: "qemu-devel@nongnu.org"
Sent: Monday, April 9, 2012 5:57 PM
Subject: [Qemu-devel] WinXP
As there are no topics, call is cancelled. Sorry for the late notice.
Hi Jun -
That's the problem - none of this can be done whatsoever with libvirt.
The issue about libvirt is that it is a manager of virtualization programs
running in separate OS processes. Doing the kind of tight interaction with
several qemu instances in one userland process & thread, and full
e
2012/4/10 Mikael
> Hi Jun -
>
> That's the problem - none of this can be done whatsoever with libvirt.
>
> The issue about libvirt is that it is a manager of virtualization programs
> running in separate OS processes. Doing the kind of tight interaction with
> several qemu instances in one userla
Quoting Jan Kiszka (jan.kis...@siemens.com):
> On 2012-04-09 17:36, Serge E. Hallyn wrote:
> > Hi,
> >
> > at https://bugs.launchpad.net/debian/+source/qemu-kvm/+bug/975240 there is
> > reported a problem in 1.0.0 with running unaccelerated qemu with hpet.
> > This is fixed upstream as of commit
2012/4/10 Mikael
> Hi Jun -
>
> That's the problem - none of this can be done whatsoever with libvirt.
>
> The issue about libvirt is that it is a manager of virtualization programs
> running in separate OS processes. Doing the kind of tight interaction with
> several qemu instances in one userla
Am 10.04.2012 08:41, schrieb David Gibson:
> On Fri, Apr 06, 2012 at 06:17:07PM +0200, Andreas Färber wrote:
>> Hello,
>>
>> This series follows up on my PowerPC QOM'ification patches from the
>> qom-cpu-others.v1 RFC series and splits it into steps easier to review.
>> The finalizer is actually fi
On Fri, 30 Mar 2012 09:49:20 +0200
Paolo Bonzini wrote:
> Regarding device_add ? and device_add foo,? I would implement it as
> separate QMP commands hooking into QOM, such as qom_list_types (taking
> the superclass as an optional argument) and qom_properties. But the
> latter first needs static
Il 10/04/2012 16:23, Luiz Capitulino ha scritto:
>> > Regarding device_add ? and device_add foo,? I would implement it as
>> > separate QMP commands hooking into QOM, such as qom_list_types (taking
>> > the superclass as an optional argument) and qom_properties. But the
>> > latter first needs sta
On Tue, 10 Apr 2012 16:27:43 +0200
Paolo Bonzini wrote:
> Il 10/04/2012 16:23, Luiz Capitulino ha scritto:
> >> > Regarding device_add ? and device_add foo,? I would implement it as
> >> > separate QMP commands hooking into QOM, such as qom_list_types (taking
> >> > the superclass as an optional
Am 28.03.2012 23:39, schrieb David Gibson:
> PAPR specifies a Command Response Queue (CRQ) mechanism used for virtual
> IO, which we implement. However, we don't correctly clean up registered
> CRQs when we reset the system.
>
> This patch adds a reset handler to fix this bug. While we're at it,
Am 28.03.2012 23:39, schrieb David Gibson:
> This patch adds the PAPR defined RTAS system-reboot call to the pseries
> machine emulation, providing the guest with a way to trigger a reboot.
> This exposes a bug in the pseries VIO code which means CRQs are not
> properly reset on a system reset. Th
Am 04.04.2012 07:02, schrieb David Gibson:
> The VIOsPAPRBus structure, used on the pseries machine contains some old
> fields which are no longer used anywhere. This patch removes them.
>
> Cc: qemu-triv...@nongnu.org
>
> Signed-off-by: David Gibson
> ---
Thanks, applied to ppc-next:
http://r
On 04/05/2012 10:51 AM, Kevin Wolf wrote:
The following changes since commit 8f8d364f2447e58768132fc10f48a67af371ee38:
Merge branch 's390-for-upstream' of git://repo.or.cz/qemu/agraf (2012-04-04
20:45:03 +)
Pulled. Thanks.
Regards,
Anthony Liguori
are available in the git reposito
On 04/09/2012 01:28 PM, Luiz Capitulino wrote:
Contains only the device_del conversion to the QAPI series.
The changes (since 7914cb3c738a03a5d5f7cb32c3768bc62eb1e944) are available
in the following repository:
git://repo.or.cz/qemu/qmp-unstable.git queue/qmp
Pulled. Thanks.
Regards,
On 04/05/2012 07:03 AM, Michael S. Tsirkin wrote:
On Mon, Mar 19, 2012 at 01:11:16PM -0500, Anthony Liguori wrote:
On 03/15/2012 06:49 PM, Michael S. Tsirkin wrote:
I'm trying a signed pull request now. You can check the signature
on for_anthony if you like, and if your git is recent enough
it
On 04/03/2012 05:42 AM, Stefan Hajnoczi wrote:
I'm will be gone from tomorrow until Monday so it's time to flush the
trivial-patches queue.
The following changes since commit f05f6b4adb4db3affb0cdd17383b0a7e905e66e1:
qdev: put all devices under /machine (2012-04-02 15:04:15 -0500)
are avail
On Sun, 2012-04-08 at 01:57 -0300, Marcelo Tosatti wrote:
> On Thu, Apr 05, 2012 at 11:07:15AM -0600, Alex Williamson wrote:
> > As Michael Tsirkin demonstrated, current PCI hotplug is vulnerable
> > to a few races. The first is a race with other hotplug operations
> > because we clear the up & do
Sorry, the screenshot does show that the deadlock is on a spinlock
during flush_tlb_others(), perhaps at
if (nr_cpu_ids > NUM_INVALIDATE_TLB_VECTORS)
raw_spin_lock(&f->tlbstate_lock);
--
You received this bug notification because you are a member of qemu-
devel-ml, which
Is there anything in /var/log/kern.log.* ? A fuller oops would be
valuable.
If this vm was spawned with libvirt, could you post the xml description?
What OS was the guest running?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
http
Uh, I meant "sorry, but the reason that happened isn't shown".
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/977391
Title:
BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*] in lucid
Status in QEMU
On Tue, Apr 10, 2012 at 09:14:00AM -0600, Alex Williamson wrote:
> On Sun, 2012-04-08 at 01:57 -0300, Marcelo Tosatti wrote:
> > On Thu, Apr 05, 2012 at 11:07:15AM -0600, Alex Williamson wrote:
> > > As Michael Tsirkin demonstrated, current PCI hotplug is vulnerable
> > > to a few races. The first
Embed CPUX86State as first member of X86CPU.
Distinguish between "x86_64-cpu" and "i386-cpu".
Drop cpu_x86_close() in favor of calling object_delete() directly.
For now let CPUClass::reset() call cpu_state_reset().
Signed-off-by: Andreas Färber
---
target-i386/cpu-qom.h | 75 +
On 2012-04-10 16:06, Serge E. Hallyn wrote:
> Quoting Jan Kiszka (jan.kis...@siemens.com):
>> On 2012-04-09 17:36, Serge E. Hallyn wrote:
>>> Hi,
>>>
>>> at https://bugs.launchpad.net/debian/+source/qemu-kvm/+bug/975240 there is
>>> reported a problem in 1.0.0 with running unaccelerated qemu with h
On Tue, Apr 10, 2012 at 10:08:10AM -0500, Anthony Liguori wrote:
> On 04/05/2012 07:03 AM, Michael S. Tsirkin wrote:
> >On Mon, Mar 19, 2012 at 01:11:16PM -0500, Anthony Liguori wrote:
> >>On 03/15/2012 06:49 PM, Michael S. Tsirkin wrote:
> >>>I'm trying a signed pull request now. You can check the
Just for an update: the TLB patch has been applied to ppc-next by
Andreas and so should be in git master shortly:
http://lists.gnu.org/archive/html/qemu-ppc/2012-03/msg00162.html
I've also reworked the MSR flags patch based upon feedback from
David/Scott and posted a revised version here, for whi
On Thu, Apr 5, 2012 at 11:59 AM, Jan Kiszka wrote:
> Use QemuEvent for signaling POSIX AIO completions. If native eventfd
> support is available, this avoids multiple read accesses to drain
> multiple pending signals.
>
> Signed-off-by: Jan Kiszka
> ---
> posix-aio-compat.c | 62
> ++-
Hello Anthony or Blue,
Please pull the x86 QOM CPU conversion.
Cc: Anthony Liguori
Cc: Blue Swirl
The following changes since commit 4e1957acc854b2f3f3068c75cef2a429f9b97011:
Merge commit 'ff71f2e8cacefae99179993204172bc65e4303df' into staging
(2012-04-10 08:21:58 -0500)
are available in
On Fri, Apr 6, 2012 at 2:48 PM, Paolo Bonzini wrote:
> scsibus_get_dev_path is leaking id if it is not NULL. Fix it.
>
> Reported-by: Laszlo Ersek
> Signed-off-by: Paolo Bonzini
> ---
> hw/scsi-bus.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/hw/scsi-bus
On Tue, Apr 10, 2012 at 09:35:39AM -0600, Alex Williamson wrote:
> On Tue, 2012-04-10 at 18:19 +0300, Michael S. Tsirkin wrote:
> > On Tue, Apr 10, 2012 at 09:14:00AM -0600, Alex Williamson wrote:
> > > On Sun, 2012-04-08 at 01:57 -0300, Marcelo Tosatti wrote:
> > > > On Thu, Apr 05, 2012 at 11:07:
On 2012-04-10 17:31, Stefan Hajnoczi wrote:
> On Thu, Apr 5, 2012 at 11:59 AM, Jan Kiszka wrote:
>> Use QemuEvent for signaling POSIX AIO completions. If native eventfd
>> support is available, this avoids multiple read accesses to drain
>> multiple pending signals.
>>
>> Signed-off-by: Jan Kiszka
On Wed, Apr 4, 2012 at 12:44 PM, Izik Eidus
wrote:
> What about this patch?, everything that was asked from Dmitry was
> accomplished...
> What prevent us from progressing with merging this patch?
Hang on, I asked what the point of the VMware paravirt device models
is. I don't think that was eve
On Tue, Apr 10, 2012 at 4:45 PM, Jan Kiszka wrote:
> On 2012-04-10 17:31, Stefan Hajnoczi wrote:
>> On Thu, Apr 5, 2012 at 11:59 AM, Jan Kiszka wrote:
>>> Use QemuEvent for signaling POSIX AIO completions. If native eventfd
>>> support is available, this avoids multiple read accesses to drain
>>>
Name it cpu.c to align with other QOM'ified targets.
Signed-off-by: Andreas Färber
---
Makefile.target|2 +-
target-i386/{cpuid.c => cpu.c} |0
2 files changed, 1 insertions(+), 1 deletions(-)
rename target-i386/{cpuid.c => cpu.c} (100%)
diff --git a/Makefile.target b/M
Move code from cpu_state_reset() into QOM x86_cpu_reset(),
fixing style issues for FPU init.
Signed-off-by: Andreas Färber
---
target-i386/cpu.c| 72 +-
target-i386/helper.c | 71 +
2 files ch
Move code from cpu_x86_init() to new QOM x86_cpu_initfn().
Also move mce_init() to cpu.c since it's used nowhere else.
Signed-off-by: Andreas Färber
---
target-i386/cpu.c| 27 +++
target-i386/helper.c | 18 --
2 files changed, 27 insertions(+), 18
On Tue, 2012-04-10 at 18:19 +0300, Michael S. Tsirkin wrote:
> On Tue, Apr 10, 2012 at 09:14:00AM -0600, Alex Williamson wrote:
> > On Sun, 2012-04-08 at 01:57 -0300, Marcelo Tosatti wrote:
> > > On Thu, Apr 05, 2012 at 11:07:15AM -0600, Alex Williamson wrote:
> > > > As Michael Tsirkin demonstrate
Quoting Jan Kiszka (jan.kis...@siemens.com):
> On 2012-04-10 16:06, Serge E. Hallyn wrote:
> > Quoting Jan Kiszka (jan.kis...@siemens.com):
> >> On 2012-04-09 17:36, Serge E. Hallyn wrote:
> >>> Hi,
> >>>
> >>> at https://bugs.launchpad.net/debian/+source/qemu-kvm/+bug/975240 there is
> >>> reporte
Il 10/04/2012 16:30, Luiz Capitulino ha scritto:
> On Tue, 10 Apr 2012 16:27:43 +0200
> Paolo Bonzini wrote:
>
>> Il 10/04/2012 16:23, Luiz Capitulino ha scritto:
> Regarding device_add ? and device_add foo,? I would implement it as
> separate QMP commands hooking into QOM, such as qom_li
On Mon, 9 Apr 2012 17:29:51 -0500
Michael Roth wrote:
> On Mon, Apr 09, 2012 at 04:57:48PM -0300, Luiz Capitulino wrote:
> > Hi Michael,
> >
> > There's a possible race condition in the bios_supports_mode() function used
> > by all suspend commands in qemu-ga: if the parent process receives a SI
On Tue, 10 Apr 2012 18:40:25 +0200
Paolo Bonzini wrote:
> Il 10/04/2012 16:30, Luiz Capitulino ha scritto:
> > On Tue, 10 Apr 2012 16:27:43 +0200
> > Paolo Bonzini wrote:
> >
> >> Il 10/04/2012 16:23, Luiz Capitulino ha scritto:
> > Regarding device_add ? and device_add foo,? I would implem
Il 10/04/2012 18:46, Luiz Capitulino ha scritto:
> I think that for device_add foo,? we could introduce
> qom-list-type-properties.
> Seems simple if limited to devices, not sure how to make it generic
> though.
With those patches you can make it generic.
>>>
>>> Cool, w
Am 04.04.2012 07:02, schrieb David Gibson:
> Currently the pseries machine contains not one but two somewhat ugly hacks
> to allow printing of early debug messages before the guest has properly
> read the device tree.
>
> First, we special case H_PUT_TERM_CHAR so that a vtermno of 0 (usually
> inv
On 2 April 2012 06:20, Peter A. G. Crosthwaite
wrote:
> The xilinx published kernel and linux test binaries expects initrd and dtb to
> be at these locations
Isn't this just broken? The documented ABI for the bootloader
to kernel interface tells the kernel where to find the initrd
(either via the
On 01/20/2012 12:55 PM, Eric Blake wrote:
Revisiting this thread, as I'd really like to have a solution in place
before qemu 1.1 is released.
>>> Looking at this from libvirt's perspective, would it be possible to give
>>> this a different name? Then libvirt would know that if
>>> block_job_canc
On 10 April 2012 01:19, Peter Crosthwaite
wrote:
> This new revision of our SDHCI series addressed Igors review of V1.
> Igor is currently iterating through revisions of his SDHC
> refactorings, is that acting as a blocker on this one?
I would like you and Igor and Vincent to agree on one SDHCI
c
From: Liu Yuan
The 'qemu-img convert -h' advertise that the default cache mode is
'writeback', while in fact it is 'unsafe'.
This patch 1) changes the cache mode as 'writeback' and 2) explicitly
calls bdrv_flush() to flush the dirty bits.
2) is needed because some backend storage doesn't have a
On Mon, 2012-04-09 at 11:24 +0300, Michael S. Tsirkin wrote:
> On Mon, Apr 09, 2012 at 11:07:03AM +0300, Gleb Natapov wrote:
> > On Sun, Apr 08, 2012 at 10:48:02PM +0300, Michael S. Tsirkin wrote:
> > > On Sun, Apr 08, 2012 at 03:45:38PM -0300, Marcelo Tosatti wrote:
> > > > On Sun, Apr 08, 2012 at
On Tue, 2012-04-10 at 18:45 +0300, Michael S. Tsirkin wrote:
> On Tue, Apr 10, 2012 at 09:35:39AM -0600, Alex Williamson wrote:
> > On Tue, 2012-04-10 at 18:19 +0300, Michael S. Tsirkin wrote:
> > > On Tue, Apr 10, 2012 at 09:14:00AM -0600, Alex Williamson wrote:
> > > > On Sun, 2012-04-08 at 01:57
Commit 7fc8d918b9674c3e9233d6d25da2457345d414a0 removed code from
eepro100.c and replaced it by different code: the code in net.c
returns bits 31...26, but eepro100 needs bits 7...2.
This patch partially reverts 7fc8d918b9674c3e9233d6d25da2457345d414a0.
To avoid future problems, I renamed the func
On Tue, Apr 10, 2012 at 01:45:15PM -0300, Luiz Capitulino wrote:
> On Mon, 9 Apr 2012 17:29:51 -0500
> Michael Roth wrote:
>
> > On Mon, Apr 09, 2012 at 04:57:48PM -0300, Luiz Capitulino wrote:
> > > Hi Michael,
> > >
> > > There's a possible race condition in the bios_supports_mode() function
Am 09.04.2012 21:17, schrieb Blue Swirl:
Use uintptr_t instead of void * or unsigned long in
several op related functions, env->mem_io_pc and
GETPC() macro.
Signed-off-by: Blue Swirl
---
cpu-defs.h | 4 ++--
exec-all.h | 10 +-
exec.c | 12 ++--
softmmu_template.h | 20 ++--
On Tue, Apr 10, 2012 at 08:48:54PM +0200, Stefan Weil wrote:
> Commit 7fc8d918b9674c3e9233d6d25da2457345d414a0 removed code from
> eepro100.c and replaced it by different code: the code in net.c
> returns bits 31...26, but eepro100 needs bits 7...2.
>
> This patch partially reverts 7fc8d918b9674c3
On Tue, 10 Apr 2012 13:50:28 -0500
Michael Roth wrote:
> On Tue, Apr 10, 2012 at 01:45:15PM -0300, Luiz Capitulino wrote:
> > On Mon, 9 Apr 2012 17:29:51 -0500
> > Michael Roth wrote:
> >
> > > On Mon, Apr 09, 2012 at 04:57:48PM -0300, Luiz Capitulino wrote:
> > > > Hi Michael,
> > > >
> > > >
On Tue, 10 Apr 2012 16:27:45 -0300
Luiz Capitulino wrote:
> On Tue, 10 Apr 2012 13:50:28 -0500
> Michael Roth wrote:
>
> > On Tue, Apr 10, 2012 at 01:45:15PM -0300, Luiz Capitulino wrote:
> > > On Mon, 9 Apr 2012 17:29:51 -0500
> > > Michael Roth wrote:
> > >
> > > > On Mon, Apr 09, 2012 at 0
On Tue, Apr 10, 2012 at 12:29:09PM -0600, Alex Williamson wrote:
> I never really intended the power state bitmap to be for power
> management of any sort, I was trying to support this kind of event flow:
>
> http://www.microsoft.com/china/whdc/system/pnppwr/hotadd/hotplugpci.mspx#EYH
>
> Hot-add
Il 10/04/2012 20:10, Liu Yuan ha scritto:
> From: Liu Yuan
>
> The 'qemu-img convert -h' advertise that the default cache mode is
> 'writeback', while in fact it is 'unsafe'.
>
> This patch 1) changes the cache mode as 'writeback' and 2) explicitly
> calls bdrv_flush() to flush the dirty bits.
>
On Tue, 2012-04-10 at 22:36 +0300, Michael S. Tsirkin wrote:
> On Tue, Apr 10, 2012 at 12:29:09PM -0600, Alex Williamson wrote:
> > I never really intended the power state bitmap to be for power
> > management of any sort, I was trying to support this kind of event flow:
> >
> > http://www.microso
commit f7aa558396dd0f6b7a2b22c05cb503c655854102 pulled the dcache and icache
line size initialization inside of a '#if !defined(CONFIG_USER_ONLY)' block.
This is not correct because instructions like 'dcbz' need the dcache size
initialized even for user mode.
Signed-off-by: Meador Inge
---
targe
Based on the following conversation:
http://mid.gmane.org/4f69f05b.5010...@codemonkey.ws
> Which reminds me - qemu sticks the release version in
> guest visible places like CPU version.
> This is wrong and causes windows guests to print messages
> about driver updates when you switch.
> We should
Hi,
This patch-set aims to add i2c support for the versatile pb board and
has now been split in to two patches: one that extracts the i2c code
from realview to a separate file and finally one that adds i2c support
to versatilepb.
-Oskar
Oskar Andero (2):
realview: break out versatile i2c contr
Signed-off-by: Oskar Andero
---
hw/versatilepb.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/hw/versatilepb.c b/hw/versatilepb.c
index 25afb1e..d011554 100644
--- a/hw/versatilepb.c
+++ b/hw/versatilepb.c
@@ -13,6 +13,7 @@
#include "net.h"
#include "sysemu.h"
The versatile i2c controller implementation was separated to
its own file called versatile_i2c.c. This is done as a preparation
for adding i2c support to the versatilepb board.
Signed-off-by: Oskar Andero
---
Makefile.target|1 +
hw/realview.c | 83 +---
Ping. Does this approach look like it could satisfy your desire for a
more integrated group layer? I'd really like to move VFIO forward,
we've been stalled on this long enough. David Woodhouse, I think this
provides the quirking you're looking for for device like the Ricoh, do
you have any othe
On Tue, Apr 10, 2012 at 02:03:05PM -0600, Alex Williamson wrote:
> On Tue, 2012-04-10 at 22:36 +0300, Michael S. Tsirkin wrote:
> > On Tue, Apr 10, 2012 at 12:29:09PM -0600, Alex Williamson wrote:
> > > I never really intended the power state bitmap to be for power
> > > management of any sort, I w
1 - 100 of 127 matches
Mail list logo
