[Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.

On Mon, Dec 21, 2009 at 09:16:17PM +0100, Sebastian Herbszt wrote: > Gleb Natapov wrote: > >On Mon, Dec 21, 2009 at 08:39:03PM +0100, Sebastian Herbszt wrote: > >>Anthony Liguori wrote: > >>>On 12/21/2009 12:24 PM, Sebastian Herbszt wrote: > As stated before i don't like the idea of automagical

Re: [Qemu-devel] [STABLE 0.12] QMP: Drop wrong assert()

Luiz Capitulino writes: > Some commands return a QList of QDicts, which is valid, > but will trig the assert(). > > Just drop it. > > Reported-by: Nathan Baum > Signed-off-by: Luiz Capitulino > --- > monitor.c |1 - > 1 files changed, 0 insertions(+), 1 deletions(-) > > diff --git a/monito

Re: [Qemu-devel] [PATCH 0/5] tcg conditional set, round 4

On Mon, Dec 21, 2009 at 12:28:03PM -0800, Richard Henderson wrote: > On 12/21/2009 01:13 AM, Laurent Desnogues wrote: >> The question for the generalized movcond is how useful is it? >> Which front-ends would need it and would the cost to generate >> code for it on some (most?) back-ends be amortiz

[Qemu-devel] Please help the daughter of a member of open source community

I am very very sorry for sending this mail to qemu-dev list. Please please help panjet, who loves the open source software and makes contribution to the open source community. He is the core member of the open source project jz-hacking and virtualmips. And even more, he created the open source foun

[Qemu-devel] [STABLE 0.12] QMP: Drop wrong assert()

Some commands return a QList of QDicts, which is valid, but will trig the assert(). Just drop it. Reported-by: Nathan Baum Signed-off-by: Luiz Capitulino --- monitor.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/monitor.c b/monitor.c index c0dc48e..3af1d5c 100644

Re: [Qemu-devel] [PATCH 3/7] QMP: Assure that returned data is a QDict

On Mon, 21 Dec 2009 19:21:18 + Nathan Baum wrote: > On Fri, 2009-12-18 at 13:25 -0200, Luiz Capitulino wrote: > > This is for debug purposes only. > > This breaks quite a lot of commands where the returned data is a QList, > e.g. query-commands, query-mice, query-cpus. Is the assert wrong, o

Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

Dor Laor wrote: Qemu will check the required cpuid of the cpu model on the host and refuse to load otherwise. When moving to this model, migration can be simplified too since there are fewer combination, and one can choose performance over migration flexibility and wise versa. Due to the above

Re: [Qemu-devel] [PATCH 0/5] tcg conditional set, round 4

On 12/21/2009 03:08 PM, Laurent Desnogues wrote: If you wanted to use movcond, you'd have to make cond + move a special case... You'd certainly want the ARM front-end to use movcond more often than that. For instance: addeq r1,r2,r3 --> add_i32 tmp,r2,r3 movcond_i32 r1,ZF,0,tmp,r1,eq

Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.

On 12/21/2009 01:43 PM, Gleb Natapov wrote: Please stop thinking so :) Especially about "user driven upgrades". Why combine disadvantages of vitalization with pain of physical HW management? Or may be next step will be to require uploading of CPU microcode to take advantage of KVM/tcg bug fixes?

Re: [Qemu-devel] [PATCH 0/5] tcg conditional set, round 4

On 12/21/2009 02:21 PM, Laurent Desnogues wrote: As far as I know these CPU's don't need the full movcond but only the variant with vtrue. I know that. And I looked into TCG very closely to figure out how to implement just that. Except then I have to modify TCG to special-case movcond to kn

Re: [Qemu-devel] [PATCH 0/5] tcg conditional set, round 4

On Mon, Dec 21, 2009 at 11:50 PM, Richard Henderson wrote: [...] >> Even if movcond was quick to generate >> host code, for instance for ARM, you'd have to explicitly detect >> conditional moves > > One of us is confused.  Why would I have to explicitly detect conditional > moves? Most ARM instru

Re: [Qemu-devel] [PATCH 0/5] tcg conditional set, round 4

On Mon, Dec 21, 2009 at 9:28 PM, Richard Henderson wrote: > On 12/21/2009 01:13 AM, Laurent Desnogues wrote: >> >> The question for the generalized movcond is how useful is it? >> Which front-ends would need it and would the cost to generate >> code for it on some (most?) back-ends be amortized? >

Re: [Qemu-devel] [PATCH 3/3] linux-user: Initialize Alpha FPCR register.

