I previously submitted a patch to have the guest virtio-blk driver get the
value for the maximum I/O size from the host bdrv, rather than assume that
there is no limit. Avi requested that I first patch the virtio spec
(http://ozlabs.org/~rusty/virtio-spec/). Below is that patch.
Please CC me
On Wed, Dec 02, 2009 at 01:12:30PM -0600, Anthony Liguori wrote:
Artyom Tarasenko wrote:
I thought attaching a second copy were the way to send the patch properly.
Attaching as an application/octet-stream is not terribly helpful. It
basically means you've attached a binary blob.
Is the
On Wed, Dec 02, 2009 at 08:18:40PM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Dec 02, 2009 at 01:04:31PM +0100, Juan Quintela wrote:
Signed-off-by: Juan Quintela quint...@redhat.com
---
hw/virtio-net.c | 148
When the synchronous read and write functions were dropped, they were replaced
by generic emulation functions. Unfortunately, these emulation functions don't
provide the same semantics as the original functions did.
The original bdrv_read would mean that we read some data synchronously and that
On Wed, Dec 2, 2009 at 7:56 PM, Alexander Graf ag...@suse.de wrote:
On 02.12.2009, at 19:53, Artyom Tarasenko wrote:
2009/12/2 Anthony Liguori anth...@codemonkey.ws:
Artyom Tarasenko wrote:
2009/12/1 Alexander Graf ag...@suse.de:
Hi,
Could someone with commit rights please stand up to
On Wed, Dec 02, 2009 at 08:03:22PM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
I don't understand.
container_of is just more generic than DO_UPCAST.
So why *ever* use DO_UPCAST? Let's get rid of it.
functions that use a PCIDevice and you pass FooState require
On 12/03/2009 10:42 AM, Avishay Traeger1 wrote:
I previously submitted a patch to have the guest virtio-blk driver get the
value for the maximum I/O size from the host bdrv, rather than assume that
there is no limit. Avi requested that I first patch the virtio spec
I have a weird problem running migrate. I try to run migrate (normal
migration with shared storage) and I get the following error on the guest
after migration completed:
ide: failed opcode was: unknown
hda: task_out_intr: status=0x41 {DriverReady Error }
hda: task_out_intr:
Krumme, Chris wrote:
Hello Ian,
Hello!
Qemu_malloc will never return 0, so sched function can return void.
Gah! nasty. Check removed.
This is a mixture of tabs and spaces, for new code pick one.
I've been sticking with spaces generally. I can't find 'CodingStyle' so
I copied. I think
2009/12/2 Anthony Liguori anth...@codemonkey.ws:
Jan Kiszka wrote:
Artyom Tarasenko wrote:
2009/12/1 Alexander Graf ag...@suse.de:
Hi,
Could someone with commit rights please stand up to feel responsible for
PPC?
Usually, when I send a patch to qemu-devel, I know who to address to
On Wed, Dec 02, 2009 at 07:48:04PM +0100, Artyom Tarasenko wrote:
Will have to find a way to persuade gmail not to wrap patches.
gmail MSA/MTA does not wrap patches IMO. the web interface
does and IMO can not be told not to, so just find another MUA you like
to send mail.
--
MST
Am 03.12.2009 11:04, schrieb Ian Molton:
Krumme, Chris wrote:
This is a mixture of tabs and spaces, for new code pick one.
I've been sticking with spaces generally. I can't find 'CodingStyle' so
I copied. I think spaces suck for this though. What is acceptable?
linux kernel style ?
Four
The QEMU team is pleased to announce the availability of the 0.11.1
release. This is a stable release of the 0.11 tree and contains only
bug fixes since the 0.11.0 The attached Changelog includes all of the
changes that have went in since 0.11.1.
It can be downloaded from Savannah at:
On Wed, Dec 02, 2009 at 11:46:06AM -0200, Glauber Costa wrote:
Avi/Marcelo
Please include this in a branch in qemu-kvm, for future inclusion
in qemu.git
This is basically the same thing that was sitting in staging for weeks,
just with a build bug fix on non-x86 hosts.
Glauber Costa
On Wed, Dec 02, 2009 at 08:13:52PM +, Ian Molton wrote:
btw. Does anyone know how to get t-bird to inline patches?
Read this:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/email-clients.txt;hb=HEAD
Does msix work with this patchset when in-kernel irqchip
is enabled?
Haven't tested. But since I see that msix need some special code in qemu-kvm,
it probably won't. But I assume we can just add a patch ontop of this to add
that code and make it work, right?
--
Glauber Costa.
Free as in
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Dec 02, 2009 at 08:03:22PM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
I don't understand.
container_of is just more generic than DO_UPCAST.
So why *ever* use DO_UPCAST? Let's get rid of it.
See how you
On Thu, Dec 03, 2009 at 09:42:02AM -0200, Glauber Costa wrote:
Does msix work with this patchset when in-kernel irqchip
is enabled?
Haven't tested. But since I see that msix need some special code in qemu-kvm,
it probably won't. But I assume we can just add a patch ontop of this to add
Michael S. Tsirkin m...@redhat.com wrote:
...
but u32 don't fit in u8. And we read u32 into u8. I agree that writing
u8 into u32 is not a problem, the problem is the reverse.
So don't read u32 into u8.
Read data into u32, check that the value fits into u8, fail migration
if it does not,
Haven't tested. But since I see that msix need some special code in qemu-kvm,
it probably won't. But I assume we can just add a patch ontop of this to add
that code and make it work, right?
Sure. However - are you making in-kernel irqchip the default?
If so, I think the best way to do it
On 12/03/2009 12:20 AM, Alexander Graf wrote:
Some recent change made PPC guests always start at address 0x0 because env
isn't synced to kvm_state on first bootup.
I'm not sure if this is the correct bugfix, but at least it makes PPC boot
again with KVM enabled.
Looks good.
--
error
On 12/02/2009 03:46 PM, Glauber Costa wrote:
It is actually not necessary to call a tpr function to save and load cr8,
as cr8 is part of the processor state, and thus, it is much easier
to just add it to CPUState.
As for apic base, wrap kvm usages, so we can call either the qemu device,
or the
On 12/02/2009 03:48 PM, Glauber Costa wrote:
This function is similar to qemu-kvm's on_vcpu mechanism.
Is similar? You're replacing on_vcpu().
Totally synchronous,
and guarantees that a given function will be executed at the specified vcpu.
This patch also convert usage within the
On 12/02/2009 03:48 PM, Glauber Costa wrote:
We don't support smp without irqchip in kernel, so only abort in
that situation
What's the reason for this restriction?
--
error compiling committee.c: too many arguments to function
On Thu, Dec 3, 2009 at 10:20 AM, Avi Kivity a...@redhat.com wrote:
On 12/02/2009 03:48 PM, Glauber Costa wrote:
This function is similar to qemu-kvm's on_vcpu mechanism.
Is similar? You're replacing on_vcpu().
Yeah, it began similar, now it is pretty much the same thing, but
using
On 12/02/09 17:46, Anthony Liguori wrote:
If you have a pending patch that you think should be in 0.12, please
check to make sure it's there.
A clear 'must have':
http://patchwork.ozlabs.org/patch/39291/
Add a new machine type for qemu 0.12
On top of that, to reduce irq sharing (nice to
On 12/03/2009 02:33 PM, Glauber Costa wrote:
On Thu, Dec 3, 2009 at 10:20 AM, Avi Kivitya...@redhat.com wrote:
On 12/02/2009 03:48 PM, Glauber Costa wrote:
This function is similar to qemu-kvm's on_vcpu mechanism.
Is similar? You're replacing on_vcpu().
Yeah, it
On Thu, Dec 3, 2009 at 10:23 AM, Avi Kivity a...@redhat.com wrote:
On 12/02/2009 03:48 PM, Glauber Costa wrote:
We don't support smp without irqchip in kernel, so only abort in
that situation
What's the reason for this restriction?
It is temporary. But as far as my testing goes, we don't
On 12/03/2009 02:36 PM, Glauber Costa wrote:
On Thu, Dec 3, 2009 at 10:23 AM, Avi Kivitya...@redhat.com wrote:
On 12/02/2009 03:48 PM, Glauber Costa wrote:
We don't support smp without irqchip in kernel, so only abort in
that situation
What's the reason for this
Keep the name then. The new name is misleading.
ok.
Totally synchronous,
and guarantees that a given function will be executed at the specified
vcpu.
This patch also convert usage within the breakpoints system
+void qemu_queue_work(CPUState *env, void (*func)(void *data), void
*data);
On Thu, Dec 3, 2009 at 10:37 AM, Avi Kivity a...@redhat.com wrote:
On 12/03/2009 02:36 PM, Glauber Costa wrote:
On Thu, Dec 3, 2009 at 10:23 AM, Avi Kivitya...@redhat.com wrote:
On 12/02/2009 03:48 PM, Glauber Costa wrote:
We don't support smp without irqchip in kernel, so only abort in
On 12/03/2009 02:37 PM, Glauber Costa wrote:
Because it fixes things.
Please elaborate.
gdbstub is called from the i/o thread , and call vcpu ioctls. So it
has to use the on_vcpu
mechanism to guarantee its execution in the right thread.
What I meant is that currently, gdbstub is the
On 12/03/2009 02:39 PM, Glauber Costa wrote:
This works well in qemu-kvm. What's the reason? it may indicate a bug in
up.
The reason is that we do not handle SIPI in qemu.git yet. Now that the basics
of smp are working, it should not be too difficult to get it working.
OK. I
On Thu, Dec 03, 2009 at 10:04:21AM -0200, Glauber Costa wrote:
Haven't tested. But since I see that msix need some special code in
qemu-kvm,
it probably won't. But I assume we can just add a patch ontop of this to
add
that code and make it work, right?
Sure. However - are you
On 12/03/2009 02:39 PM, Michael S. Tsirkin wrote:
Right now there are no knobs to disable it, since last time I checked,
people were inclined to
solve that by adding a machine type that does not do irqchip in
kernel, if wanted.
Can't everything doable by machine type also doable from
Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Dec 03, 2009 at 12:56:57PM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Dec 02, 2009 at 08:03:22PM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
I don't understand.
On 02.12.2009 20:12, Anthony Liguori wrote:
Artyom Tarasenko wrote:
I thought attaching a second copy were the way to send the patch
properly.
Attaching as an application/octet-stream is not terribly helpful. It
basically means you've attached a binary blob.
Is the proper way
On Thu, Dec 3, 2009 at 10:45 AM, Avi Kivity a...@redhat.com wrote:
On 12/03/2009 02:39 PM, Michael S. Tsirkin wrote:
Right now there are no knobs to disable it, since last time I checked,
people were inclined to
solve that by adding a machine type that does not do irqchip in
kernel, if
Gerd Hoffmann wrote:
On 12/02/09 17:46, Anthony Liguori wrote:
If you have a pending patch that you think should be in 0.12, please
check to make sure it's there.
A clear 'must have':
http://patchwork.ozlabs.org/patch/39291/
Add a new machine type for qemu 0.12
On top of that, to
2009/12/3 Michael S. Tsirkin m...@redhat.com:
On Wed, Dec 02, 2009 at 07:48:04PM +0100, Artyom Tarasenko wrote:
Will have to find a way to persuade gmail not to wrap patches.
gmail MSA/MTA does not wrap patches IMO. the web interface
does and IMO can not be told not to, so just find another
On Wednesday 02 December 2009, Anthony Liguori wrote:
Arnd Bergmann wrote:
With the upcoming macvtap, we will want to open devices other than
/dev/net/tun but no longer need to call TUNSETIFF.
What are the names of these devices and how do you the character devices
get created in
On 12/03/2009 02:55 PM, Juan Quintela wrote:
sorry, already allocated memory. basically -device foo
requires that qdev creates foo and then it call foo_init().
Alternatives:
- foo_init() allocates Foo and calls qdev_init() (how C++ works, but
cumbersome here)
- we put the offset of
On 12/02/2009 05:46 PM, Anthony Liguori wrote:
I've got all of the patches I'm considering for 0.12 currently in
staging. I'm going to work through and test/commit these in a few
chunks over the next few days before freezing the tree.
If you have a pending patch that you think should be in
Riku Voipio wrote:
git pulls have been working really well for linux-user. I'd like to
continue that for new architectures.
I can provide the patches in the same way as git pull requests.
Works for me.
Regards,
Anthony Liguori
Alexander Graf ag...@suse.de writes:
Would you mind writing up a documentation on that whole -device stuff?
I'm having a hard time following your changes and every time you do a
patch you break my S390 series.
I've been writing a brief guide on how to use -device. It's not yet in
the Wiki,
Filip Navara wrote:
If only everything was as easy as it sounds. Unfortunately
git-send-email was for long time unavailable to Windows users and even
now it is barely usable and hard to configure. TortoiseGit once again
doesn't work because of the changed setting on the nongnu.org mail
server...
On Wed, 02 Dec 2009 13:32:03 -0600
Anthony Liguori anth...@codemonkey.ws wrote:
Both freshly rebased against staging (which doesn't build btw).
Nope, and it won't for a while. Instead of fixing everything, I'm just
focusing on small groups of patches at a time.
Right, but people
On 12/02/2009 02:48 PM, Glauber Costa wrote:
+if (env == qemu_get_current_env()) {
Will always be false for TCG + iothread. What's wrong with
qemu_cpu_self(env)? It appears to do the same, and it would also make
the whole thread-local storage stuff redundant.
If there are performance
On Thu, Dec 03, 2009 at 01:56:57PM +0100, Carl-Daniel Hailfinger wrote:
On 02.12.2009 20:12, Anthony Liguori wrote:
Artyom Tarasenko wrote:
I thought attaching a second copy were the way to send the patch
properly.
Attaching as an application/octet-stream is not terribly helpful.
On Thu, Dec 3, 2009 at 12:29 PM, Paolo Bonzini pbonz...@redhat.com wrote:
On 12/02/2009 02:48 PM, Glauber Costa wrote:
+ if (env == qemu_get_current_env()) {
Will always be false for TCG + iothread. What's wrong with
qemu_cpu_self(env)? It appears to do the same, and it would also make
Paolo Bonzini wrote:
On 12/02/2009 05:46 PM, Anthony Liguori wrote:
I've got all of the patches I'm considering for 0.12 currently in
staging. I'm going to work through and test/commit these in a few
chunks over the next few days before freezing the tree.
If you have a pending patch that you
Hi,
my migration issues currently look like they are driven by at least two
bugs (that's real fun). One slipped into qemu-kvm during merge of
upstream, the other is either an issue of current kvm.git master or
kvm-kmod's wrapping of the latter.
Problem 1
-
Setup: qemu-kvm after
This changes the monitor eject_device() function to not check for
bdrv_is_inserted().
Example run where the bug manifests itself:
(output of 'info block' is stripped to include only the CD-ROM device)
QEMU 0.11.50 monitor - type 'help' for more information
(qemu) info block
ide1-cd0:
From: Naphtali Sprei nsp...@redhat.com
When guest un-eject a cdrom, re-insert the cdrom image (re-open the drive's
file).
Also, related changes for the un-eject:
o enter UNIT ATTENTION state only on change/insert media, not upon removal
o minor change in packet command abort when in UNIT
This series contains two patches that were submitted previously, but conflict
with each other. This series contains both to make sure they are applied on the
right order and that there are no mismerges.
This should fix a mismerge that is present on the current staging tree (a
closing bracket is
On Thu, 3 Dec 2009 12:23:45 -0200
Luiz Capitulino lcapitul...@redhat.com wrote:
On Wed, 02 Dec 2009 13:32:03 -0600
Anthony Liguori anth...@codemonkey.ws wrote:
Both freshly rebased against staging (which doesn't build btw).
Nope, and it won't for a while. Instead of fixing
Luiz Capitulino wrote:
Right, but people rebasing against it need to build it to be able
to fix conflicts and test things.
So, here is a list of problems I had to fix/workaround to have staging
fully building on x86_64.
With recent changes the -net one went away and we got a new one:
It would be nice if the -debugcon patch could be considered for 0.12; I
realize it is a trivial thing (unless you do mixed Qemu/Bochs
debugging!), but it also shouldn't affect anything else in any
significant way.
Here is the patch rebased against your staging tree. The SCSI code in
your staging
Updated to fix a compile problem with my vmstate conversion...
This iteration addresses all of the comments from the last round. Thanks to
everyone for their careful reviews and helpful comments. The most significant
change in this version is my use of the QObject API, so a concentrated review
Christoph Hellwig wrote:
On Mon, Nov 30, 2009 at 04:54:31PM +0100, Kevin Wolf wrote:
Users don't expect that they need to specify host_device/cdrom/floppy when
creating an image on a block device or converting with an device as target.
Currently creating as raw leads to 'Error while
Hi there,
Got this while testing block migration in staging:
Program terminated with signal 11, Segmentation fault.
#0 0x00410cf9 in monitor_vprintf (mon=0x0, fmt=0x5ae5e7 Start full
migration for %s\n,
ap=0x7fff1f830a40) at /home/lcapitulino/src/aliguori-queue/monitor.c:192
192
Luiz Capitulino wrote:
Hi there,
Got this while testing block migration in staging:
Program terminated with signal 11, Segmentation fault.
#0 0x00410cf9 in monitor_vprintf (mon=0x0, fmt=0x5ae5e7 Start full
migration for %s\n,
ap=0x7fff1f830a40) at
Anthony Liguori wrote:
New patch attached, addressing the below. Thanks!
CODING_STYLE is off (as I mentioned before).
Hopefully fixed now.
+gettimeofday(tv, NULL);
This will break Win32 (use qemu_gettimeofday).
Done
Don't open code a list, use one of the sys-queue types.
I
On Thu, 03 Dec 2009 19:36:15 +0100
Jan Kiszka jan.kis...@siemens.com wrote:
Luiz Capitulino wrote:
Hi there,
Got this while testing block migration in staging:
Program terminated with signal 11, Segmentation fault.
#0 0x00410cf9 in monitor_vprintf (mon=0x0,
The monitor_vprintf() function now touches the 'mon' variable
before calling monitor_puts(), this causes block migration
to segfault as its functions call monitor_printf() with a
NULL 'mon'.
This is probably hiding the real bug, but for some reason this
has been the behavior for a long time.
We
Luiz Capitulino wrote:
On Thu, 03 Dec 2009 19:36:15 +0100
Jan Kiszka jan.kis...@siemens.com wrote:
Luiz Capitulino wrote:
Hi there,
Got this while testing block migration in staging:
Program terminated with signal 11, Segmentation fault.
#0 0x00410cf9 in monitor_vprintf
Jan Kiszka wrote:
Problem 2
-
Setup: qemu head with vmstate fixes. kvm-kmod master, 64-bit host guest.
Effect: The migration target either locks up or reboots immediately.
I've nailed this down to 84d0b66c778d881eafca2a5d0d66678211c4e861. Every
kvm module build before that works,
On Wed, Dec 02, 2009 at 10:46:11AM -0600, Anthony Liguori wrote:
I've got all of the patches I'm considering for 0.12 currently in
staging. I'm going to work through and test/commit these in a few
chunks over the next few days before freezing the tree.
What are the plans on the OpenBIOS
Jan Kiszka wrote:
Luiz Capitulino wrote:
Hi there,
Got this while testing block migration in staging:
Program terminated with signal 11, Segmentation fault.
#0 0x00410cf9 in monitor_vprintf (mon=0x0, fmt=0x5ae5e7 Start full
migration for %s\n,
ap=0x7fff1f830a40) at
Jan Kiszka wrote:
Luiz Capitulino wrote:
On Thu, 03 Dec 2009 19:36:15 +0100
Jan Kiszka jan.kis...@siemens.com wrote:
Luiz Capitulino wrote:
Hi there,
Got this while testing block migration in staging:
Program terminated with signal 11, Segmentation fault.
#0
Gleb Natapov wrote:
On Fri, Nov 27, 2009 at 01:25:36PM +0100, Kevin Wolf wrote:
Either rename variables and functions to refer to write errors (which is what
they actually do) or introduce a parameter to distinguish reads and writes.
I prefer either to use two different functions or
On Thu, Dec 3, 2009 at 9:26 PM, Aurelien Jarno aurel...@aurel32.net wrote:
On Wed, Dec 02, 2009 at 10:46:11AM -0600, Anthony Liguori wrote:
I've got all of the patches I'm considering for 0.12 currently in
staging. I'm going to work through and test/commit these in a few
chunks over the next
Adam Lackorzynski wrote:
multiboot: Support arbitrary number of modules
Signed-off-by: Adam Lackorzynski a...@os.inf.tu-dresden.de
---
hw/pc.c | 216 +-
1 files changed, 143 insertions(+), 73 deletions(-)
diff --git a/hw/pc.c
From: Juha Riihimäki juha.riihim...@nokia.com
At least under some mingw compilers slirp networking fails without declaring
these fields packed.
From: Juha Riihimäki juha.riihim...@nokia.com
Signed-off-by: Juha Riihimäki juha.riihim...@nokia.com
Signed-off-by: Riku Voipio riku.voi...@nokia.com
From: Juha Riihimäki juha.riihim...@nokia.com
/tmp doesn't exist under win32. Ease the pain of win32 development slightly.
From: Juha Riihimäki juha.riihim...@nokia.com
Signed-off-by: Riku Voipio riku.voi...@nokia.com
---
exec.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
From: Riku Voipio riku.voi...@nokia.com
The limit of iomem areas is quite low. Without the
debug print, it is quite hard to figure out why more
devices are not getting registered.
Signed-off-by: Riku Voipio riku.voi...@nokia.com
---
exec.c |2 +-
1 files changed, 1 insertions(+), 1
From: Juha Riihimäki juha.riihim...@nokia.com
From: Juha Riihimäki juha.riihim...@nokia.com
Signed-off-by: Juha Riihimäki juha.riihim...@nokia.com
Signed-off-by: Riku Voipio riku.voi...@nokia.com
---
hw/sd.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/hw/sd.c
From: Riku Voipio riku.voi...@nokia.com
Convert musb fifo to 8bit to allow 8/16/32bit access
MUSB allows reading and writing to the fifo in 32/16/8 bit
width. The Linux kernel does this sometimes, most usually at
the end of writing the packet to allow packet to end at a
odd bytecount.
Convert
From: Riku Voipio riku.voi...@nokia.com
Simplifies power budget negotiation.
Signed-off-by: Riku Voipio riku.voi...@nokia.com
---
hw/usb-hid.c |2 +-
hw/usb-hub.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/usb-hid.c b/hw/usb-hid.c
index f4a2a48..b099ae7
From: Juha Riihimäki juha.riihim...@nokia.com
Excplicit read/write locking pidfile under WIN32 is bit extreme
nobody get the chance to read the pidfile. Convert to a write-only lock.
Also, creating pidfile was disabled along with daemonize under
WIN32. Enable it, but do not enable daemon support
From: Riku Voipio riku.voi...@nokia.com
Collection of lingering qemu fixes from maemo qemu. probably
worth pushing to 0.12
Juha Riihimäki (4):
Fix win32 log file location
fix pidfile option to work in WIN32
handle SD CMD5 without error messages
fix networking on win32 host
Riku Voipio
multiboot: Support arbitrary number of modules.
Addressed comments by Anthony.
Signed-off-by: Adam Lackorzynski a...@os.inf.tu-dresden.de
---
hw/pc.c | 260 ++
1 files changed, 159 insertions(+), 101 deletions(-)
diff --git a/hw/pc.c
multiboot: Separate multiboot loading into separate file
Move multiboot loading functionality to a separate file as suggested by
Alex Graf.
Signed-off-by: Adam Lackorzynski a...@os.inf.tu-dresden.de
---
Makefile.target |2 +-
hw/multiboot.c | 318
On 03.12.2009, at 23:23, Adam Lackorzynski wrote:
multiboot: Separate multiboot loading into separate file
Move multiboot loading functionality to a separate file as suggested by
Alex Graf.
Awesome, thanks!
Looks good to me. The code could use some cleanup (magic numbers), but we
should
Gerd Hoffmann wrote:
On 12/02/09 17:46, Anthony Liguori wrote:
If you have a pending patch that you think should be in 0.12, please
check to make sure it's there.
A clear 'must have':
http://patchwork.ozlabs.org/patch/39291/
Add a new machine type for qemu 0.12
On top of that, to
Adam Lackorzynski wrote:
multiboot: Support arbitrary number of modules.
Addressed comments by Anthony.
Signed-off-by: Adam Lackorzynski a...@os.inf.tu-dresden.de
---
hw/pc.c | 260 ++
1 files changed, 159 insertions(+), 101
On Thu, 03 Dec 2009 17:21:18 -0600
Anthony Liguori anth...@codemonkey.ws wrote:
Finally the 'default devices' patch series ('must have' IMHO):
http://patchwork.ozlabs.org/patch/39180/ (patch 1/10)
Without that one using -device and -readconfig becomes much harder.
This series
Luiz Capitulino wrote:
On Thu, 03 Dec 2009 17:21:18 -0600
Anthony Liguori anth...@codemonkey.ws wrote:
Finally the 'default devices' patch series ('must have' IMHO):
http://patchwork.ozlabs.org/patch/39180/ (patch 1/10)
Without that one using -device and -readconfig becomes much harder.
SeaBIOS needs to write to the f-segment. So it needs to have some way to set
that from read-only to read-write, write in it and when it's done set it to
read-only again.
On PCI we have a mechanism for that. The ISA machine does not though. To stay
regression free and happily enable users to
On Fri, Dec 04, 2009 at 01:24:52AM +0100, Alexander Graf wrote:
SeaBIOS needs to write to the f-segment. So it needs to have some way to set
that from read-only to read-write, write in it and when it's done set it to
read-only again.
On PCI we have a mechanism for that. The ISA machine does
On 04.12.2009, at 01:44, Kevin O'Connor wrote:
On Fri, Dec 04, 2009 at 01:24:52AM +0100, Alexander Graf wrote:
SeaBIOS needs to write to the f-segment. So it needs to have some way to set
that from read-only to read-write, write in it and when it's done set it to
read-only again.
On PCI
Hi there.
I tried to verify if the bug existed with Realview, but I just can't get
the guest to mount an sd-card, which I created with qemu-img and copied
a roots onto there and the guest kernel cannot be configured with
PCI/SCSI support for the ext2 image.
Do you have any ideas on how to
On Wed, Nov 11, 2009 at 09:06:58AM +0800, Scott Tsai wrote:
On Wed, Nov 11, 2009 at 8:57 AM, Greg KH gre...@suse.de wrote:
What code? ??Where is it at?
http://patchwork.ozlabs.org/patch/38118/
This code emulates a Vernier Go!Temp device in qemu.
I wrote this to enable people to follow
http://airlied.livejournal.com/69291.html
Link courtesy Laurent Desnogues.
--
mailto:av1...@comtv.ru
Split out pc smbus routines from acpi.c into pc_smbus.c and
use it.
The split out smbus emulation will be used later.
Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp
---
Makefile.target |2 +
hw/acpi.c | 164 +++
hw/pc_smbus.c |
By introducing a registering function, make pc_init1() not refer to
ferr_irq directly in order to make ferr_irq piix independent.
Later pc_init1() will be split out into another file keeping ferr_irq
static.
Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp
---
hw/pc.c |8 +++-
remove unused variable in get_pmsts().
Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp
---
hw/acpi_piix4.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
index 53efa2a..887c82f 100644
--- a/hw/acpi_piix4.c
+++ b/hw/acpi_piix4.c
@@
Split out apm register emulation for acpi.c into pc_apm.c.
The apm emulation will be used later.
Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp
---
Makefile.target |4 +-
hw/acpi.c | 57 ++-
hw/pc_apm.c | 89
This is the preparation patch for q35 chipset and PCIE support.
Anthony, any chance to merge? Can you please give me comments?
This patch series is for spliting out piix specific part from pc emulator
to make it easier to implement other pc chipset emulator.
Although my motivation is for 128+
initialize ioapic before use.
Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp
---
hw/pc_piix.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 35924ea..fcf8aaf 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -81,6 +81,9 @@
1 - 100 of 113 matches
Mail list logo
