Avi Kivity wrote:
On 12/14/2009 04:06 PM, Anthony Liguori wrote:
The QEMU team is pleased to announce the availability of the 0.12.0-rc2
release. This is the second release candidate for the 0.12.0 release.
This release is not intended for production use.
I'm missing the tag for this release?
On Mon, 2009-12-14 at 15:10 +, Daniel P. Berrange wrote:
> The model I had in mind was for the proxy to define a VNC extension that
> allows the client to query what 'desktops' are available and request
> switching between them at any time. The list of desktop would of course
> be authorized p
One of the other folks here (I'm sorry, I've forgotten who as I
misplaced the mail) passed me a preliminary patch to tackle the missing
fp rounding mode support. That patch added helpers to change the
rounding mode, and injected them before and after every fp insn that
forced a rounding mode.
On 11 Dec 2009, at 13:19, Daniel P. Berrange wrote:
> On Wed, Dec 09, 2009 at 01:10:18PM -0800, Andrew Farmer wrote:
>> Right now, if an incoming migrate through exec fails, the qemu process
>> will end up chewing CPU indefinitely - it looks like it closes the
>> migration FD but doesn't remove i
Anthony Liguori wrote:
Michael S. Tsirkin wrote:
Further, we should error out when device is added.
Doing this during boot is way too late, management
won't be able to understand such errors and
won't be able to recover.
I don't quite understand this.
In 0.11, we never loaded option roms
On Mon, Dec 14, 2009 at 06:18:29PM +0100, Gerd Hoffmann wrote:
> On 12/14/09 17:23, Michael S. Tsirkin wrote:
>> On Mon, Dec 14, 2009 at 04:01:33PM +0100, Gerd Hoffmann wrote:
>> So how do you do this?
>> Assume we have -disable_hw_csum.
>> We want new machine type to have it off, right?
>> But now
On Mon, Dec 14, 2009 at 08:12:48PM +0100, Sebastian Herbszt wrote:
> Anthony Liguori wrote:
>> Michael S. Tsirkin wrote:
>>>
>>> Further, we should error out when device is added.
>>> Doing this during boot is way too late, management
>>> won't be able to understand such errors and
>>> won't be abl
On Mon, Dec 14, 2009 at 12:37:29PM +0100, Gerd Hoffmann wrote:
> On 12/14/09 12:10, Michael S. Tsirkin wrote:
>> On Mon, Dec 14, 2009 at 11:24:41AM +0100, Gerd Hoffmann wrote:
>> for block:
>> if (strcmp(s->serial_str, "0"))
>> features |= 1<< VIRTIO_BLK_F_IDENTIFY;
>>
>> if (bd
Sebastian Herbszt wrote:
Anthony Liguori wrote:
Michael S. Tsirkin wrote:
Further, we should error out when device is added.
Doing this during boot is way too late, management
won't be able to understand such errors and
won't be able to recover.
I don't quite understand this.
In 0.11, we
Hi!
I have a linux guest where init crashes during boot with invalid opcode error
with kernel 2.6.31, but works fine with kernel 2.6.32.
It also works fine even with 2.6.31 with qemu-kvm.
With Gleb's help, we figured out that the opcode in question is syscall, which
is unsupported by hardware on k
Michael S. Tsirkin wrote:
On Mon, Dec 14, 2009 at 08:12:48PM +0100, Sebastian Herbszt wrote:
Anthony Liguori wrote:
Michael S. Tsirkin wrote:
Further, we should error out when device is added.
Doing this during boot is way too late, management
won't be able to understand such errors and
won't
Michael S. Tsirkin wrote:
Hi!
I have a linux guest where init crashes during boot with invalid opcode error
with kernel 2.6.31, but works fine with kernel 2.6.32.
It also works fine even with 2.6.31 with qemu-kvm.
With Gleb's help, we figured out that the opcode in question is syscall, which
is
On Mon, Dec 14, 2009 at 01:33:50PM -0600, Anthony Liguori wrote:
> Sebastian Herbszt wrote:
>> Anthony Liguori wrote:
>>> Michael S. Tsirkin wrote:
Further, we should error out when device is added.
Doing this during boot is way too late, management
won't be able to understand s
On Mon, Dec 14, 2009 at 01:44:22PM -0600, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>> Hi!
>> I have a linux guest where init crashes during boot with invalid opcode error
>> with kernel 2.6.31, but works fine with kernel 2.6.32.
>> It also works fine even with 2.6.31 with qemu-kvm.
>>
>>
Michael S. Tsirkin wrote:
On Mon, Dec 14, 2009 at 01:44:22PM -0600, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
Hi!
I have a linux guest where init crashes during boot with invalid opcode error
with kernel 2.6.31, but works fine with kernel 2.6.32.
It also works fine even with 2.6.
Michael S. Tsirkin wrote:
At some level this is wrong. ROM presence is a hardware feature and you
definitely need to select your hardware when you create a VM. For real
hardware, cards with PXE are sometimes more expensive than without as
they need ROM memory. People do select hardware based on
On Mon, Dec 14, 2009 at 01:57:29PM -0600, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
> >On Mon, Dec 14, 2009 at 01:44:22PM -0600, Anthony Liguori wrote:
> >>Michael S. Tsirkin wrote:
> >>>Hi!
> >>>I have a linux guest where init crashes during boot with invalid opcode
> >>>error
> >>>with
Anthony Liguori wrote:
Sebastian Herbszt wrote:
Anthony Liguori wrote:
Michael S. Tsirkin wrote:
Further, we should error out when device is added.
Doing this during boot is way too late, management
won't be able to understand such errors and
won't be able to recover.
I don't quite under
Gleb Natapov wrote:
I thought KVM emulates the syscall instruction? I swear I've seen
patches for that.
It is. Starting from 2.6.32.
Okay, so this is a performance vs. migration compatibility issue then?
BTW, couldn't we just not advertise syscall in cpuid? That should fix
it too
On Mon, Dec 14, 2009 at 02:02:03PM -0600, Anthony Liguori wrote:
> Gleb Natapov wrote:
> >>I thought KVM emulates the syscall instruction? I swear I've seen
> >>patches for that.
> >>
> >It is. Starting from 2.6.32.
>
> Okay, so this is a performance vs. migration compatibility issue then?
>
> B
On Mon, Dec 14, 2009 at 7:02 PM, Richard Henderson wrote:
> One of the other folks here (I'm sorry, I've forgotten who as I misplaced
> the mail) passed me a preliminary patch to tackle the missing fp rounding
> mode support. That patch added helpers to change the rounding mode, and
> injected th
On Mon, Dec 14, 2009 at 02:02:03PM -0600, Anthony Liguori wrote:
> Gleb Natapov wrote:
>>> I thought KVM emulates the syscall instruction? I swear I've seen
>>> patches for that.
>>>
>>>
>> It is. Starting from 2.6.32.
>>
>
> Okay, so this is a performance vs. migration compatibility issue
On Mon, Dec 14, 2009 at 10:08:38PM +0200, Gleb Natapov wrote:
> On Mon, Dec 14, 2009 at 02:02:03PM -0600, Anthony Liguori wrote:
> > Gleb Natapov wrote:
> > >>I thought KVM emulates the syscall instruction? I swear I've seen
> > >>patches for that.
> > >>
> > >It is. Starting from 2.6.32.
> >
> >
Michael S. Tsirkin wrote:
This might help 32 bit guests, but not guests with 64 bit
kernel and 32 bit userspace (my case) because all 64 bit
CPUs advertise syscall bit in cpuid. Thus 64 bit guests
do not seem to even bother checking this bit:
AMD + 64 bit -> syscall.
Okay, I don't see a grea
This violates the RFB specification (section 6.6.4). It happens to work with
most clients but it's still wrong.
Reported-by: Yaniv Kaul
Signed-off-by: Anthony Liguori
---
vnchextile.h |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/vnchextile.h b/vnchextile.h
index
On Mon, Dec 14, 2009 at 01:59:47PM -0600, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>> At some level this is wrong. ROM presence is a hardware feature and you
>> definitely need to select your hardware when you create a VM. For real
>> hardware, cards with PXE are sometimes more expensive
On 12/14/09 21:20, Michael S. Tsirkin wrote:
So far, it's not clear to me that anyone has demonstrated how this is
harmful for people that don't want pxe booting. Assuming we fix the bug
about rom loading, then there's really no impact to users.
Fix (v2) is on the list already.
PXE booting m
On Mon, Dec 14, 2009 at 02:18:33PM -0600, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>> This might help 32 bit guests, but not guests with 64 bit
>> kernel and 32 bit userspace (my case) because all 64 bit
>> CPUs advertise syscall bit in cpuid. Thus 64 bit guests
>> do not seem to even bot
On Mon, Dec 14, 2009 at 09:32:30PM +0100, Gerd Hoffmann wrote:
> On 12/14/09 21:20, Michael S. Tsirkin wrote:
>>> So far, it's not clear to me that anyone has demonstrated how this is
>>> harmful for people that don't want pxe booting. Assuming we fix the bug
>>> about rom loading, then there's re
On Mon, Dec 14, 2009 at 10:34:28PM +0200, Michael S. Tsirkin wrote:
> On Mon, Dec 14, 2009 at 09:32:30PM +0100, Gerd Hoffmann wrote:
> > On 12/14/09 21:20, Michael S. Tsirkin wrote:
> >>> So far, it's not clear to me that anyone has demonstrated how this is
> >>> harmful for people that don't want
Gerd Hoffmann wrote:
On 12/14/09 21:20, Michael S. Tsirkin wrote:
So far, it's not clear to me that anyone has demonstrated how this is
harmful for people that don't want pxe booting. Assuming we fix the bug
about rom loading, then there's really no impact to users.
Fix (v2) is on the list al
On 12/14/09 20:17, Michael S. Tsirkin wrote:
On Mon, Dec 14, 2009 at 06:18:29PM +0100, Gerd Hoffmann wrote:
On 12/14/09 17:23, Michael S. Tsirkin wrote:
On Mon, Dec 14, 2009 at 04:01:33PM +0100, Gerd Hoffmann wrote:
So how do you do this?
Assume we have -disable_hw_csum.
We want new machine typ
-device 'virtio-blk-pci,disable=blk-identify|ring-indirect'
The driver will just do 'vdev->host_features&= ~disable'.
cheers,
Gerd
Is there an example of an existing property that is like this?
No. A new property type is needed for this.
cheers,
Gerd
Michael S. Tsirkin wrote:
On Mon, Dec 14, 2009 at 09:32:30PM +0100, Gerd Hoffmann wrote:
On 12/14/09 21:20, Michael S. Tsirkin wrote:
So far, it's not clear to me that anyone has demonstrated how this is
harmful for people that don't want pxe booting. Assuming we fix the bug
about rom
Michael S. Tsirkin wrote:
Or, we could have a very small ROM, that loads
more actual code from card or from qemu directly
when it is run.
It's not as simple as it sounds but it's possible, in theory at least.
But I think the question really is, what problem are we trying to solve?
Regards,
On Mon, Dec 14, 2009 at 09:40:28PM +0100, Gerd Hoffmann wrote:
> On 12/14/09 20:17, Michael S. Tsirkin wrote:
>> On Mon, Dec 14, 2009 at 06:18:29PM +0100, Gerd Hoffmann wrote:
>>> On 12/14/09 17:23, Michael S. Tsirkin wrote:
On Mon, Dec 14, 2009 at 04:01:33PM +0100, Gerd Hoffmann wrote:
S
Michael S. Tsirkin wrote:
On Mon, Dec 14, 2009 at 09:32:30PM +0100, Gerd Hoffmann wrote:
On 12/14/09 21:20, Michael S. Tsirkin wrote:
So far, it's not clear to me that anyone has demonstrated how this is
harmful for people that don't want pxe booting. Assuming we fix the bug
about rom loading,
On Mon, Dec 14, 2009 at 02:43:38PM -0600, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>> On Mon, Dec 14, 2009 at 09:32:30PM +0100, Gerd Hoffmann wrote:
>>
>>> On 12/14/09 21:20, Michael S. Tsirkin wrote:
>>>
> So far, it's not clear to me that anyone has demonstrated how this is
This small series contains some QMP related fixes.
Thanks.
Key replacement should not update the dictionary's size.
This commit also adds a test for the bug.
Signed-off-by: Luiz Capitulino
---
check-qdict.c |2 ++
qdict.c |3 +--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/check-qdict.c b/check-qdict.c
index c37d448..f2
Monitor's eject command uses 'filename' for the device name
argument, but 'device' is a better name.
Signed-off-by: Luiz Capitulino
---
monitor.c |2 +-
qemu-monitor.hx |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/monitor.c b/monitor.c
index d97d529..d5041d
do_balloon() should check for ballooning availability as
do_info_balloon() does.
Noted by Daniel P. Berrange .
Signed-off-by: Luiz Capitulino
---
monitor.c | 35 ++-
1 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/monitor.c b/monitor.c
index d50
The monitor_read_command() function is readline specific
and should only be used when readline is available.
Signed-off-by: Luiz Capitulino
---
monitor.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/monitor.c b/monitor.c
index 920ccff..b518cc4 100644
--- a/monitor.c
The monitor_vprintf() function now touches the 'mon' pointer
before calling monitor_puts(), this causes block migration
to segfault as its functions call monitor_printf() with a
NULL 'mon'.
To fix the problem this commit moves the 'mon' NULL check
from monitor_puts() to monitor_vprintf().
This ca
On Mon, Dec 14, 2009 at 02:44:34PM -0600, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>> Or, we could have a very small ROM, that loads
>> more actual code from card or from qemu directly
>> when it is run.
>>
>
> It's not as simple as it sounds but it's possible, in theory at least.
>
>
Michael S. Tsirkin wrote:
On Mon, Dec 14, 2009 at 02:18:33PM -0600, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
This might help 32 bit guests, but not guests with 64 bit
kernel and 32 bit userspace (my case) because all 64 bit
CPUs advertise syscall bit in cpuid. Thus 64 bit guests
Sebastian Herbszt wrote:
Some DOS-based software might need the UMA (RAM UMB).
I don't think that's the workload to optimize for in terms of the
default settings. Certainly, it's important to allow such workloads to
disable all unnecessary rom loading but I don't think it's justification
fo
Michael S. Tsirkin wrote:
On Mon, Dec 14, 2009 at 02:43:38PM -0600, Anthony Liguori wrote:
Because it can be selected by the user via the menu and because it can
be selected at runtime via the boot_set monitor command.
Yes, but it's not like we have nowhere to store them.
We could sha
On 12/14/09 21:43, Michael S. Tsirkin wrote:
What do we put in e.g. 0.11 compat? Any features we enable
there might not be supported by host.
compat properties as usual?
Sorry, I still fail to see your problem.
You'll have a 'disable' bitmap. Fill it via 'features='.
Or using separate prope
On Mon, Dec 14, 2009 at 02:54:49PM -0600, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>> On Mon, Dec 14, 2009 at 02:18:33PM -0600, Anthony Liguori wrote:
>>
>>> Michael S. Tsirkin wrote:
>>>
This might help 32 bit guests, but not guests with 64 bit
kernel and 32 bit userspa
On Mon, Dec 14, 2009 at 10:12:14PM +0100, Gerd Hoffmann wrote:
> On 12/14/09 21:43, Michael S. Tsirkin wrote:
>> What do we put in e.g. 0.11 compat? Any features we enable
>> there might not be supported by host.
>
> compat properties as usual?
>
> Sorry, I still fail to see your problem.
>
> You'l
On 12/14/09 22:14, Michael S. Tsirkin wrote:
On Mon, Dec 14, 2009 at 10:12:14PM +0100, Gerd Hoffmann wrote:
On 12/14/09 21:43, Michael S. Tsirkin wrote:
What do we put in e.g. 0.11 compat? Any features we enable
there might not be supported by host.
compat properties as usual?
Sorry, I still
The application is not very useful once the guest window is closed.
QEMU is not a document-based application; terminating it automatically
saves the user another action and resembles SDL behavior.
v2:
- Use delegate method, suggested by Juha Riihimäki.
Signed-off-by: Andreas Färber
Cc: Juha Riih
Hi,
Am 14.12.2009 um 08:04 schrieb >:
On Dec 13, 2009, at 04:55, ext Andreas Färber wrote:
The application is not very useful once the guest window is closed.
QEMU is not a document-based application; terminating it
automatically
saves the user another action and resembles SDL behavior.
Anthony Liguori wrote:
Michael S. Tsirkin wrote:
On Mon, Dec 14, 2009 at 02:43:38PM -0600, Anthony Liguori wrote:
Because it can be selected by the user via the menu and because it can
be selected at runtime via the boot_set monitor command.
Yes, but it's not like we have nowhere to
Michael S. Tsirkin wrote:
On Mon, Dec 14, 2009 at 02:54:49PM -0600, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
On Mon, Dec 14, 2009 at 02:18:33PM -0600, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
This might help 32 bit guests, but not guests with 64
Sebastian Herbszt wrote:
Anthony Liguori wrote:
Michael S. Tsirkin wrote:
On Mon, Dec 14, 2009 at 02:43:38PM -0600, Anthony Liguori wrote:
Because it can be selected by the user via the menu and because it
can be selected at runtime via the boot_set monitor command.
Yes, but it's not
On Mon, Dec 14, 2009 at 12:33 PM, Avi Kivity wrote:
> qemu-kvm-0.12.0-rc2 is now available. This release is is based on the
> upstream qemu 0.12.0-rc2, plus kvm-specific enhancements. Please see the
> original qemu 0.12.0-rc2 release announcement for details.
>
> This release can be used with th
Make libuser.a depend on $(GENERATED_HEADERS) too so make -j won't start
building it before the headers exist. (There may be more bugs like this
but at least this makes (g)make -j4 started from scratch on a quadcore
now always complete here again.)
Signed-off-by: Juergen Lock
--- a/Makefile
+++
Hi!
I updated my git head snapshot qemu-devel port update to 0.12.0-rc2
today (that was just announced:
http://lists.gnu.org/archive/html/qemu-devel/2009-12/msg01514.html
- the Subject says rc1 but in fact its rc2) so people can test that
version on FreeBSD more easily:
http://peo
Anthony Liguori wrote:
Sebastian Herbszt wrote:
Anthony Liguori wrote:
Michael S. Tsirkin wrote:
On Mon, Dec 14, 2009 at 02:43:38PM -0600, Anthony Liguori wrote:
Because it can be selected by the user via the menu and because it
can be selected at runtime via the boot_set monitor command.
On 12/14/2009 12:11 PM, Laurent Desnogues wrote:
I don't really like passing parts of opcodes to helpers, but as you say
that prevents explosion of helpers. OTOH you could do lazy calls to
helpers that set rounding modes with my approach of separating them
from computation.
I don't particularl
On 12/14/2009 12:11 PM, Laurent Desnogues wrote:
I'll take a closer look at your patch tomorrow.
For the record, I believe this finishes what I had in mind for the
exception handling there in op_handler.c.
r~
commit ce6c2abc1d5d437dde980b4addc7da0f0f5de252
Author: Richard Henderson
Date:
We really need compile _all_ sources for user target with -fpie when
use --enable-user-pie.
It's regression introduced by commit add16157d72454.
Please, do not break it any more.
Signed-off-by: Kirill A. Shutemov
Cc: Blue Swirl
---
Makefile.user |4 ++--
configure |1 +
2 files cha
On Tue, Dec 15, 2009 at 12:28 AM, Anthony Liguori wrote:
> Dave Airlie wrote:
>>
>> I actually reinvented at least one of the patches locally and it
>> didn't seem to help,
>> but I'll try and take a closer look today,
>>
>
> http://repo.or.cz/w/qemu/aliguori-queue.git vmware-vga-for-dave
>
> Is t
raise_exception() in op_helper.c should not be used outside
op_helper.c because of tcg. This patch uses raise_exception2() instead
of raise_exception().
target-i386-fix-raise_exception-for-hw-breakpoints.patch
Description: Binary data
Michael S. Tsirkin wrote:
On Mon, Dec 14, 2009 at 02:44:34PM -0600, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
Or, we could have a very small ROM, that loads
more actual code from card or from qemu directly
when it is run.
It's not as simple as it sounds but it's possib
There is now a mailing list for discussions on SeaBIOS. To join the
mailing list, please visit:
http://www.seabios.org/mailman/listinfo/seabios
Mails can be sent to seab...@seabios.org. To reduce spam, non-member
posts to the list will be moderated.
-Kevin
On 12/14/2009 04:31 PM, Richard Henderson wrote:
On 12/14/2009 12:11 PM, Laurent Desnogues wrote:
I'll take a closer look at your patch tomorrow.
For the record, I believe this finishes what I had in mind for the
exception handling there in op_handler.c.
Hmph. One more patch for correctness
On Mon, Dec 14, 2009 at 08:37:44PM -0600, Anthony Liguori wrote:
> Okay, I think I've figured out how this is supposed to work. With these
> two patches to SeaBIOS and the patch to qemu, I can run:
Yes - I think this is the best way to fix this. Space optimizations
can be most easily done by a
On Mon, Dec 14, 2009 at 03:05:22PM -0600, Anthony Liguori wrote:
> I believe the way this works with real BIOSes is that the rom is
> initially loaded somewhere outside of the 1M region and it's init is
> executed. It's then the rom's job to execute it's initialization.
> Afterwards, the bi
On Mon, Dec 14, 2009 at 08:37:44PM -0600, Anthony Liguori wrote:
> Okay, I think I've figured out how this is supposed to work. With these
> two patches to SeaBIOS and the patch to qemu, I can run:
I'm not sure why "Do not guard qemu shadow ram work around in
CONFIG_OPTIONROMS_DEPLOYED" patch i
101 - 172 of 172 matches
Mail list logo