On 12/21/2009 02:33 AM, Aurelien Jarno wrote: On Sat, Dec 19, 2009 at 03:17:16PM -0800, Richard Henderson wrote: Signed-off-by: Richard Henderson --- linux-user/main.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/linux-user/main.c b/linux-user/main.c index 12502ad

Re: [Qemu-devel] [PATCH 0/5] tcg conditional set, round 4

On 12/21/2009 01:13 AM, Laurent Desnogues wrote: The question for the generalized movcond is how useful is it? Which front-ends would need it and would the cost to generate code for it on some (most?) back-ends be amortized? ... Any front end that has a conditional move instruction? Sparcv9, Mi

Re: [Qemu-devel] [PATCH] PPC64: Fix timebase

Am 21.12.2009 um 11:15 schrieb Aurelien Jarno: On Mon, Dec 21, 2009 at 10:39:39AM +0100, Alexander Graf wrote: On 21.12.2009, at 10:24, Aurelien Jarno wrote: On Mon, Dec 21, 2009 at 01:22:12AM +0100, Alexander Graf wrote: On PPC we have a 64-bit time base. Usually (PPC32) this is accessed

[Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.

Gleb Natapov wrote: On Mon, Dec 21, 2009 at 08:39:03PM +0100, Sebastian Herbszt wrote: Anthony Liguori wrote: >On 12/21/2009 12:24 PM, Sebastian Herbszt wrote: >>As stated before i don't like the idea of automagically >>upgrading the firmware >>on reset, e.g. after a live migration to a newer qe

[Qemu-devel] Re: Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.

On Mon, Dec 21, 2009 at 08:28:20PM +0100, Sebastian Herbszt wrote: > Gleb Natapov wrote: > >On Mon, Dec 21, 2009 at 07:24:43PM +0100, Sebastian Herbszt wrote: > >>Does any OS (Windows?) depend on the tables the bios creates (e.g. smbios) > >>for licensing? It would be ugly if Windows wants you to r

[Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.

On Mon, Dec 21, 2009 at 08:39:03PM +0100, Sebastian Herbszt wrote: > Anthony Liguori wrote: > >On 12/21/2009 12:24 PM, Sebastian Herbszt wrote: > >>As stated before i don't like the idea of automagically > >>upgrading the firmware > >>on reset, e.g. after a live migration to a newer qemu version. >

[Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.

On Mon, Dec 21, 2009 at 01:17:23PM -0600, Anthony Liguori wrote: > >Does any OS (Windows?) depend on the tables the bios creates (e.g. > >smbios) > >for licensing? It would be ugly if Windows wants you to > >re-activate after a reboot > >following a migration to newer qemu version and therefore pos

Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.

On Mon, Dec 21, 2009 at 01:13:10PM -0600, Anthony Liguori wrote: > On 12/21/2009 11:43 AM, Gleb Natapov wrote: > >Why I will never have reset equivalent to power off + startup? Are you > >saying we are not capable of implementing spec correctly? > > No, I'm saying that if you want reset absolutely

[Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.

Anthony Liguori wrote: On 12/21/2009 12:24 PM, Sebastian Herbszt wrote: As stated before i don't like the idea of automagically upgrading the firmware on reset, e.g. after a live migration to a newer qemu version. You have explained that qemu-kvm needs this in order to work with live migration

[Qemu-devel] Re: Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.

Gleb Natapov wrote: On Mon, Dec 21, 2009 at 07:24:43PM +0100, Sebastian Herbszt wrote: Does any OS (Windows?) depend on the tables the bios creates (e.g. smbios) for licensing? It would be ugly if Windows wants you to re-activate after a reboot following a migration to newer qemu version and th

Re: [Qemu-devel] [PATCH 3/7] QMP: Assure that returned data is a QDict

On Fri, 2009-12-18 at 13:25 -0200, Luiz Capitulino wrote: > This is for debug purposes only. This breaks quite a lot of commands where the returned data is a QList, e.g. query-commands, query-mice, query-cpus. Is the assert wrong, or are such commands meant to be returning a QDict? > Signed-off-b

[Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.

On 12/21/2009 12:24 PM, Sebastian Herbszt wrote: As stated before i don't like the idea of automagically upgrading the firmware on reset, e.g. after a live migration to a newer qemu version. You have explained that qemu-kvm needs this in order to work with live migration and changed hw support

Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.

On 12/21/2009 11:43 AM, Gleb Natapov wrote: Why I will never have reset equivalent to power off + startup? Are you saying we are not capable of implementing spec correctly? No, I'm saying that if you want reset absolutely equivalent to power off + startup, then you need to fork() and re-ex

[Qemu-devel] Re: Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.

On Mon, Dec 21, 2009 at 07:24:43PM +0100, Sebastian Herbszt wrote: > Gleb Natapov wrote: > >On Mon, Dec 21, 2009 at 11:26:12AM -0600, Anthony Liguori wrote: > >>On 12/21/2009 10:43 AM, Gleb Natapov wrote: > There are some really ugly corner cases here. For instance, guest > is running and

[Qemu-devel] Re: Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.

Gleb Natapov wrote: On Mon, Dec 21, 2009 at 11:26:12AM -0600, Anthony Liguori wrote: On 12/21/2009 10:43 AM, Gleb Natapov wrote: >>There are some really ugly corner cases here. For instance, guest >>is running and the user does a yum update which upgrades the qemu >>package. This includes layi

[Qemu-devel] [slirp] guest program's tcp connection hang on close_wait.

Hi All, I am using qemu-arm running linux (guest), I start a server program on the linux(guest); then I start a program on host machine to connect to the server(on qemu linux guest) to a specified tcp port. (the qemu is started with tcp redir configuration). Then I got a problem when the

Re: [Qemu-devel] M68K Or PPC Status Update to Run Mac OS in Qemu

G 3 wrote: > > On Dec 21, 2009, at 2:13 AM, qemu-devel-requ...@nongnu.org > wrote: > >> On 20.12.2009, at 21:32, Leo B wrote: >> >> >>> A while back I know someone was working on PPC Support in Qemu to be >>> able to run Mac OS9-Mac OS X in Qemu on X86 PC's no

Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.

On Mon, Dec 21, 2009 at 11:26:12AM -0600, Anthony Liguori wrote: > On 12/21/2009 10:43 AM, Gleb Natapov wrote: > >>There are some really ugly corner cases here. For instance, guest > >>is running and the user does a yum update which upgrades the qemu > >>package. This includes laying down a new b

Re: [Qemu-devel] M68K Or PPC Status Update to Run Mac OS in Qemu

On Dec 21, 2009, at 2:13 AM, qemu-devel-requ...@nongnu.org wrote: On 20.12.2009, at 21:32, Leo B wrote: A while back I know someone was working on PPC Support in Qemu to be able to run Mac OS9-Mac OS X in Qemu on X86 PC's not sure about M68K support though so is anybody still working on M6

[Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.

On Mon, Dec 21, 2009 at 09:40:47AM +0200, Gleb Natapov wrote: > On Sun, Dec 20, 2009 at 11:48:20AM -0600, Anthony Liguori wrote: > > >system_reset _is_ hard shutdown/start-up. If it is not it is a bug, we > > >just arguing if the same applies for the case that migration was done > > >between boot a

Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.

On 12/21/2009 10:43 AM, Gleb Natapov wrote: There are some really ugly corner cases here. For instance, guest is running and the user does a yum update which upgrades the qemu package. This includes laying down a new bios. User eventually restarts guest, now we re-read BIOS and we're on a newe

[Qemu-devel] Re: [PATCH] PPC: Make DCR uint32_t

On Mon, Dec 21, 2009 at 5:02 AM, Alexander Graf wrote: > For what I know DCR is always 32 bits wide, so we should also use uint32_t to > pass it along the stacks. > > This fixes a warning when compiling qemu-system-ppc64 with KVM enabled, making > it compile without --disable-werror > > Signed-off

Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.

On Mon, Dec 21, 2009 at 10:40:56AM -0600, Anthony Liguori wrote: > On 12/21/2009 01:32 AM, Gleb Natapov wrote: > >On Sun, Dec 20, 2009 at 08:59:48PM -0500, Kevin O'Connor wrote: > >>On Sun, Dec 20, 2009 at 11:48:20AM -0600, Anthony Liguori wrote: > >>>I think we have two ways to view firmware. The

[Qemu-devel] [PATCHv3-RFC 2/2] virtio: add features as qdev properties

Add feature bits as properties to virtio. This makes it possible to e.g. define machine without indirect buffer support, which is required for 0.10 compatibility, or without hardware checksum support, which is required for 0.11 compatibility. Since default values for optional features are now set

[Qemu-devel] [PATCHv3-RFC 1/2] qdev: add bit property type

This adds "bit" property type, which is a boolean stored in a 32 bit integer field, with legal values on and off. Will be used by virtio for feature bits. Signed-off-by: Michael S. Tsirkin --- hw/qdev-properties.c | 70 +- hw/qdev.h|

[Qemu-devel] [PATCHv3-RFC 0/2] qemu: properties for feature compatibility

Here's what I came up with for solving the problem of differences in features in virtio between 0.12 and 0.11. This also enables migration between different backends, e.g. between host where tap supports virtio net header and where it does not: management just needs to set features appropriately.

Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.

On 12/21/2009 01:32 AM, Gleb Natapov wrote: On Sun, Dec 20, 2009 at 08:59:48PM -0500, Kevin O'Connor wrote: On Sun, Dec 20, 2009 at 11:48:20AM -0600, Anthony Liguori wrote: I think we have two ways to view firmware. The first would be to treat guest firmware as part of the guest. Wh

[Qemu-devel] Re: stable-0.12 versus master branching?

On Sun, Dec 20, 2009 at 08:35:53AM -0600, Anthony Liguori wrote: > Michael S. Tsirkin wrote: >> I am really confused wrt stable 0.12 branching policy. >> For example I see this, in master: >> >> commit d587e0787153f0224a6140c5015609963ceaabfb >> Author: Anthony Liguori >> Date: Mo

Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

On 12/21/2009 02:59 PM, Andre Przywara wrote: KVM's cpuid filter doesn't help here because it won't attempt to mask things like sse3. It would be insane to emulate sse3 too. It does expose sse3 support (called pni in Linux IIRC). Not sure if qemu masks it, but the information is there. W

Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

On 12/21/2009 03:45 PM, David S. Ahern wrote: On 12/21/2009 05:05 AM, Avi Kivity wrote: On 12/21/2009 01:45 PM, Alexander Graf wrote: Well, we have two groups: 1) Casual user w/o management app 2) Enterprise user w/ management app So I clearly belong to the first group. 3)

Re: [Qemu-devel] [PATCH] PPC64: Fix timebase

Aurelien Jarno wrote: > On Mon, Dec 21, 2009 at 12:15:42PM +0100, Alexander Graf wrote: > >> On 21.12.2009, at 10:24, Aurelien Jarno wrote: >> >> >>> On Mon, Dec 21, 2009 at 01:22:12AM +0100, Alexander Graf wrote: >>> On PPC we have a 64-bit time base. Usually (PPC32) this is ac

[Qemu-devel] [PATCHv2-RFC 2/2] virtio: add features as qdev properties

Add feature bits as properties to virtio. This makes it possible to e.g. define machine without indirect buffer support, which is required for 0.10 compatibility, or without hardware checksum support, which is required for 0.11 compatibility. Since default values for optional features are now set

[Qemu-devel] [PATCHv2-RFC 1/2] qdev: add bit property type

This adds "bit" property type, which is a boolean stored in a 32 bit integer field, with legal values on and off. Will be used by virtio for feature bits. Signed-off-by: Michael S. Tsirkin --- hw/qdev-properties.c | 70 +- hw/qdev.h|

[Qemu-devel] [PATCHv2-RFC 0/2] qemu: properties for feature compatibility

Here's what I came up with for solving the problem of differences in features in virtio between 0.12 and 0.11. This also enables migration between different backends, e.g. between host where tap supports virtio net header and where it does not: management just needs to set features appropriately.

Re: [Qemu-devel] [PATCH] PPC64: Fix timebase

On Mon, Dec 21, 2009 at 12:15:42PM +0100, Alexander Graf wrote: > > On 21.12.2009, at 10:24, Aurelien Jarno wrote: > > > On Mon, Dec 21, 2009 at 01:22:12AM +0100, Alexander Graf wrote: > >> On PPC we have a 64-bit time base. Usually (PPC32) this is accessed using > >> two separate 32 bit SPR acce

Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

On 12/21/2009 06:51 AM, Michael S. Tsirkin wrote: > On Mon, Dec 21, 2009 at 06:45:22AM -0700, David S. Ahern wrote: >> >> On 12/21/2009 05:05 AM, Avi Kivity wrote: >>> On 12/21/2009 01:45 PM, Alexander Graf wrote: Well, we have two groups: 1) Casual user w/o management app

Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

On Mon, Dec 21, 2009 at 06:45:22AM -0700, David S. Ahern wrote: > > On 12/21/2009 05:05 AM, Avi Kivity wrote: > > On 12/21/2009 01:45 PM, Alexander Graf wrote: > >> > >> Well, we have two groups: > >> > >> 1) Casual user w/o management app > >> 2) Enterprise user w/ management app > >> > >> So I c

Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

