On Fri, Dec 18, 2009 at 12:01:06PM +0100, Gerd Hoffmann wrote:
From: Anthony Liguori aligu...@us.ibm.com
Hi,
Option rom saga continued. This is the first series I consider ready
for merging. Changes:
* pci roms: will be loaded via option pci rom bar.
* non-pci roms: will be
On Fri, Dec 18, 2009 at 12:01:10PM +0100, Gerd Hoffmann wrote:
This patch adds a file transfer interface to fw_cfg. Intended to be
used for passing non-pci option roms and vgabios to seabios. Namespace
is modeled after the existing cbfs filesystem support in seabios.
Reading the new
On Fri, Dec 18, 2009 at 12:01:11PM +0100, Gerd Hoffmann wrote:
roms: use fw_cfg for vgabios and option rom loading, additionally to
deploying them the traditional way (copy to 0xc - 0xe range).
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/loader.c | 25
Kirill A. Shutemov kir...@shutemov.name writes:
lseek(fd, s-refcount_block_offset, SEEK_SET);
-write(fd, s-refcount_block, ref_clusters * s-cluster_size);
+ret = write(fd, s-refcount_block, ref_clusters * s-cluster_size);
+if (ret != s-cluster_size) {
+ret = -errno;
On 12/15/2009 07:56 PM, Michael S. Tsirkin wrote:
I see.
But unfortunately this bit has multiple meanings
for 64/32 bit, kvm does not know whether you will
run a 32 bit or a 64 bit program.
This is a cpu architecture bug.
Correct. One bit is used for two separate features (syscall-32
On 12/14/2009 10:18 PM, 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 bother checking this bit:
AMD +
Am Sonntag, 20. Dezember 2009 02:39 schrieb Kirill A. Shutemov:
CCblock/vvfat.o
cc1: warnings being treated as errors
block/vvfat.c: In function 'commit_one_file':
block/vvfat.c:2259: error: ignoring return value of 'ftruncate', declared
with attribute warn_unused_result
make: ***
On Sat, Dec 19, 2009 at 11:43 PM, malc av1...@comtv.ru wrote:
On Sun, 20 Dec 2009, Aurelien Jarno wrote:
On Sat, Dec 19, 2009 at 10:52:52AM -0800, Richard Henderson wrote:
Changes from round 3:
* Drop movcond for now.
* Only use movzbl and not xor in setcond.
Thanks for the
On Sat, Dec 19, 2009 at 10:52 PM, Richard Henderson r...@twiddle.net wrote:
On 12/19/2009 01:25 PM, Blue Swirl wrote:
On Sat, Dec 19, 2009 at 5:47 PM, Richard Hendersonr...@twiddle.net
wrote:
On 12/19/2009 02:31 AM, Blue Swirl wrote:
static inline void tcg_out_movi_imm32(TCGContext *s,
On Sat, Dec 19, 2009 at 9:08 PM, Richard Henderson r...@twiddle.net wrote:
Here's a split up version of the patch you looked at yesterday.
I was going to apply the patches, but the Signed-off-By line is missing.
On Sun, Dec 20, 2009 at 1:39 AM, Kirill A. Shutemov
kir...@shutemov.name wrote:
Let's fix code instead!
Nice idea. BTW this can't be the first patch in the series, or
bisectability will be broken.
I am really confused wrt stable 0.12 branching policy.
For example I see this, in master:
commit d587e0787153f0224a6140c5015609963ceaabfb
Author: Anthony Liguori aligu...@us.ibm.com
Date: Mon Dec 14 11:36:53 2009 -0600
Revert pci: interrupt disable bit
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 aligu...@us.ibm.com
Date: Mon Dec 14 11:36:53 2009 -0600
Revert pci:
This makes rebuilds after source updates easier
for most users (who don't edit config-devices.mak).
Signed-off-by: Stefan Weil w...@mail.berlios.de
---
Makefile | 20 +++-
1 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/Makefile b/Makefile
index c1fa08c..684365d
Gleb Natapov wrote:
On Fri, Dec 18, 2009 at 12:01:06PM +0100, Gerd Hoffmann wrote:
From: Anthony Liguori aligu...@us.ibm.com
Hi,
Option rom saga continued. This is the first series I consider ready
for merging. Changes:
* pci roms: will be loaded via option pci rom bar.
* non-pci
Avi Kivity wrote:
Maybe we should make -cpu host the default. That will give the best
performance for casual users, more testing for newer features, and
will force management apps to treat migration much more seriously.
The downside is that casual users upgrading their machines might
Stefan Weil wrote:
Hi,
these patches are still missing in QEMU master
(and would also be good for 0.12.x because many
people wait for the multicast fix needed for
junos, see junos qemu eepro100.c at google):
089c60f8e467cfd567a946e005f10559b2fb9462
f925f386761fe1abb82aad8472c6fb388b022756
On Sun, Dec 20, 2009 at 08:43:38AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
On Fri, Dec 18, 2009 at 12:01:06PM +0100, Gerd Hoffmann wrote:
From: Anthony Liguori aligu...@us.ibm.com
Hi,
Option rom saga continued. This is the first series I consider ready
for merging. Changes:
On 12/20/2009 04:48 PM, Anthony Liguori wrote:
Avi Kivity wrote:
Maybe we should make -cpu host the default. That will give the best
performance for casual users, more testing for newer features, and
will force management apps to treat migration much more seriously.
The downside is that
Gleb Natapov wrote:
On Sun, Dec 20, 2009 at 08:43:38AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
On Fri, Dec 18, 2009 at 12:01:06PM +0100, Gerd Hoffmann wrote:
From: Anthony Liguori aligu...@us.ibm.com
Hi,
Option rom saga continued. This is the first series I
Hi,
I'm using Fedora 12 with kernel 2.6.31.6-166.fc12.i686.PAE and with qemu
0.11.0-12.fc12.i686, and I'm not able to start OpenBSD as a guest
operating system. See RedHat's bugzilla #508801.
Based on Fedora's spec file[ref#2] I've created RPM packages from
origin/master
On Sun, Dec 20, 2009 at 08:58:40AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
On Sun, Dec 20, 2009 at 08:43:38AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
On Fri, Dec 18, 2009 at 12:01:06PM +0100, Gerd Hoffmann wrote:
From: Anthony Liguori aligu...@us.ibm.com
Hi,
Option
Gleb Natapov wrote:
On Sun, Dec 20, 2009 at 08:58:40AM -0600, Anthony Liguori wrote:
No. You have to physically shut down and start up again. That's
the right semantics IMHO.
Reset is equivalent (or should be) to shut down and start up again.
Not at all. Reset can happen in a
On 12/20/2009 05:11 PM, Anthony Liguori wrote:
Not at all. Reset can happen in a lot of different ways, some that
there is really no way to detect (jumping right to BIOS vector). From
a hardware perspective, powering down a CPU and powering it on again
behaves very differently than reset
On Sun, Dec 20, 2009 at 09:11:18AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
On Sun, Dec 20, 2009 at 08:58:40AM -0600, Anthony Liguori wrote:
No. You have to physically shut down and start up again. That's
the right semantics IMHO.
Reset is equivalent (or should be) to shut down
The QEMU team is pleased to announce the availability of the 0.12.1.
release. This is the first release of the 0.12 series. 0.12.0 had a
problem with target-arm we felt was important enough but found after
0.12.0 was tagged. This has been fixed for 0.12.1.
This release consists of over
Gleb Natapov wrote:
On Sun, Dec 20, 2009 at 09:11:18AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
On Sun, Dec 20, 2009 at 08:58:40AM -0600, Anthony Liguori wrote:
No. You have to physically shut down and start up again. That's
the right semantics IMHO.
Reset
Avi Kivity wrote:
We should just qemu_ram_alloc() that memory regardless of whether we
every map it into the guest. Since roms can be large, we want to
send their contents over during the live part of migration. If we
use qemu_ram_alloc(), we get that for free.
Currently live migration
Avi Kivity wrote:
On 12/20/2009 04:48 PM, Anthony Liguori wrote:
Avi Kivity wrote:
Maybe we should make -cpu host the default. That will give the best
performance for casual users, more testing for newer features, and
will force management apps to treat migration much more seriously.
The
On Sun, Dec 20, 2009 at 09:28:34AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
On Sun, Dec 20, 2009 at 09:11:18AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
On Sun, Dec 20, 2009 at 08:58:40AM -0600, Anthony Liguori wrote:
No. You have to physically shut down and start up again.
Blue Swirl wrote:
On Fri, Dec 18, 2009 at 11:01 AM, Gerd Hoffmann kra...@redhat.com wrote:
From: Anthony Liguori aligu...@us.ibm.com
Currently, we preload option roms into the option rom space in memory. This
prevents DDIM from functioning correctly which severely limits the number
of roms
On 12/20/2009 05:31 PM, Anthony Liguori wrote:
Avi Kivity wrote:
We should just qemu_ram_alloc() that memory regardless of whether we
every map it into the guest. Since roms can be large, we want to
send their contents over during the live part of migration. If we
use qemu_ram_alloc(), we
On 12/20/2009 05:33 PM, Anthony Liguori wrote:
- casual (non-management-app-using) users will start seeing problems
with Windows guests unless they change their command lines
Assuming their migrating across different CPU types.
I was thinking about upgrading their host cpu. I doubt you'd
On Sun, Dec 20, 2009 at 05:36:57PM +0200, Avi Kivity wrote:
On 12/20/2009 05:33 PM, Anthony Liguori wrote:
- casual (non-management-app-using) users will start seeing
problems with Windows guests unless they change their command
lines
Assuming their migrating across different CPU types.
On 12/20/2009 05:38 PM, Gleb Natapov wrote:
I was thinking about upgrading their host cpu. I doubt you'd live
migrate without a management app.
And what about VM on disk-on-key or VM image on NFS that can be started
from different locations?
That needs a config file anyway to
Anthony Liguori schrieb:
Stefan Weil wrote:
Hi,
these patches are still missing in QEMU master
(and would also be good for 0.12.x because many
people wait for the multicast fix needed for
junos, see junos qemu eepro100.c at google):
089c60f8e467cfd567a946e005f10559b2fb9462
On Sun, Dec 20, 2009 at 09:39:38AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
More importantly though, what's the use-case here?
Use-case for what? This just what need to be done for correct HW
emulation.
Live migration is transparent to the guest. The fact that firmware
can
On Sun, Dec 20, 2009 at 05:40:53PM +0200, Avi Kivity wrote:
On 12/20/2009 05:38 PM, Gleb Natapov wrote:
I was thinking about upgrading their host cpu. I doubt you'd live
migrate without a management app.
And what about VM on disk-on-key or VM image on NFS that can be started
from
Handling of transmit commands is rather complex,
so about 80 lines of code were moved from function
action_command to the new function tx_command.
The two new values tx and cb_address in the
eepro100 status structure made this possible without
passing too many parameters.
In addition, the moved
Michael S. Tsirkin suggested more documentation for
two temporary status values. Well, here it is.
Signed-off-by: Stefan Weil w...@mail.berlios.de
---
hw/eepro100.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/hw/eepro100.c b/hw/eepro100.c
index 5635f61..fb455a4
* Handling of multicast list was missing.
* Multicast all was missing.
* Promiscuous mode for multicast frames was wrong.
This patch is a step to synchronize my maintainer version
of eepro100.c (git://repo.or.cz/qemu/ar7.git) with the
version integrated in QEMU.
Signed-off-by: Stefan Weil
On 12/20/2009 05:49 PM, Michael S. Tsirkin wrote:
That needs a config file anyway to let the host qemu know which machine
level (e.g. -M pc-0.11) to use.
Hmm, yes, but will qemu ship config files which configure host cpu
as well?
If it doesn't, the management app will have to to
On Sun, Dec 20, 2009 at 11:49:40AM +0200, Avi Kivity wrote:
On 12/14/2009 10:18 PM, 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
On 12/20/2009 05:51 PM, Michael S. Tsirkin wrote:
Maybe we should make -cpu host the default. That will give the best
performance for casual users, more testing for newer features, and will
force management apps to treat migration much more seriously. The
downside is that casual users
On Sun, Dec 20, 2009 at 3:52 PM, Gleb Natapov g...@redhat.com wrote:
On Sun, Dec 20, 2009 at 09:39:38AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
More importantly though, what's the use-case here?
Use-case for what? This just what need to be done for correct HW
emulation.
Live
On Sun, Dec 20, 2009 at 04:08:32PM +, Blue Swirl wrote:
On Sun, Dec 20, 2009 at 3:52 PM, Gleb Natapov g...@redhat.com wrote:
On Sun, Dec 20, 2009 at 09:39:38AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
More importantly though, what's the use-case here?
Use-case for what?
Stefan Weil wrote:
Anthony Liguori schrieb:
Stefan Weil wrote:
Hi,
these patches are still missing in QEMU master
(and would also be good for 0.12.x because many
people wait for the multicast fix needed for
junos, see junos qemu eepro100.c at google):
2009/12/20 Gleb Natapov g...@redhat.com:
On Sun, Dec 20, 2009 at 04:08:32PM +, Blue Swirl wrote:
On Sun, Dec 20, 2009 at 3:52 PM, Gleb Natapov g...@redhat.com wrote:
On Sun, Dec 20, 2009 at 09:39:38AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
More importantly though, what's the
Hello,
Am 20.12.2009 um 16:52 schrieb Stefan Weil:
Michael S. Tsirkin suggested more documentation for
two temporary status values. Well, here it is.
Signed-off-by: Stefan Weil w...@mail.berlios.de
---
hw/eepro100.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git
On 12/15/2009 05:21 PM, Dustin Kirkland wrote:
- fetch the submodules and include them in the tarball
...
I think this option would help keep us all on the same page. But I
could live with pointers to the submodules, since packaging a new
release only happens a couple of times per
On Sun, Dec 20, 2009 at 05:59:33PM +0200, Avi Kivity wrote:
On 12/20/2009 05:51 PM, Michael S. Tsirkin wrote:
Maybe we should make -cpu host the default. That will give the best
performance for casual users, more testing for newer features, and will
force management apps to treat migration
On Sun, Dec 20, 2009 at 3:34 PM, Anthony Liguori anth...@codemonkey.ws wrote:
Blue Swirl wrote:
On Fri, Dec 18, 2009 at 11:01 AM, Gerd Hoffmann kra...@redhat.com wrote:
From: Anthony Liguori aligu...@us.ibm.com
Currently, we preload option roms into the option rom space in memory.
This
On 20.12.2009, at 17:56, Michael S. Tsirkin wrote:
On Sun, Dec 20, 2009 at 05:59:33PM +0200, Avi Kivity wrote:
On 12/20/2009 05:51 PM, Michael S. Tsirkin wrote:
Maybe we should make -cpu host the default. That will give the best
performance for casual users, more testing for newer
On 20.12.2009, at 18:02, Blue Swirl wrote:
On Sun, Dec 20, 2009 at 3:34 PM, Anthony Liguori anth...@codemonkey.ws
wrote:
Blue Swirl wrote:
On Fri, Dec 18, 2009 at 11:01 AM, Gerd Hoffmann kra...@redhat.com wrote:
From: Anthony Liguori aligu...@us.ibm.com
Currently, we preload
On Sun, Dec 20, 2009 at 06:17:02PM +0100, Alexander Graf wrote:
On 20.12.2009, at 17:56, Michael S. Tsirkin wrote:
On Sun, Dec 20, 2009 at 05:59:33PM +0200, Avi Kivity wrote:
On 12/20/2009 05:51 PM, Michael S. Tsirkin wrote:
Maybe we should make -cpu host the default. That will give
On 20.12.2009, at 18:18, Michael S. Tsirkin wrote:
On Sun, Dec 20, 2009 at 06:17:02PM +0100, Alexander Graf wrote:
On 20.12.2009, at 17:56, Michael S. Tsirkin wrote:
On Sun, Dec 20, 2009 at 05:59:33PM +0200, Avi Kivity wrote:
On 12/20/2009 05:51 PM, Michael S. Tsirkin wrote:
Maybe we
On Sun, Dec 20, 2009 at 07:18:22PM +0200, Michael S. Tsirkin wrote:
On Sun, Dec 20, 2009 at 06:17:02PM +0100, Alexander Graf wrote:
On 20.12.2009, at 17:56, Michael S. Tsirkin wrote:
On Sun, Dec 20, 2009 at 05:59:33PM +0200, Avi Kivity wrote:
On 12/20/2009 05:51 PM, Michael S.
On 20.12.2009, at 18:23, Gleb Natapov wrote:
On Sun, Dec 20, 2009 at 07:18:22PM +0200, Michael S. Tsirkin wrote:
On Sun, Dec 20, 2009 at 06:17:02PM +0100, Alexander Graf wrote:
On 20.12.2009, at 17:56, Michael S. Tsirkin wrote:
On Sun, Dec 20, 2009 at 05:59:33PM +0200, Avi Kivity wrote:
On Sun, Dec 20, 2009 at 06:29:11PM +0100, Alexander Graf wrote:
On 20.12.2009, at 18:23, Gleb Natapov wrote:
On Sun, Dec 20, 2009 at 07:18:22PM +0200, Michael S. Tsirkin wrote:
On Sun, Dec 20, 2009 at 06:17:02PM +0100, Alexander Graf wrote:
On 20.12.2009, at 17:56, Michael S. Tsirkin
Gleb Natapov wrote:
It's not a matter of correctness IMHO.
Ah now I see what you mean. New FW has to be used after reboot because old
one may not be able to init HW any longer.
I think we have two ways to view firmware. The first would be to treat
guest firmware as part of the guest.
Alexander Graf wrote:
Don't macs usually have a powerpc vgabios?
I'm not certain, but this is what x86emu is for in X11.
VGA is a PC concept and just about nothing about it really make sense on
a different architecture. The interface is an extension of the PC BIOS
(software interrupts)
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 problems. Considering running
mplayer in a
On 20.12.2009, at 18:55, Anthony Liguori wrote:
Alexander Graf wrote:
Don't macs usually have a powerpc vgabios?
I'm not certain, but this is what x86emu is for in X11.
VGA is a PC concept and just about nothing about it really make sense on a
different architecture. The interface is
Andreas Färber schrieb:
Hello,
Am 20.12.2009 um 16:52 schrieb Stefan Weil:
Michael S. Tsirkin suggested more documentation for
two temporary status values. Well, here it is.
Signed-off-by: Stefan Weil w...@mail.berlios.de
---
hw/eepro100.c |7 ---
1 files changed, 4
On 20.12.2009, at 18:59, 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
I see that you applied Dave's series, no worries on that, but I think we
really want the following, since a clever enough malicious guest can
probably turn the overrun into code execution in the host QEMU (though
I've not tried writing an exploit or anything like that)... not sure if
this merits
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 like an issue too.
Downgrading seems
On 12/18/2009 07:59 PM, Andreas Färber wrote:
Think of my porposed Makefile patch!
Which one?
Paolo
Am 20.12.2009 um 19:01 schrieb Alexander Graf:
On 20.12.2009, at 18:55, Anthony Liguori wrote:
Alexander Graf wrote:
Don't macs usually have a powerpc vgabios?
I'm not certain, but this is what x86emu is for in X11.
VGA is a PC concept and just about nothing about it really make
sense
Am 20.12.2009 um 19:22 schrieb Paolo Bonzini:
On 12/18/2009 07:59 PM, Andreas Färber wrote:
Think of my porposed Makefile patch!
Which one?
In particular my add-on patch for libuser.a, which tackled exactly
that issue:
http://www.mail-archive.com/qemu-devel@nongnu.org/msg20948.html
On 12/20/2009 07:30 PM, Andreas Färber wrote:
Am 20.12.2009 um 19:22 schrieb Paolo Bonzini:
On 12/18/2009 07:59 PM, Andreas Färber wrote:
Think of my porposed Makefile patch!
Which one?
In particular my add-on patch for libuser.a, which tackled exactly that
issue:
On Sun, Dec 20, 2009 at 6:24 PM, Andreas Färber andreas.faer...@web.de wrote:
Am 20.12.2009 um 19:01 schrieb Alexander Graf:
On 20.12.2009, at 18:55, Anthony Liguori wrote:
Alexander Graf wrote:
Don't macs usually have a powerpc vgabios?
I'm not certain, but this is what x86emu is for
Am 20.12.2009 um 19:38 schrieb Paolo Bonzini:
On 12/20/2009 07:30 PM, Andreas Färber wrote:
Am 20.12.2009 um 19:22 schrieb Paolo Bonzini:
On 12/18/2009 07:59 PM, Andreas Färber wrote:
Think of my porposed Makefile patch!
Which one?
In particular my add-on patch for libuser.a, which
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 M68K support or PPC Support and how far is it
from being included in a stable Qemu release,I notice Power PC
On Sun, 2009-12-20 at 19:01 +0100, Alexander Graf wrote:
Yes. The Alpha for example used stock VGABIOSes. IIRC Sparc has its
own graphics anyways and I don't know about the others, but I suspect
they either use x86 VGABIOSes or no VGABIOSes.
Macs are different though. IIRC they have a
On Sun, 2009-12-20 at 18:53 +, Blue Swirl wrote:
Some Sun machines also had ATY,Rage XL cards but I don't know if
they had special roms.
They would have similar f-code to the mac ones (ie. Tokenized forth for
Open Firmware).
However, in the case of qemu, I don't see much point in doing
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 M68K support or PPC Support and how far is it
from being included
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 catching up on mail backlog from this thread, but I'm concerned that
we're exposing setcond to the target translation code if we're
--- a/posix-aio-compat.c
+++ b/posix-aio-compat.c
@@ -502,7 +502,8 @@ static void aio_signal_handler(int signum)
if (posix_aio_state) {
char byte = 0;
- write(posix_aio_state-wfd, byte, sizeof(byte));
+ if (write(posix_aio_state-wfd, byte, sizeof(byte)) != sizeof(byte))
+
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
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. What that means it that we should
store all firmware in an nvram file, migrate the nvram file during
migration
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 catching up on mail backlog from this thread, but I'm concerned that
we're exposing setcond
On Sun, Dec 20, 2009 at 10:25 AM, Avi Kivity a...@redhat.com wrote:
On 12/15/2009 05:21 PM, Dustin Kirkland wrote:
- fetch the submodules and include them in the tarball
...
I think this option would help keep us all on the same page. But I
could live with pointers to the submodules,
This adds definitions for contemporary processors
which may be selected via -cpu model, as an
alternative to the existing use of -cpu qemu64
augmented with a series of feature flags.
The primary motivation was determination of a
least common denominator within a given processor
class for
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. What that means it that we should
store all
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 and reset.
It's not and it will never be completely.
There are always
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 like an issue too.
Downgrading seems more
On Sun, Dec 20, 2009 at 07:06:03PM +0100, Alexander Graf wrote:
On 20.12.2009, at 18:59, 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
88 matches
Mail list logo
