broken thread, please ignore.
On Tue, Aug 24, 2010 at 02:33:51PM +0800, Ken CC wrote:
> assert(devfn < PCIBUS_MAX_DEVICES)
>
> Signed-off-by: Ken CC
> ---
> hw/pci.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/hw/pci.c b/hw/pci.c
> index 02019a1..1e804da 10064
assert(devfn < PCIBUS_MAX_DEVICES)
Signed-off-by: Ken CC
---
hw/pci.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index 02019a1..1e804da 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -747,6 +747,7 @@ static PCIDevice *do_pci_register_device(PCIDevice
*
Define MAX_PCI_SLOTS as 0x1f, if pci addr provided from command line
is bigger than 0x1f, return error -EINVAL.
0x1f << 3 | 7 == 255 (PCIBUS_MAX_DEVICES - 1)
Signed-off-by: Ken CC
---
hw/qdev-properties.c |2 ++
hw/qdev.h|3 +++
2 files changed, 5 insertions(+), 0 deletions(
Define MAX_PCI_SLOTS as 0x1f, if pci addr provided from command line
is bigger than 0x1f, return error -EINVAL.
0x1f << 3 | 7 == 255 (PCIBUS_MAX_DEVICES - 1)
Signed-off-by: Ken CC
---
hw/qdev-properties.c |2 ++
hw/qdev.h|3 +++
2 files changed, 5 insertions(+), 0 deletions(
assert(devfn < PCIBUS_MAX_DEVICES)
Signed-off-by: Ken CC
---
hw/pci.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index 02019a1..1e804da 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -747,6 +747,7 @@ static PCIDevice *do_pci_register_device(PCIDevice
*
Signed-off-by: Ken CC
---
hw/pci.c |2 +-
hw/pci.h |1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index 70dbace..02019a1 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -47,7 +47,7 @@ struct PCIBus {
pci_hotplug_fn hotplug;
DeviceState *hotplug_
Hi all,
I working on Android emulator and its based on the QEmu. And there I'm going
to emulate camera using machines web cam. There I need to use machines
character device "dev/vedio0" and stream that to the qemu environment.
Therefore on the emulator that web cam stream will be available as the
Ping.
On Wed, Aug 04, 2010 at 05:43:20PM +0900, Isaku Yamahata wrote:
> https://bugs.launchpad.net/bugs/611646
> reports that ./i386-softmmu/qemu -M isapc segfaults.
> This patch fixes the segfault introduced by
> f885f1eaa8711c06033ceb1599e3750fb37c306f
>
> It's because i440fx_state in pc_init1(
ping.
On Thu, Jul 29, 2010 at 06:08:42PM +0900, Isaku Yamahata wrote:
> acpi table file can be modified during load so file size check
> should be more strict.
> pointer calculation should be after qemu_realloc(). not before realloc().
>
> Signed-off-by: Isaku Yamahata
> ---
> hw/acpi.c | 28
On Tue, Aug 24, 2010 at 09:43:25AM +0800, Ken CC wrote:
> On Mon, Aug 23, 2010 at 06:56:56PM +0900, Isaku Yamahata wrote:
> >
> > How did you trigger the bug?
> > I suppose parse_pci_devfn() in qdev-properties should check the error.
> > Although I'm not objecting this patch itself, it's caller's
On Mon, Aug 23, 2010 at 06:56:56PM +0900, Isaku Yamahata wrote:
>
> How did you trigger the bug?
> I suppose parse_pci_devfn() in qdev-properties should check the error.
> Although I'm not objecting this patch itself, it's caller's bug.
> Just assert(devfn < PCIBUS_MAX_DEVICES)?
>
assign pci add
This patch allows to connect Qemu using NBD protocol to an nbd-server
using named exports.
For instance, if on the host "isoserver", in /etc/nbd-server/config, you have:
[generic]
[debian-500-ppc-netinst]
exportname = /ISO/debian-500-powerpc-netinst.iso
[Fedora-10-ppc-netinst]
exp
On 24.08.2010, at 00:50, Anthony Liguori wrote:
> On 08/23/2010 05:45 PM, Alexander Graf wrote:
>>> Device_add already works with this set and only required minor changes the
>>> s390 specific code. So that part was pretty slick :). The part that didn't
>>> work was the drive_add one.
>>>
>>>
On 08/23/2010 05:45 PM, Alexander Graf wrote:
Device_add already works with this set and only required minor changes the s390
specific code. So that part was pretty slick :). The part that didn't work was
the drive_add one.
What is blockdev_add supposed to be? drive_add without IF_SCSI?
driv
On 24.08.2010, at 00:23, Alexander Graf wrote:
>
> On 24.08.2010, at 00:21, Anthony Liguori wrote:
>
>> On 08/23/2010 05:02 PM, Alexander Graf wrote:
>>> The monitor command for hotplugging is in i386 specific code. This is just
>>> plain wrong, as S390 just learned how to do hotplugging too an
Please send in any agenda items you are interested in covering.
thanks,
-chris
On 24.08.2010, at 00:21, Anthony Liguori wrote:
> On 08/23/2010 05:02 PM, Alexander Graf wrote:
>> The monitor command for hotplugging is in i386 specific code. This is just
>> plain wrong, as S390 just learned how to do hotplugging too and needs to
>> get drives for that.
>>
>> So let's add a g
On 08/23/2010 05:02 PM, Alexander Graf wrote:
The monitor command for hotplugging is in i386 specific code. This is just
plain wrong, as S390 just learned how to do hotplugging too and needs to
get drives for that.
So let's add a generic copy to generic code that handles drive_add in a
way that
All architectures can now use drive_add on the monitor. This of course
does not mean that there is hotplug support for the specific platform,
so in order to actually make use of the new drives you still need to
have a hotplug capable device.
Signed-off-by: Alexander Graf
---
qemu-monitor.hx |
All guest targets could potentially implement hotplugging. With the next
patches in this set I will also reflect this in the monitor interface.
So let's always compile it in. It shouldn't hurt.
Signed-off-by: Alexander Graf
---
Makefile.target |5 -
1 files changed, 4 insertions(+), 1 d
The monitor command for hotplugging is in i386 specific code. This is just
plain wrong, as S390 just learned how to do hotplugging too and needs to
get drives for that.
So let's add a generic copy to generic code that handles drive_add in a
way that doesn't have pci dependencies.
I'm not fully ha
I just submitted a few patches that enable the s390 virtio bus to receive
a hotplug add event. This patch implements the qemu side of it, so that new
hotplug events can be submitted to the guest.
Signed-off-by: Alexander Graf
---
hw/s390-virtio-bus.c |9 +
hw/s390-virtio-bus.h |5
While booting a recent guest, I realized that we're know spawning 2x 64 vrings.
Each vring occupies 3 * PAGE_SIZE size and we only reserved 256 * PAGE_SIZE
bytes where some additional meta info also has to fit in.
This is obviously too little. So let's increase the amount of reserved pages
to a re
Hey guys,
this patch set adds support for hotplug add on S390. Apparently it's the first
non-x86 platform receiving so much love in Qemu, so I've stumbled over some
very basic #if defined(TARGET_I386) cases that just shouldn't be there.
I'm open for suggestions, comments, improvements, etc. on th
What does
file `which qemu-system-x86_64`
say?
--
qemu not able to run 64 bit OS when -enable-kvm is used with a 64 bit processor
https://bugs.launchpad.net/bugs/621950
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in QEMU: N
On 08/23/2010 01:24 PM, Jan Kiszka wrote:
Anthony Liguori wrote:
On 08/23/2010 10:10 AM, Markus Armbruster wrote:
You lost me. A few messages upthread.
What's the *practical* problem again?
CPU hotplug adds a local APIC to Sysbus but Sysbus does not allow hot plug.
I beli
Anthony Liguori wrote:
> On 08/23/2010 10:10 AM, Markus Armbruster wrote:
>> You lost me. A few messages upthread.
>>
>> What's the *practical* problem again?
>>
>
> CPU hotplug adds a local APIC to Sysbus but Sysbus does not allow hot plug.
>
> I believe the right short term way to fix this
You're host kernel is 64-bit? Please show the full command line you use
to launch qemu.
--
qemu not able to run 64 bit OS when -enable-kvm is used with a 64 bit processor
https://bugs.launchpad.net/bugs/621950
You received this bug notification because you are a member of qemu-
devel-ml, which i
On 08/23/2010 12:36 PM, Markus Armbruster wrote:
Anthony Liguori writes:
On 08/23/2010 10:10 AM, Markus Armbruster wrote:
You lost me. A few messages upthread.
What's the *practical* problem again?
CPU hotplug adds a local APIC to Sysbus but Sysbus does not allow hot plu
Anthony Liguori writes:
> On 08/23/2010 10:10 AM, Markus Armbruster wrote:
>> You lost me. A few messages upthread.
>>
>> What's the *practical* problem again?
>>
>
> CPU hotplug adds a local APIC to Sysbus but Sysbus does not allow hot plug.
>
> I believe the right short term way to fix thi
On Mon, Aug 23, 2010 at 12:49 AM, Avi Kivity wrote:
> On 08/23/2010 09:45 AM, Paolo Bonzini wrote:
>>
>> On 08/17/2010 01:29 PM, Avi Kivity wrote:
>>>
>>> On 08/12/2010 06:29 PM, Paolo Bonzini wrote:
Nothing earth shattering. :)
Paolo Bonzini (3):
move kvm_set_irqfd to kv
On 08/23/2010 10:10 AM, Markus Armbruster wrote:
You lost me. A few messages upthread.
What's the *practical* problem again?
CPU hotplug adds a local APIC to Sysbus but Sysbus does not allow hot plug.
I believe the right short term way to fix this is to take the local APIC
off of Sysbus
On 08/23/2010 10:14 AM, Avi Kivity wrote:
On 08/23/2010 05:47 PM, Anthony Liguori wrote:
Devices can contain references to structs and objects. If a Device
contains a reference to an object, the object should be stored in a
BusState which is a container of Devices. Therefore, the object
I tried this
On 08/23/2010 05:47 PM, Anthony Liguori wrote:
Devices can contain references to structs and objects. If a Device
contains a reference to an object, the object should be stored in a
BusState which is a container of Devices. Therefore, the object
should inherit from Device.
I disagree.
You lost me. A few messages upthread.
What's the *practical* problem again?
On Mon, Aug 23, 2010, Kevin Wolf wrote:
> How did you find this one? From a quick look it seems that the pattern
> that name is intentionally overflowed to access extension is still there
> in some places. So if this caused some real bug, I think we'll have to
> fix the other ones, too.
Compiler
On 08/23/2010 05:26 PM, Anthony Liguori wrote:
On 08/23/2010 09:00 AM, Avi Kivity wrote:
On 08/23/2010 04:48 PM, Anthony Liguori wrote:
The fundamental issue is: every function (minus trivial ones) in
the device models code should have a state reference. That state
reference should inherit
On 08/23/2010 09:32 AM, Avi Kivity wrote:
Is bad? The answer would depend on whether OtherState implemented
methods or not. If OtherState has no methods, it's fine. If it has
methods, it's bad.
I don't see why. As long as you can manipulate all of MyDevice's
state via MyDeviceState metho
Am 22.08.2010 00:47, schrieb Loïc Minier:
> Signed-off-by: Loïc Minier
Thanks, applied to the block patch.
How did you find this one? From a quick look it seems that the pattern
that name is intentionally overflowed to access extension is still there
in some places. So if this caused some real b
On 08/23/2010 09:00 AM, Avi Kivity wrote:
On 08/23/2010 04:48 PM, Anthony Liguori wrote:
The fundamental issue is: every function (minus trivial ones) in
the device models code should have a state reference. That state
reference should inherit from a DeviceState. If this statement
isn't tru
Jes Sorensen wrote:
> On 08/22/10 20:35, malc wrote:
>> On Sun, 22 Aug 2010, Blue Swirl wrote:
>>> What's the ultimate editor? I'd love to drop Emacs, which is annoying
>>> but does its job better than the others that I've tried.
>>>
>> ed
>
> ed is for sissies, real developers use cat, echo
Jes Sorensen wrote:
> On 08/22/10 20:39, malc wrote:
>
>> Disregarding my own stance on the braces, braces around single statement
>> is actually helpful w.r.t. debugging imaging trying to set a break point
>> on said singlesttement, plain impossible in following case:
>>
>> if (a) b;
>>
>
On 08/23/2010 05:07 PM, Jes Sorensen wrote:
On 08/23/10 16:03, Avi Kivity wrote:
On 08/23/2010 04:55 PM, Jes Sorensen wrote:
Well with the inconsistency we have now, what is the right iron fist to
apply? Demand the code is consistent with the file you edit or that it's
consistent with whats
On 08/23/10 16:03, Avi Kivity wrote:
> On 08/23/2010 04:55 PM, Jes Sorensen wrote:
>>
>> Well with the inconsistency we have now, what is the right iron fist to
>> apply? Demand the code is consistent with the file you edit or that it's
>> consistent with whats in CODING_STYLE, even if it means th
On 08/23/2010 04:55 PM, Jes Sorensen wrote:
Well with the inconsistency we have now, what is the right iron fist to
apply? Demand the code is consistent with the file you edit or that it's
consistent with whats in CODING_STYLE, even if it means that what you
apply is completely different to the
On 08/23/2010 04:48 PM, Anthony Liguori wrote:
The fundamental issue is: every function (minus trivial ones) in the
device models code should have a state reference. That state
reference should inherit from a DeviceState. If this statement
isn't true, then the device has been modelled in qde
On 08/22/10 22:39, Avi Kivity wrote:
> On 08/22/2010 10:44 PM, malc wrote:
>>
>>> There is the problem that some patch submitters are reminded of
>>> CODING_STYLE while others aren't. Some don't need to be reminded but
>>> they are not part of the problem.
>> And to this i fully subscribe.
>
> I
On 08/22/10 20:42, Anthony Liguori wrote:
> On 08/22/2010 01:36 PM, malc wrote:
>
> But how would you do that? Drop the CODING_STYLE (and accept
> anything)? Switch to a new CODING_STYLE that is widely appreciated and
> so all bikeshedding will cease? Enforce current style?
>
On 08/23/2010 08:42 AM, Avi Kivity wrote:
GPIO is just one way for a device to talk, same as
(*bus)_phys_memory_rw() or its netdev or its chardev or its timers.
It doesn't need to have special status within DeviceState, but it
doesn't hurt so much that I can tell.
Everything extra hurts when
On 08/23/2010 04:23 PM, Anthony Liguori wrote:
This is really a fundamental discussion. If you look closely at
qdev in it's current form, what it actually models is a device with
GPIO input and output whereas the GPIO input and output correspond
to qemu_irqs which really model pins that can b
On 08/23/2010 06:25 AM, Paolo Bonzini wrote:
On 08/20/2010 08:12 PM, Anthony Liguori wrote:
+/* Returns false to terminate walk; true to continue */
+typedef int (qdev_walkerfn)(DeviceState *dev, void *opaque);
+
Since you're introducing qbus_walk_children, I suggest a different
interface: qd
On 08/23/2010 12:46 AM, Avi Kivity wrote:
On 08/23/2010 12:02 AM, Anthony Liguori wrote:
On 08/22/2010 03:28 PM, Avi Kivity wrote:
On 08/20/2010 09:38 PM, Anthony Liguori wrote:
While that might be useful, I don't quite see what makes CPUs so
special
that they need to be kept out of qdev. C
On 08/23/2010 05:10 AM, Stefan Hajnoczi wrote:
On Sun, Aug 22, 2010 at 04:41:44PM -0500, Anthony Liguori wrote:
ram_addr_t is not necessarily an unsigned long. It's actually a
uint64_t. Integer promotion should handle this in most cases but
having the definition in two different places wo
On Mon, 23 Aug 2010, Juan Quintela wrote:
> > +register_savevm(NULL, "gpe", 0, 1, gpe_save, gpe_load, s);
>
> Please port this to VMSTATE.
>
> If possible (i.e. not problems with backwards compatibility), something like:
>
> > +for ( i = 0; i < ACPI_GPE0_BLK_LEN / 2; i++ ) {
> > +
On 08/23/2010 05:21 AM, John Haxby wrote:
Any reason why this (and its sister patch) were never picked up?
jch
It was likely missed originally because there wasn't a [PATCH] in the
subject. Can you resubmit? It's not obvious to me what it's sister
patch is so I'd suggest resubmitting that
On 08/23/2010 07:00 AM, Avi Kivity wrote:
Off-topic, but what's the reason for dev->hotplugged's existence? A
device is either plugged or not, it is either hotpluggable or not, but
is there a way to tell, from looking at a plugged device, whether it
has been hotplugged in the past?
AFAICT it
On 08/20/2010 12:00 PM, Markus Armbruster wrote:
Alex Williamson writes:
Several devices rely on their reset() function being called to
initialize device state, e1000 and rtl8139 in particular. When
the device is hot added, the reset doesn't occur, often leaving
the device in an unusable sta
Uploaded to lucid-proposed
** Changed in: qemu-kvm (Ubuntu Lucid)
Status: In Progress => Confirmed
** Changed in: qemu-kvm (Ubuntu Lucid)
Assignee: Thierry Carrez (ttx) => (unassigned)
--
KVM segmentation fault, using SCSI+writeback and linux 2.4 guest
https://bugs.launchpad.net/bug
On Mon, 23 Aug 2010, Juan Quintela wrote:
> > +# Xen Device Model
> > +# xen full virtualized machine
> > +
> > +# Remove some lib, because we don't want it for a xen target.
> > +ifeq ($(TARGET_BASE_ARCH), xen)
> > +bad-libobj-y = exec.o translate-all.o cpu-exec.o translate.o
> > +bad-libobj-y +=
stefano.stabell...@eu.citrix.com wrote:
> From: Anthony PERARD
>
> This patch adds a new Xen device model target to Qemu, called
> target-xen.
> The new target makes use of the previously introduced xen_machine_fv.
> In order to have a fully working Xen device model we still need
> functionalities
On 08/20/2010 08:12 PM, Anthony Liguori wrote:
+/* Returns false to terminate walk; true to continue */
+typedef int (qdev_walkerfn)(DeviceState *dev, void *opaque);
+
Since you're introducing qbus_walk_children, I suggest a different
interface: qdev_walkerfn should return 0 to walk children,
stefano.stabell...@eu.citrix.com wrote:
> From: Anthony PERARD
>
> Xen currently uses a different BIOS (hvmloader + rombios) therefore the
> Qemu acpi_piix4 implementation wouldn't work correctly with Xen.
> We plan on fixing this properly but at the moment we are just adding a
> new Xen specific
On 08/23/2010 02:01 PM, Markus Armbruster wrote:
Avi Kivity writes:
On 08/22/2010 07:40 PM, Jes Sorensen wrote:
I totally agree with Markus
that it seems like wasted effort to come up with new tools and having to
maintain them when there are good ones out there like the ones from the
Linux
Avi Kivity writes:
> On 08/22/2010 07:40 PM, Jes Sorensen wrote:
>> I totally agree with Markus
>> that it seems like wasted effort to come up with new tools and having to
>> maintain them when there are good ones out there like the ones from the
>> Linux kernel.
>>
>
> scripts/Lindent is just a
Signed-off-by: Gerd Hoffmann
---
Makefile |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index f95cc2f..867e038 100644
--- a/Makefile
+++ b/Makefile
@@ -154,8 +154,9 @@ ar de en-us fi fr-be hr it lv nl
pl ru th \
Make stdvga provide the new vgabios binary (with pcibios support)
using the PCI option rom bar. Seabios will happily load it from
there. The new vga bios will also lookup the framebuffer address
in pci config space, so the magic bochs lfb @ 0xe000 is not
needed any more -> zap it.
Without th
Hi,
This patch series will put the new vgabios (patches posted to the list
last week) into use for stdvga and vmware_vga.
For obvious reasons it depends on the new vgabios binaries being
present, i.e. vgabios patches being committed to vgabios.git, subtree
being updated and vgabios binaries bei
Signed-off-by: Gerd Hoffmann
---
hw/vmware_vga.c |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/hw/vmware_vga.c b/hw/vmware_vga.c
index 12bff48..682f287 100644
--- a/hw/vmware_vga.c
+++ b/hw/vmware_vga.c
@@ -114,14 +114,12 @@ struct pci_vmsvga_state_s {
# define
Any reason why this (and its sister patch) were never picked up?
jch
On 27/07/10 15:54, Stefano Stabellini wrote:
Any comments?
On Wed, 21 Jul 2010, Stefano Stabellini wrote:
From: John Haxby
Introduce a new 'connected' xendev op called when Connected.
Rename the existing xendev 'connect'
On 08/23/2010 01:18 PM, Alexander Graf wrote:
I certainly don't, but others may.
However, the problem remains: every time real hardware doesn't fit our pretty
model we'll drop support for that hardware?
No, every time real hardware doesn't fit out pretty model and nobody really
cares, we d
On Sun, Aug 22, 2010 at 04:47:17PM -0500, Anthony Liguori wrote:
> Please add some information about the restrictions on types.
> Clearly, you can't specify just any type in the trace file so what
> set of types are allowed?
Sure, will fix in v2.
Stefan
On 23.08.2010, at 12:15, Avi Kivity wrote:
> On 08/23/2010 01:11 PM, Alexander Graf wrote:
>> On 23.08.2010, at 11:25, Avi Kivity wrote:
>>
>>> On 08/23/2010 12:09 PM, Jan Kiszka wrote:
> Okay, okay. "But then there's a need explicitly not to instantiate it
> when modelling a 486 or low
On 23.08.2010, at 11:25, Avi Kivity wrote:
> On 08/23/2010 12:09 PM, Jan Kiszka wrote:
>>
>>> Okay, okay. "But then there's a need explicitly not to instantiate it
>>> when modelling a 486 or lower".
>> ...plus the need to instantiate it (as a dedicated device) when modeling
>> 486 SMP.
>
> In
On 08/23/2010 01:11 PM, Alexander Graf wrote:
On 23.08.2010, at 11:25, Avi Kivity wrote:
On 08/23/2010 12:09 PM, Jan Kiszka wrote:
Okay, okay. "But then there's a need explicitly not to instantiate it
when modelling a 486 or lower".
...plus the need to instantiate it (as a dedicated device)
** Changed in: qemu-kvm (Ubuntu Lucid)
Assignee: (unassigned) => Thierry Carrez (ttx)
--
KVM segmentation fault, using SCSI+writeback and linux 2.4 guest
https://bugs.launchpad.net/bugs/595438
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed
On Sun, Aug 22, 2010 at 04:41:44PM -0500, Anthony Liguori wrote:
> ram_addr_t is not necessarily an unsigned long. It's actually a
> uint64_t. Integer promotion should handle this in most cases but
> having the definition in two different places worries me a bit.
I thought it is unsigned long:
From: Anthony PERARD
Xen currently uses a different BIOS (hvmloader + rombios) therefore the
Qemu acpi_piix4 implementation wouldn't work correctly with Xen.
We plan on fixing this properly but at the moment we are just adding a
new Xen specific acpi_piix4 implementation.
This patch is optional;
On Sun, Aug 22, 2010 at 04:38:36PM -0500, Anthony Liguori wrote:
> On 08/12/2010 05:36 AM, Stefan Hajnoczi wrote:
> >+linetoh_nop()
> >+{
> >+local name args
> >+name=$(get_name "$1")
> >+args=$(get_args "$1")
> >+
> >+# Define an empty function for the trace event
> >+cat< >+st
From: Anthony PERARD
Introduce a mapcache to handle the 64bit address space of the guest
from a 32bit userland process (Qemu).
The mapcache maps chucks of guest memory on demand, unmaps them when
they are not needed anymore.
Signed-off-by: Anthony PERARD
Signed-off-by: Stefano Stabellini
---
From: Anthony PERARD
Handle shutdown and reset requests in helper.c.
Signed-off-by: Anthony PERARD
Signed-off-by: Stefano Stabellini
---
target-xen/helper.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/target-xen/helper.c b/target-xen/helper.c
index
From: Anthony PERARD
Open and bind event channels; map ioreq and buffered ioreq rings.
Signed-off-by: Anthony PERARD
Signed-off-by: Stefano Stabellini
---
hw/xen_machine_fv.c | 21 +++
target-xen/cpu.h |6 +
target-xen/helper.c | 339 +++
From: Anthony PERARD
Introduce functions to read and write the state of the VM in xenstore.
Signed-off-by: Anthony PERARD
Signed-off-by: Stefano Stabellini
---
hw/xen_machine_fv.c |9
target-xen/helper.c |7 +++
target-xen/qemu-xen.h |3 +
target-xen/xenstore.c | 127 +++
From: Anthony PERARD
Introduce two functions qemu_shutdown_requested_get and
qemu_reset_requested_get to get the value of shutdown/reset_requested
without reset it.
Signed-off-by: Anthony PERARD
Signed-off-by: Stefano Stabellini
---
sysemu.h |2 ++
vl.c | 10 ++
2 files chan
From: Anthony PERARD
This patch introduces Xen specific call in piix_pci.
The specific part for Xen is in write_config, set_irq and get_pirq.
Signed-off-by: Anthony PERARD
Signed-off-by: Stefano Stabellini
---
hw/piix_pci.c | 19 ---
hw/xen.h |3 +++
xen-all.c
From: Anthony PERARD
Add an handler to process xenstore events.
Signed-off-by: Anthony PERARD
Signed-off-by: Stefano Stabellini
---
target-xen/xenstore.c | 30 +-
1 files changed, 29 insertions(+), 1 deletions(-)
diff --git a/target-xen/xenstore.c b/target-xen/x
From: Anthony PERARD
Introduce a 8259 Interrupt Controller for target-xen; every set_irq
call makes a Xen hypercall.
Signed-off-by: Anthony PERARD
Signed-off-by: Stefano Stabellini
---
Makefile.target |2 +-
hw/xen_common.h |3 ++
hw/xen_machine_fv.c |
From: Anthony PERARD
This options will check if the target is build with Xen support.
---
Makefile.target |3 +++
hw/xen.h|8
qemu-options.hx |9 +
vl.c| 11 +++
4 files changed, 31 insertions(+), 0 deletions(-)
create mode 100644 xen-a
From: Anthony PERARD
Introduce a xen_dm_init function that opens the xenctrl interface; call
xen_dm_init from xen_machine_fv.
Signed-off-by: Anthony PERARD
Signed-off-by: Stefano Stabellini
---
Makefile.target |1 +
hw/xen_machine_fv.c |8
target-xen/xenstore.c | 13
From: Anthony PERARD
Add the Xen FV (Fully Virtualized) machine to Qemu;
this is groundwork to add Xen device model support in Qemu.
Signed-off-by: Anthony PERARD
Signed-off-by: Stefano Stabellini
---
Makefile.target |3 +
hw/xen_machine_fv.c | 156 +++
From: Anthony PERARD
Introduce a new emulated PCI device, specific to fully virtualized Xen
guests. The device is necessary for PV on HVM drivers to work.
Signed-off-by: Anthony PERARD
Signed-off-by: Stefano Stabellini
---
Makefile.target |1 +
hw/hw.h |3 +
hw/pci_id
From: Anthony PERARD
This patch adds a new Xen device model target to Qemu, called
target-xen.
The new target makes use of the previously introduced xen_machine_fv.
In order to have a fully working Xen device model we still need
functionalities introduced by the following patches.
Signed-off-by:
From: Anthony PERARD
Update the libxenctrl calls in Qemu to use the new interface, otherwise
Qemu wouldn't be able to build against new versions of the library.
Signed-off-by: Anthony PERARD
Signed-off-by: Stefano Stabellini
---
configure|5 +
hw/xen_backend.c | 10 +
Hi all,
this is the second version of the patch series that adds xen device
model support in qemu.
This is the list of changes we made on top of the last version:
- we modified the first patch to add support to the new libxc interface
without removing support for the old one;
- we converted the n
How did you trigger the bug?
I suppose parse_pci_devfn() in qdev-properties should check the error.
Although I'm not objecting this patch itself, it's caller's bug.
Just assert(devfn < PCIBUS_MAX_DEVICES)?
On Mon, Aug 23, 2010 at 01:56:31PM +0800, Ken CC wrote:
>
> Check before trying subindexin
On 08/23/2010 12:09 PM, Jan Kiszka wrote:
Okay, okay. "But then there's a need explicitly not to instantiate it
when modelling a 486 or lower".
...plus the need to instantiate it (as a dedicated device) when modeling
486 SMP.
In short, if we want our model to be perfect, we have to fix rea
On Sun, Aug 22, 2010 at 04:54:06PM -0500, Anthony Liguori wrote:
> On 08/19/2010 07:48 PM, Amit Shah wrote:
> >If the machine is stopped and 'info balloon' is invoked, the monitor
> >process just hangs waiting for info from the guest. Return the most
> >recent balloon data in that case.
> >
> >See
Avi Kivity wrote:
> On 08/23/2010 12:06 AM, Anthony Liguori wrote:
>> On 08/22/2010 03:33 PM, Avi Kivity wrote:
>>> On 08/22/2010 11:03 PM, Anthony Liguori wrote:
On 08/22/2010 02:44 PM, Avi Kivity wrote:
>> No more MI diamond and all devices have DeviceStates.
>> Coincidentally, it
On 08/21/10 16:20, Kevin O'Connor wrote:
On Fri, Aug 20, 2010 at 09:39:10AM -0500, Anthony Liguori wrote:
On 08/20/2010 09:09 AM, Gerd Hoffmann wrote:
Been there, tried that. It isn't *that* easy. The PCI ID in the
option rom header doesn't match the PCI ID of the emulated lsi, so
seabios ref
Am 22.08.2010 20:42, schrieb Anthony Liguori:
> On 08/22/2010 01:36 PM, malc wrote:
>
> But how would you do that? Drop the CODING_STYLE (and accept
> anything)? Switch to a new CODING_STYLE that is widely appreciated and
> so all bikeshedding will cease? Enforce current style?
1 - 100 of 105 matches
Mail list logo