On 12/21/2009 05:05 AM, Avi Kivity wrote: > On 12/21/2009 01:45 PM, Alexander Graf wrote: >> >> Well, we have two groups: >> >> 1) Casual user w/o management app >> 2) Enterprise user w/ management app >> >> So I clearly belong to the first group. >> > > 3) Developer/power user who knows what

[Qemu-devel] Re: cpuid problem in upstream qemu with kvm

No, Windows tries to detect changes in your hardware and assumes that if too many things change, you might be a pirate and requires you to phone their offices to re-authenticate. 'Just' the CPU is not big deal. Might hit you with two 'bad' points. Network interface + CPU will require re-activa

[Qemu-devel] Re: cpuid problem in upstream qemu with kvm

On 12/21/2009 08:48 AM, Gleb Natapov wrote: > Well, I wouldn't be too sure on that one. Software may use SSE3 instructions to access MMIO in which case we do have to emulate it. Unfortunately this is already a reality. Look here: http://groups.google.com/group/linux.kernel/browse_thread/thread

[Qemu-devel] [PATCH] PPC: Make DCR uint32_t

For what I know DCR is always 32 bits wide, so we should also use uint32_t to pass it along the stacks. This fixes a warning when compiling qemu-system-ppc64 with KVM enabled, making it compile without --disable-werror Signed-off-by: Alexander Graf --- darwin-user/main.c |4 ++-- hw/ppc

Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

