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
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
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 alw
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 al
This adds definitions for contemporary processors
which may be selected via -cpu , 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 simplification
On Sun, Dec 20, 2009 at 10:25 AM, Avi Kivity 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,
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 to
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 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
> --- 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)) != sizeo
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 p
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 include
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 do
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
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 Suppor
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 ta
On Sun, Dec 20, 2009 at 6:24 PM, Andreas Färber 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 f
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:
http://www.mail-archiv
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
A
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
On 12/18/2009 07:59 PM, Andreas Färber wrote:
Think of my porposed Makefile patch!
Which one?
Paolo
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.
>>
>
> Downgra
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 th
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
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
>> ---
>> hw/eepro100.c |7 ---
>> 1 files changed, 4 insertions(+), 3
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 inte
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 gu
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) an
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.
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, Mic
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
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, Mic
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:
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.
On 20.12.2009, at 18:02, Blue Swirl wrote:
> On Sun, Dec 20, 2009 at 3:34 PM, Anthony Liguori
> wrote:
>> Blue Swirl wrote:
>>>
>>> On Fri, Dec 18, 2009 at 11:01 AM, Gerd Hoffmann wrote:
>>>
From: Anthony Liguori
Currently, we preload option roms into the option rom sp
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
On Sun, Dec 20, 2009 at 3:34 PM, Anthony Liguori wrote:
> Blue Swirl wrote:
>>
>> On Fri, Dec 18, 2009 at 11:01 AM, Gerd Hoffmann wrote:
>>
>>>
>>> From: Anthony Liguori
>>>
>>> Currently, we preload option roms into the option rom space in memory.
>>> This
>>> prevents DDIM from functioning co
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
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 year
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
---
hw/eepro100.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/hw/eepro100.c b/hw/e
2009/12/20 Gleb Natapov :
> On Sun, Dec 20, 2009 at 04:08:32PM +, Blue Swirl wrote:
>> On Sun, Dec 20, 2009 at 3:52 PM, Gleb Natapov 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?
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):
089c60f8e467cfd567a946e005f1055
On Sun, Dec 20, 2009 at 04:08:32PM +, Blue Swirl wrote:
> On Sun, Dec 20, 2009 at 3:52 PM, Gleb Natapov 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
On Sun, Dec 20, 2009 at 3:52 PM, Gleb Natapov 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.
>>
>> Liv
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 upgradi
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 cpui
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 th
* 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
---
h
Michael S. Tsirkin suggested more documentation for
two temporary status values. Well, here it is.
Signed-off-by: Stefan Weil
---
hw/eepro100.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/hw/eepro100.c b/hw/eepro100.c
index 5635f61..fb455a4 100644
--- a/hw/eepr
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 mov
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
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 firmwa
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):
>>
>> 089c60f8e467cfd567a946e005f10559b2fb94
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 let
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
upgrade itself without the guest doing anything is not something
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 differe
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 l
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 ge
Blue Swirl wrote:
On Fri, Dec 18, 2009 at 11:01 AM, Gerd Hoffmann wrote:
From: Anthony Liguori
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 we can support.
This patch introduc
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 st
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
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 uses
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
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 2,00
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) t
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 (c
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 l
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
>
> Hi,
> >>>
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
origin/
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
Hi,
Option rom saga continued. This is the first series I consider ready
for merging
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 ca
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
> >>
> >> Hi,
> >>
> >>Option rom saga continued. This is the first series I consider ready
> >>for merging. Changes
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
5a8
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
exper
Gleb Natapov wrote:
On Fri, Dec 18, 2009 at 12:01:06PM +0100, Gerd Hoffmann wrote:
From: Anthony Liguori
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 loaded
This makes rebuilds after source updates easier
for most users (who don't edit config-devices.mak).
Signed-off-by: Stefan Weil
---
Makefile | 20 +++-
1 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/Makefile b/Makefile
index c1fa08c..684365d 100644
--- a/Makefil
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: Mon Dec 14 11:36:53 2009 -0600
Revert "pci: interrupt disable
I am really confused wrt stable 0.12 branching policy.
For example I see this, in master:
commit d587e0787153f0224a6140c5015609963ceaabfb
Author: Anthony Liguori
Date: Mon Dec 14 11:36:53 2009 -0600
Revert "pci: interrupt disable bit support"
Th
On Sun, Dec 20, 2009 at 1:39 AM, Kirill A. Shutemov
wrote:
> Let's fix code instead!
Nice idea. BTW this can't be the first patch in the series, or
bisectability will be broken.
On Sat, Dec 19, 2009 at 9:08 PM, Richard Henderson 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 Sat, Dec 19, 2009 at 10:52 PM, Richard Henderson wrote:
> On 12/19/2009 01:25 PM, Blue Swirl wrote:
>>
>> On Sat, Dec 19, 2009 at 5:47 PM, Richard Henderson
>> wrote:
>>>
>>> On 12/19/2009 02:31 AM, Blue Swirl wrote:
>
> static inline void tcg_out_movi_imm32(TCGContext *s, int ret, ui
On Sat, Dec 19, 2009 at 11:43 PM, malc 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 fo
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 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 +
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 and
"Kirill A. Shutemov" 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 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
> ---
> hw/loader.c | 25 ++---
>
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 FW
On Fri, Dec 18, 2009 at 12:01:06PM +0100, Gerd Hoffmann wrote:
> From: Anthony Liguori
>
> 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 loaded via fw_
89 matches
Mail list logo