Avi Kivity wrote: On 12/20/2009 07:59 PM, Anthony Liguori wrote: Gleb Natapov wrote: Windows is a mystery box, so we can speculate as much as we want about it. If you don't like something just say "it may break Windows" :) Losing activation does sound like an issue too. Downgrading seems mor

Re: [Qemu-devel] ne2k_isa: how to specify a custom iobase and irq?

"Sebastian Herbszt" writes: > Anthony Liguori wrote: >> Sebastian Herbszt wrote: >>> Markus Armbruster wrote: "Sebastian Herbszt" writes: > The default iobase and irq for the ne2k_isa card are 0x300 and 9. > It should be possible to override both using the "-net" syntax like >>

Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

On Mon, Dec 21, 2009 at 02:09:31PM +0200, Avi Kivity wrote: > On 12/21/2009 02:04 PM, Michael S. Tsirkin wrote: >> >> I think so - if this does not happen a lot, it's not a problem to phone home, >> right? >> > > I'm sure it's very annoying when it happens. It could well be less annoying than

Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

On 12/21/2009 02:04 PM, Michael S. Tsirkin wrote: I think so - if this does not happen a lot, it's not a problem to phone home, right? I'm sure it's very annoying when it happens. -- error compiling committee.c: too many arguments to function

Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

On Mon, Dec 21, 2009 at 02:04:47PM +0200, Avi Kivity wrote: > On 12/21/2009 01:18 PM, Michael S. Tsirkin wrote: >> >>> No, Windows tries to detect changes in your hardware and assumes that if >>> too many things change, you might be a pirate and requires you to phone >>> their offices to re-authent

Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

On 12/21/2009 01:45 PM, Alexander Graf wrote: Well, we have two groups: 1) Casual user w/o management app 2) Enterprise user w/ management app So I clearly belong to the first group. 3) Developer/power user who knows what he's about. You could simply add -cpu qemu64 for those guests tha

Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

On Mon, Dec 21, 2009 at 12:45:26PM +0100, Alexander Graf wrote: > > On 21.12.2009, at 12:38, Michael S. Tsirkin wrote: > > > On Mon, Dec 21, 2009 at 12:22:53PM +0100, Alexander Graf wrote: > >> > >> On 21.12.2009, at 12:18, Michael S. Tsirkin wrote: > >> > >>> On Mon, Dec 21, 2009 at 01:12:26PM

Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

On 12/21/2009 01:18 PM, Michael S. Tsirkin wrote: No, Windows tries to detect changes in your hardware and assumes that if too many things change, you might be a pirate and requires you to phone their offices to re-authenticate. How often does a casual user upgrade his host CPU? I

Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

On 21.12.2009, at 12:38, Michael S. Tsirkin wrote: > On Mon, Dec 21, 2009 at 12:22:53PM +0100, Alexander Graf wrote: >> >> On 21.12.2009, at 12:18, Michael S. Tsirkin wrote: >> >>> On Mon, Dec 21, 2009 at 01:12:26PM +0200, Avi Kivity wrote: On 12/20/2009 07:18 PM, Michael S. Tsirkin wrote:

Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

On Mon, Dec 21, 2009 at 12:22:53PM +0100, Alexander Graf wrote: > > On 21.12.2009, at 12:18, Michael S. Tsirkin wrote: > > > On Mon, Dec 21, 2009 at 01:12:26PM +0200, Avi Kivity wrote: > >> On 12/20/2009 07:18 PM, Michael S. Tsirkin wrote: > >>> > > Hmm, then, shouldn't either kvm or qemu ma

Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

On 12/21/2009 1:12 PM, Avi Kivity wrote: On 12/20/2009 07:18 PM, Michael S. Tsirkin wrote: Hmm, then, shouldn't either kvm or qemu mask features that we do not emulate well enough to make windows not crash? -cpu host does that already, no? Alex I expected so, but Avi here seems to say windo

Re: [Qemu-devel] Re: SVM support in 0.12?

Andre Przywara wrote: Jun Koi wrote: I am running latest Qemu 0.12-rc. My guest VM runs Linux kernel 2.6.31. Because Qemu now supports SVM, I expect to see the SVM flag in /proc/cpuinfo, but that is not the case. So it seems SVM support is not enabled by default configuration?? My host and

[Qemu-devel] [PATCH] PPC64: Fix timebase

On PPC we have a 64-bit time base. Usually (PPC32) this is accessed using two separate 32 bit SPR accesses to SPR_TBU and SPR_TBL. On PPC64 the SPR_TBL register acts as 64 bit though, so we get the full 64 bits as return value. If we only take the lower ones, fine. But Linux wants to see all 64 bi

Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

On 21.12.2009, at 12:18, Michael S. Tsirkin wrote: > On Mon, Dec 21, 2009 at 01:12:26PM +0200, Avi Kivity wrote: >> On 12/20/2009 07:18 PM, Michael S. Tsirkin wrote: >>> > Hmm, then, shouldn't either kvm or qemu mask features that we do not > emulate well enough to make windows not crash

Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

On Mon, Dec 21, 2009 at 01:12:26PM +0200, Avi Kivity wrote: > On 12/20/2009 07:18 PM, Michael S. Tsirkin wrote: >> Hmm, then, shouldn't either kvm or qemu mask features that we do not emulate well enough to make windows not crash? >>> -cpu host does that already, no? >>> >>>

Re: [Qemu-devel] [PATCH] PPC64: Fix timebase

On 21.12.2009, at 10:24, Aurelien Jarno wrote: > On Mon, Dec 21, 2009 at 01:22:12AM +0100, Alexander Graf wrote: >> On PPC we have a 64-bit time base. Usually (PPC32) this is accessed using >> two separate 32 bit SPR accesses to SPR_TBU and SPR_TBL. >> >> On PPC64 the SPR_TBL register acts as 64

Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

On 12/20/2009 07:59 PM, Anthony Liguori wrote: Gleb Natapov wrote: Windows is a mystery box, so we can speculate as much as we want about it. If you don't like something just say "it may break Windows" :) Losing activation does sound like an issue too. Downgrading seems more likely to cause p

Re: [Qemu-devel] [PATCH] PPC64: Fix timebase

On 21.12.2009, at 10:24, Aurelien Jarno wrote: > On Mon, Dec 21, 2009 at 01:22:12AM +0100, Alexander Graf wrote: >> On PPC we have a 64-bit time base. Usually (PPC32) this is accessed using >> two separate 32 bit SPR accesses to SPR_TBU and SPR_TBL. >> >> On PPC64 the SPR_TBL register acts as 64

Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

On 12/20/2009 07:18 PM, Michael S. Tsirkin wrote: Hmm, then, shouldn't either kvm or qemu mask features that we do not emulate well enough to make windows not crash? -cpu host does that already, no? Alex I expected so, but Avi here seems to say windows will crash if you use a n

Re: [Qemu-devel] [PATCH 3/3] linux-user: Initialize Alpha FPCR register.

On Sat, Dec 19, 2009 at 03:17:16PM -0800, Richard Henderson wrote: > Signed-off-by: Richard Henderson > --- > linux-user/main.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/linux-user/main.c b/linux-user/main.c > index 12502ad..b67662c 100644 > --- a/linux-user/

Re: [Qemu-devel] Re: SVM support in 0.12?

Jun Koi wrote: I am running latest Qemu 0.12-rc. My guest VM runs Linux kernel 2.6.31. Because Qemu now supports SVM, I expect to see the SVM flag in /proc/cpuinfo, but that is not the case. So it seems SVM support is not enabled by default configuration?? My host and guest are both 32 bit Li

Re: [Qemu-devel] [PATCH] PPC64: Fix timebase

On Mon, Dec 21, 2009 at 10:39:39AM +0100, Alexander Graf wrote: > > On 21.12.2009, at 10:24, Aurelien Jarno wrote: > > > On Mon, Dec 21, 2009 at 01:22:12AM +0100, Alexander Graf wrote: > >> On PPC we have a 64-bit time base. Usually (PPC32) this is accessed using > >> two separate 32 bit SPR acce

Re: [Qemu-devel] [PATCH 0/5] tcg conditional set, round 4

On Sun, Dec 20, 2009 at 06:00:48PM -0800, Richard Henderson wrote: > On 12/20/2009 02:57 PM, Paul Brook wrote: >> On Saturday 19 December 2009, Richard Henderson wrote: >>> Changes from round 3: >>> >>> * Drop movcond for now. >>> * Only use movzbl and not xor in setcond. >> >> I'm still catchi

Re: [Qemu-devel] Re: SVM support in 0.12?

On Sat, Dec 19, 2009 at 2:34 AM, Alexander Graf wrote: > > Am 18.12.2009 um 17:52 schrieb Jun Koi : > >> On Fri, Dec 18, 2009 at 8:35 PM, Alexander Graf wrote: >>> >>> Am 18.12.2009 um 03:39 schrieb Jun Koi >>> On Fri, Dec 18, 2009 at 11:37 AM, Jun Koi wrote: > > Hi, > > I

[Qemu-devel] Re: [PATCH 0/5] tcg conditional set, round 4

On Mon, Dec 21, 2009 at 10:47 AM, Paolo Bonzini wrote: > On 12/21/2009 10:13 AM, Laurent Desnogues wrote: >> >> Which front-ends would need it and would the cost to generate >> code for it on some (most?) back-ends be amortized? > > The ARM front-end could definitely use a backend's ability to do

[Qemu-devel] Re: [PATCH 0/5] tcg conditional set, round 4

On 12/21/2009 10:13 AM, Laurent Desnogues wrote: Which front-ends would need it and would the cost to generate code for it on some (most?) back-ends be amortized? The ARM front-end could definitely use a backend's ability to do predication (via movcond). Paolo

Re: [Qemu-devel] [PATCH] PPC64: Fix timebase

On 21.12.2009, at 10:24, Aurelien Jarno wrote: > On Mon, Dec 21, 2009 at 01:22:12AM +0100, Alexander Graf wrote: >> On PPC we have a 64-bit time base. Usually (PPC32) this is accessed using >> two separate 32 bit SPR accesses to SPR_TBU and SPR_TBL. >> >> On PPC64 the SPR_TBL register acts as 64

[Qemu-devel] Re: [ANNOUNCE] qemu-kvm-0.12.0-rc2 released

On 12/21/2009 05:39 AM, Dustin Kirkland wrote: What about the qemu-system-arm build break I also mentioned? That's currently blocking my packaging. I'm looking into it, though of course patches are welcome as usual. -- error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH] PPC64: Fix timebase

On Mon, Dec 21, 2009 at 01:22:12AM +0100, Alexander Graf wrote: > On PPC we have a 64-bit time base. Usually (PPC32) this is accessed using > two separate 32 bit SPR accesses to SPR_TBU and SPR_TBL. > > On PPC64 the SPR_TBL register acts as 64 bit though, so we get the full > 64 bits as return val

Re: [Qemu-devel] [PATCH 0/5] tcg conditional set, round 4

On Mon, Dec 21, 2009 at 3:00 AM, Richard Henderson wrote: [...] > I *am* convinced that to remove either VTRUE or VFALSE as arguments to the > movcond primitive (implementing dest = (cond ? vtrue : dest) would do too > much violence to both the liveness analysis and the register allocator > within

[Qemu-devel] [PATCH] Use vpath directive

The vpath directive has two advantages over the VPATH variable: 1) it allows to skip searching of .o files; 2) the default semantics are to append to the vpath, so there is no confusion between "VPATH=xyz" and "VPATH+=xyz". Since "vpath %.c %.h PATH" is not valid, I'm introducing a wrapper macro t

Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

On 12/21/2009 09:43 AM, Gleb Natapov wrote: On Sun, Dec 20, 2009 at 11:59:43AM -0600, Anthony Liguori wrote: Gleb Natapov wrote: Windows is a mystery box, so we can speculate as much as we want about it. If you don't like something just say "it may break Windows" :) Losing activation does sound

[Qemu-devel] [PATCH 17/19] move vmstate registration of vmstate_timers earlier

Signed-off-by: Paolo Bonzini --- vl.c | 62 +++--- 1 files changed, 31 insertions(+), 31 deletions(-) diff --git a/vl.c b/vl.c index 23ba687..204b6a0 100644 --- a/vl.c +++ b/vl.c @@ -697,36 +697,6 @@ static void icount_adjust_vm(void * op

[Qemu-devel] [PATCH 18/19] introduce qemu_clock_enable

By adding the possibility to turn on/off a clock, yet another incestuous relationship between timers and CPUs can be disentangled. This also needs qemu_run_timers to accept a QEMUClock, and nicely simplifies host_alarm_handler. Signed-off-by: Paolo Bonzini --- vl.c | 32 +-

[Qemu-devel] [PATCH 14/19] disentangle tcg and deadline calculation

Just tell main_loop_wait whether to be blocking or nonblocking, so that there is no need to call qemu_cpus_have_work from the timer subsystem. Instead, tcg_cpu_exec can say "we want the main loop not to block because we have stuff to do". Signed-off-by: Paolo Bonzini --- hw/xenfb.c |6 --

[Qemu-devel] [PATCH 15/19] do not provide qemu_event_increment if iothread not used

host_alarm_handler is using qemu_event_increment instead of qemu_notify_event. After fixing this, the whole event business can be omitted if not using the iothread. Signed-off-by: Paolo Bonzini --- vl.c | 130 -- 1 files changed, 6

[Qemu-devel] [PATCH 13/19] move tcg_has_work to cpu-exec.c and rename it

tcg_has_work is the only user of cpu-exec.c's qemu_cpu_has_work export. Just move everything into cpu-exec.c. Signed-off-by: Paolo Bonzini --- cpu-all.h |2 +- cpu-exec.c | 16 ++-- vl.c | 28 ++-- 3 files changed, 17 insertions(+), 29 deletions

[Qemu-devel] [PATCH 16/19] tweak qemu_notify_event

Instead of testing specially next_cpu in host_alarm_handler, just do that in qemu_notify_event. The idea is, if we are not running (or not yet running) target CPU code, prepare things so that the execution loop is exited asap; just make that clear. Signed-off-by: Paolo Bonzini --- vl.c | 10 +

[Qemu-devel] [PATCH 12/19] new function qemu_icount_delta

Tweaking the rounding in qemu_next_deadline ensures that there's no change whatsoever. Signed-off-by: Paolo Bonzini --- vl.c | 27 --- 1 files changed, 16 insertions(+), 11 deletions(-) diff --git a/vl.c b/vl.c index 289aadc..9f363c8 100644 --- a/vl.c +++ b/vl.c @@ -52

[Qemu-devel] [PATCH 06/19] more alarm timer cleanup

The timer_alarm_pending variable is related to the alarm timer but not placed in the struct. Also, in qemu_mod_timer the wrong flag was being tested: the timer is rearmed in the alarm timer "bottom half", so the right flag to test there is the "pending" flag. Finally, I hoisted the NULL checks fr

[Qemu-devel] [PATCH 10/19] add qemu_bh_scheduled

Signed-off-by: Paolo Bonzini --- async.c |5 + qemu-common.h |2 ++ 2 files changed, 7 insertions(+), 0 deletions(-) diff --git a/async.c b/async.c index 57ac3a8..d58a1d5 100644 --- a/async.c +++ b/async.c @@ -188,6 +188,11 @@ void qemu_bh_cancel(QEMUBH *bh) bh->scheduled

[Qemu-devel] [PATCH 11/19] use a bottom half to run timers

Make the timer subsystem register its own bottom half instead of placing the bottom half code in the heart of the main loop. To test if an alarm timer is pending, just check if the bottom half is scheduled. Signed-off-by: Paolo Bonzini --- vl.c | 68 ---

[Qemu-devel] [PATCH 08/19] move kbd/mouse events to event.c

As a side exercise, move 200 lines out of vl.c already into common code that only needs to be compiled once. Signed-off-by: Paolo Bonzini --- Makefile |2 +- event.c | 238 ++ vl.c | 214 +-

[Qemu-devel] [PATCH 09/19] remove qemu_rearm_alarm_timer from main loop

Make the timer subsystem register its own callback instead. Signed-off-by: Paolo Bonzini --- vl.c |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/vl.c b/vl.c index c32dc5d..78807f5 100644 --- a/vl.c +++ b/vl.c @@ -1421,6 +1421,12 @@ static void win32_rearm_timer(s

[Qemu-devel] [PATCH 05/19] only one flag is needed for alarm_timer

The ALARM_FLAG_DYNTICKS can be testing simply by checking if there is a rearm function. Signed-off-by: Paolo Bonzini --- vl.c | 31 +++ 1 files changed, 15 insertions(+), 16 deletions(-) diff --git a/vl.c b/vl.c index 58e57c1..efffaf1 100644 --- a/vl.c +++ b/vl.c @

[Qemu-devel] [PATCH 07/19] add qemu_get_clock_ns

Some places use get_clock directly because they want to access the rt_clock with nanosecond precision. Add a function to do exactly that instead of using internal interfaces. Signed-off-by: Paolo Bonzini --- qemu-timer.h |1 + vl.c | 21 +++-- 2 files changed, 20 i

[Qemu-devel] [PATCH 04/19] fix error in win32_rearm_timer

The TIME_ONESHOT and TIME_PERIODIC flags are mutually exclusive. The code after the patch matches the flags used in win32_start_timer. Signed-off-by: Paolo Bonzini --- vl.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/vl.c b/vl.c index 22ec53d..58e57c1 100644 --- a/v

  1   2   >