date:20101027

  > "install64", which comes a bit longer.  It fails in a new way: it
  > ignores keyboard input, This happens after the kernel has booted, and
  > the installer has started.
  
  Yes, ignoring keyboard input sounds right. The issue here is that
  we're basically emulating a PPC32 machine, but plug in a PPC64
  CPU. This works mostly, but for ADB it breaks, as the guest kernel
  doesn't have support for our ADB controller. Unfortunately, keyboard
  and mouse are attached using ADB.
  
  One way to get around this is to use -usb -usbdevice keyboard.

That makes no difference.  I suppose it is still using the adb keyboard.

  Another way is to use the serial port instead of graphical console.
  
I cannot get this to work either.

With -nographic I get the same lock as initially, after

  Device tree strings 0x0245 -> 0x024504d9
  Device tree struct  0x02451000 -> 0x02453000
  Calling quiesce ...
  returning from prom_init

it hangs.

  Please also keep in mind that PPC emulation is _very_ slow.

Why is it slow?

  If you need performance for this, please just grab a PPC machine and
  use KVM on it. It will be a lot faster.

Physical machines take space and need power.  Qemu is a lot leaner.  :-)

-- 
Torbjörn

Re: [Qemu-devel] [PATCH v2] Add a DTrace tracing backend targetted for SystemTAP compatability

2010-10-27 Thread Daniel P. Berrange

On Wed, Oct 27, 2010 at 12:26:50PM +0530, Prerna Saxena wrote:
> ACK, works well!
> A suggestion though..
> 
> On 10/20/2010 07:39 PM, Daniel P. Berrange wrote:
> >
> >eg, instead of
> >
> >   probe process("qemu").mark("qemu_malloc") {
> > printf("Malloc %d %p\n", $arg1, $arg2);
> >   }
> >
> >The addition of qemu.stp to /usr/share/systemtap/tapset/
> >lets users write
> >
> >   probe qemu.qemu_malloc {
> > printf("Malloc %d %p\n", size, ptr);
> >   }
> >...
> >
> >
> >diff --git a/tracetool b/tracetool
> >index 7010858..047f16b 100755
> >--- a/tracetool
> >+++ b/tracetool
> >+linetos_dtrace()
> >+{
> >+local name args arglist state
> >+
> >+# Define prototype for probe arguments
> >+cat< >+probe qemu.$name = process("qemu").mark("$name")
> >+{
> 
> The 'process' probes only work by looking for the binary in $PATH, 
> unless the full path is specified. When compiling qemu in non-standard 
> locations ( ie with --prefix), such probes would not point to the 
> correct binary. It could be nice if tracetool could pass the full build 
> path for defining the probe point. Eg,
> 
> probe qemu.qemu_malloc = 
> process("/Path/to/build/dir/bin/qemu").mark("qemu_malloc") { .. }

Yes, that's doable. The other problem with this tapset is that it
only works for the 'qemu' binary and not the 'qemu-system-'
binaries. I either need to make the probe cover all binaries, or
generate one tapset per architecture target.  I'm going to split
this patch in 2, one with just the core dtrace bits, and a second
with the systemtap tapset addon.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London-o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org-o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] v6: [PATCH 0/3]: Threadlets: A generic task offloading framework

2010-10-27 Thread Amit Shah

On (Sat) Oct 23 2010 [13:05:48], Stefan Hajnoczi wrote:
> >> >You cannot access guest memory using QEMU RAM functions (or use the
> >> >virtqueue_pop() function which uses them) from a thread without taking
> >> >the QEMU global mutex.
> >> >
> >> >The abort stack trace is a result of accessing guest RAM from two
> >> >threads simultaneously.
> >> >
> >> >In general it is not safe to use QEMU functions from a thread unless
> >> >they are explicitly written to work outside the QEMU global mutex.
> >> >Most functions assume the global mutex, which serializes I/O thread
> >> >and vcpu changes to global state, is held.
> >>
> >> Yes, threadlets are only meant to be used to make synchronous system
> >> calls asynchronous.  They are not meant to add parallelism to QEMU
> >> (yet).
> >
> > Yes -- I realised that.  (But I don't see why the virtio rings get
> > modified elsewhere other than the only function I push/pop from above.)
> 
> The particular race condition triggered by virtqueue_pop() is because
> guest RAM access functions try to optimize frequently accessed memory
> to keep lookup time to a minimum.  The current RAM block is put onto
> the beginning of the lookup list so the next access to it will be
> faster.  When two threads are looking up guest memory simultaneously
> one may be modifying the list while the other traverses it...

Right, thanks.

> > Anyway, just one question as I've still not read the code: does a
> > running work item in a threadlet block migration?  Do the remaining work
> > items in a threadlet get migrated fine?
> 
> There's no migration support in the threadlets infrastructure itself.
> 
> Threadlets users need to think about how to safely migrate, either
> through cancellation or waiting for all pending work to complete.  For
> example, migration will quiesce aio requests using qemu_aio_flush() so
> there is no outstanding work to be migrated.

The problem then is that the API doesn't have functions to either stall
all pending work in a threadlet or cancel all work or even block the
caller till all work is finished.  I think the API relies on the work
signalling some sort of completion, which means callers (or threadlet
users) have to keep track of all the work scheduled, which might be
uneecessary.

Amit

Re: [Qemu-devel] v6: [PATCH 0/3]: Threadlets: A generic task offloading framework

2010-10-27 Thread Stefan Hajnoczi

On Wed, Oct 27, 2010 at 8:57 AM, Amit Shah  wrote:
> On (Sat) Oct 23 2010 [13:05:48], Stefan Hajnoczi wrote:
>> >> >You cannot access guest memory using QEMU RAM functions (or use the
>> >> >virtqueue_pop() function which uses them) from a thread without taking
>> >> >the QEMU global mutex.
>> >> >
>> >> >The abort stack trace is a result of accessing guest RAM from two
>> >> >threads simultaneously.
>> >> >
>> >> >In general it is not safe to use QEMU functions from a thread unless
>> >> >they are explicitly written to work outside the QEMU global mutex.
>> >> >Most functions assume the global mutex, which serializes I/O thread
>> >> >and vcpu changes to global state, is held.
>> >>
>> >> Yes, threadlets are only meant to be used to make synchronous system
>> >> calls asynchronous.  They are not meant to add parallelism to QEMU
>> >> (yet).
>> >
>> > Yes -- I realised that.  (But I don't see why the virtio rings get
>> > modified elsewhere other than the only function I push/pop from above.)
>>
>> The particular race condition triggered by virtqueue_pop() is because
>> guest RAM access functions try to optimize frequently accessed memory
>> to keep lookup time to a minimum.  The current RAM block is put onto
>> the beginning of the lookup list so the next access to it will be
>> faster.  When two threads are looking up guest memory simultaneously
>> one may be modifying the list while the other traverses it...
>
> Right, thanks.
>
>> > Anyway, just one question as I've still not read the code: does a
>> > running work item in a threadlet block migration?  Do the remaining work
>> > items in a threadlet get migrated fine?
>>
>> There's no migration support in the threadlets infrastructure itself.
>>
>> Threadlets users need to think about how to safely migrate, either
>> through cancellation or waiting for all pending work to complete.  For
>> example, migration will quiesce aio requests using qemu_aio_flush() so
>> there is no outstanding work to be migrated.
>
> The problem then is that the API doesn't have functions to either stall
> all pending work in a threadlet or cancel all work or even block the
> caller till all work is finished.  I think the API relies on the work
> signalling some sort of completion, which means callers (or threadlet
> users) have to keep track of all the work scheduled, which might be
> uneecessary.

I agree that placing responsibility on the caller is not ideal in
simple cases like waiting for all work to complete.  On the other hand
it allows custom behavior to be implemented since the caller has full
control.

I'd wait to see how callers actually use threadlets and deal with
migration.  Patterns may emerge and can be put into common code.

Stefan

Re: [Qemu-devel] [PATCH 2/3] Make paio subsystem use threadlets

2010-10-27 Thread Stefan Hajnoczi

On Tue, Oct 26, 2010 at 3:14 PM, Arun R Bharadwaj
 wrote:
> @@ -536,14 +442,15 @@ static void paio_cancel(BlockDriverAIOCB *blockacb)
>     struct qemu_paiocb *acb = (struct qemu_paiocb *)blockacb;
>     int active = 0;
>
> -    mutex_lock(&lock);
>     if (!acb->active) {
> -        QTAILQ_REMOVE(&request_list, acb, node);
> -        acb->ret = -ECANCELED;
> +        if (!deque_threadletwork(&acb->work)) {
> +            acb->ret = -ECANCELED;
> +         } else {
> +            active = 1;
> +         }
>     } else if (acb->ret == -EINPROGRESS) {
>         active = 1;
>     }
> -    mutex_unlock(&lock);
>
>     if (active) {
>         /* fail safe: if the aio could not be canceled, we wait for

The paio_cancel() infinite loop is still there in this patch.

http://www.mail-archive.com/qemu-devel@nongnu.org/msg44766.html

Stefan

[Qemu-devel] Re: [PATCH] QEMU_OPTION_spice is not guarded by ifdef

2010-10-27 Thread Gerd Hoffmann


I did a "make clean" before but I am still getting error about
QEMU_OPTION_spice.
Log:
(...)
   LINK  qemu-io.exe
   GEN   libhw32/qemu-options.def
   CClibhw32/vl.o
C:/msys/home/User/qemu/vl.c: In function `qemu_main':
C:/msys/home/User/qemu/vl.c:2601: error: `QEMU_OPTION_spice'
undeclared (first use in this function)


Ah, windows.

/me tries a cross build.

Works fine for me.

cheers,
  Gerd

Re: [Qemu-devel] Which qemu ports actually work?

Alexander Graf  writes:

  >  Device tree strings 0x0245 -> 0x024504d9
  >  Device tree struct  0x02451000 -> 0x02453000
  >  Calling quiesce ...
  >  returning from prom_init
  > 
  > it hangs.

  It doesn't hang. It tries to display stuff on the graphical screen
  which you disabled. You need to tell the kernel to use the serial
  console.

I take it back and say "it appears to hang to a naive user".

I suppose I'll wait until I can find some documentation, such as a
simple example from which to start, and stop DOSing your developers'
mailing list with my qemu troubles.  :-)

  >  If you need performance for this, please just grab a PPC machine and
  >  use KVM on it. It will be a lot faster.
  > 
  > Physical machines take space and need power.  Qemu is a lot leaner.  :-)

  *shrug* depends on what you want to do. If you want to actually do
  *something useful, I'd recommend KVM.

You might have different goals than me.  Speed is nice, and sometimes
critically important.  But for my project to get (pseudo) access to lots
of more hardware for GNU software testing purposes, speed is not a major
issue.  Stability, robustness, reproducibility, documentation, are
critically important to me.

-- 
Torbjörn

[Qemu-devel] Re: Which qemu ports actually work?

2010-10-27 Thread Paolo Bonzini


On 10/27/2010 11:21 AM, Torbjorn Granlund wrote:

You might have different goals than me.  Speed is nice, and sometimes
critically important.  But for my project to get (pseudo) access to lots
of more hardware for GNU software testing purposes, speed is not a major
issue.  Stability, robustness, reproducibility, documentation, are
critically important to me.


Lobbying a Debian developer into giving access to Debian porter machines 
is probably even more effective than KVM.


Paolo

Re: [Qemu-devel] [PATCH 1/2] Type-safe ioport callbacks

2010-10-27 Thread Avi Kivity

 On 10/26/2010 08:33 PM, Blue Swirl wrote:

>
>  Why two types?  I think some devices use PIO on a PC and MMIO on other
>  architectures.  Sharing the type would allow sharing code.

Then there are the functions provided by rwhandler.c. I think that
interface makes even more sense compared to 8/16/32 (and 64?) bit
handlers in many cases.

On the other hand, that makes the transition harder.

Perhaps we can have a type with {read,write}(addr, width), and another 
built on top that provides the traditional {read,write}[bwl](addr) to 
ease the transition.

--
error compiling committee.c: too many arguments to function

[al...@redhat.com: [Qemu-devel] [PATCH 0/2] add optional root to info qtree]

2010-10-27 Thread Alon Levy

bump. Doesn't anyone find it useful to view only a part of the
whole qtree? Is there some easy way to do this with current
qemu monitor?

- Forwarded message from Alon Levy  -

Date: Thu, 21 Oct 2010 08:37:18 +0200
From: Alon Levy 
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] [PATCH 0/2] add optional root to info qtree

Allow viewing of a part of the large qdev tree. The optional argument
is first looked for as a bus id, if that fails a device id is found and
it's parent bus is the root for printing.

Adds sub_args_type callback for each monitor mon_cmd_t to fascilitate the
existing info_cmds args_type and params strings, so monitor_parse_command
will check the arguments for the do_info sub command do_info_qtree.

Alon Levy (2):
  monitor: add sub_args_type for second level parameters
  monitor info qtree: add optional bus id

 hmp-commands.hx |1 +
 hw/qdev.c   |   17 ++---
 hw/qdev.h   |2 +-
 monitor.c   |   47 +--
 4 files changed, 57 insertions(+), 10 deletions(-)

-- 
1.7.3.1

- End forwarded message -

Re: [Qemu-devel] Which qemu ports actually work?

2010-10-27 Thread Alexander Graf


On 27.10.2010, at 02:21, Torbjorn Granlund wrote:

> Alexander Graf  writes:
> 
>> Device tree strings 0x0245 -> 0x024504d9
>> Device tree struct  0x02451000 -> 0x02453000
>> Calling quiesce ...
>> returning from prom_init
>> 
>> it hangs.
> 
>  It doesn't hang. It tries to display stuff on the graphical screen
>  which you disabled. You need to tell the kernel to use the serial
>  console.
> 
> I take it back and say "it appears to hang to a naive user".
> 
> I suppose I'll wait until I can find some documentation, such as a
> simple example from which to start, and stop DOSing your developers'
> mailing list with my qemu troubles.  :-)

Sounds great :). Please keep in mind that if you're running into these issues, 
others might too. And if you find something out and miss documentation, please 
create some. That's why we made everything be a wiki these days :).

> 
>> If you need performance for this, please just grab a PPC machine and
>> use KVM on it. It will be a lot faster.
>> 
>> Physical machines take space and need power.  Qemu is a lot leaner.  :-)
> 
>  *shrug* depends on what you want to do. If you want to actually do
>  *something useful, I'd recommend KVM.
> 
> You might have different goals than me.  Speed is nice, and sometimes
> critically important.  But for my project to get (pseudo) access to lots
> of more hardware for GNU software testing purposes, speed is not a major
> issue.  Stability, robustness, reproducibility, documentation, are
> critically important to me.

Yes, stability and robustness clearly speak for KVM too ;). I wouldn't trust 
the PPC emulation to a full extent and in fact, even the others might be buggy 
at times. The best guarantee for full ISA compliance is a real CPU.

Alex

Re: [Qemu-devel] Which qemu ports actually work?

Alexander Graf  writes:

  Sounds great :). Please keep in mind that if you're running into these
  issues, others might too. And if you find something out and miss
  documentation, please create some. That's why we made everything be a
  wiki these days :).

If I get a meaningful number of OS/qemu combinations to actually work, I
intend to put someting together.  I am far from there yet.  What I would
write is a simple list of commands to get *something* to work for each
tuple.

I have limited time trying to reverse engineer how things are intended
to work, how to switch this and that off via qemu.  It is usually more
efficient that developers write at least rudimentary documentation.
  
I live in this word myself, I have contributed to the GNU project since
the early 1990'ies.  I am not asking volunteers to "work harder".  But
writing great software and then make it very, very hard to use by not
spending 1% of ones time writing documentation, is poor use of the
volunteer time!

-- 
Torbjörn

[Qemu-devel] [PATCH 0/6] pcie: fixes for pci branch

This patch series fixes isseus which introduced by
5704608988972359473ce609f9e4884808115b58
cd870502e228f8f028f93fb585ae3b208fcb46c7
4b78560503a802eae3663ace9f9cf080319e7265

Isaku Yamahata (6):
  pcie: fix pcie_cap_slot_write_config().
  pcie/slot: fix hotplug_event_notify().
  pcie/slot: clean up of hotplug_event_notify().
  pcie/slot: factor out the logic to update hotplug event status.
  pcie/slot: fix save/load
  msix: remove range checks.

 hw/ioh3420.c|1 +
 hw/msix.c   |5 -
 hw/pcie.c   |   46 ++
 hw/pcie.h   |1 +
 hw/xio3130_downstream.c |1 +
 5 files changed, 33 insertions(+), 21 deletions(-)

[Qemu-devel] [PATCH 1/6] pcie: fix pcie_cap_slot_write_config().

This patch fixes pcie_cap_slot_write_config() which is broken by
5704608988972359473ce609f9e4884808115b58
The command completion event should generated only when the command
is issued (and the command is completed).

>From 6.7.3.2
> Software issues a command to a hot-plug capable Downstream Port by
> issuing a write transaction that targets any portion of the
> Port's Slot Control register. A single write to the Slot Control
> register is considered to be a single command
...
> The Port must process the command normally even if the status field is
> already set when the command is issued.

Signed-off-by: Isaku Yamahata 
---
 hw/pcie.c |   25 ++---
 1 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/hw/pcie.c b/hw/pcie.c
index 0385f53..64cc003 100644
--- a/hw/pcie.c
+++ b/hw/pcie.c
@@ -19,6 +19,7 @@
  */
 
 #include "sysemu.h"
+#include "range.h"
 #include "pci_bridge.h"
 #include "pcie.h"
 #include "msix.h"
@@ -323,17 +324,19 @@ void pcie_cap_slot_write_config(PCIDevice *dev,
 
 hotplug_event_notify(dev);
 
-/* command completion.
- * Real hardware might take a while to complete
- * requested command because physical movement would be involved
- * like locking the electromechanical lock.
- * However in our case, command is completed instantaneously above,
- * so send a command completion event right now.
- *
- * 6.7.3.2 Command Completed Events
- */
-/* set command completed bit */
-pcie_cap_slot_event(dev, PCI_EXP_HP_EV_CCI);
+if (ranges_overlap(addr, len, pos + PCI_EXP_SLTCTL, 2)) {
+/* command completion.
+ * Real hardware might take a while to complete
+ * requested command because physical movement would be involved
+ * like locking the electromechanical lock.
+ * However in our case, command is completed instantaneously above,
+ * so send a command completion event right now.
+ *
+ * 6.7.3.2 Command Completed Events
+ */
+/* set command completed bit */
+pcie_cap_slot_event(dev, PCI_EXP_HP_EV_CCI);
+}
 }
 
 void pcie_cap_slot_push_attention_button(PCIDevice *dev)
-- 
1.7.1.1

[Qemu-devel] [PATCH 3/6] pcie/slot: clean up of hotplug_event_notify().

remove redundant return and blank line from hotplug_event_notify().

Signed-off-by: Isaku Yamahata 
---
 hw/pcie.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/hw/pcie.c b/hw/pcie.c
index 3c52849..37d7457 100644
--- a/hw/pcie.c
+++ b/hw/pcie.c
@@ -164,9 +164,7 @@ static void hotplug_event_notify(PCIDevice *dev)
 qemu_set_irq(dev->irq[dev->exp.hpev_intx], dev->exp.hpev_notified);
 } else if (dev->exp.hpev_notified) {
 pci_msi_notify(dev, pcie_cap_flags_get_vector(dev));
-return;
 }
-
 }
 
 /*
-- 
1.7.1.1

[Qemu-devel] [PATCH 2/6] pcie/slot: fix hotplug_event_notify().

This patch fixes the miscondition to trigger slot event
which is introduced by cd870502e228f8f028f93fb585ae3b208fcb46c7.

Signed-off-by: Isaku Yamahata 
---
 hw/pcie.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/pcie.c b/hw/pcie.c
index 64cc003..3c52849 100644
--- a/hw/pcie.c
+++ b/hw/pcie.c
@@ -148,7 +148,7 @@ static void hotplug_event_notify(PCIDevice *dev)
 uint16_t sltsta = pci_get_word(exp_cap + PCI_EXP_SLTSTA);
 
 dev->exp.hpev_notified = (sltctl & PCI_EXP_SLTCTL_HPIE) &&
-(sltsta & PCI_EXP_HP_EV_SUPPORTED);
+(sltsta & sltctl & PCI_EXP_HP_EV_SUPPORTED);
 
 if (prev == dev->exp.hpev_notified) {
 return;
-- 
1.7.1.1

[Qemu-devel] [PATCH 4/6] pcie/slot: factor out the logic to update hotplug event status.

This patch factors out the hot plug event logic.

Signed-off-by: Isaku Yamahata 
---
 hw/pcie.c |   10 --
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/hw/pcie.c b/hw/pcie.c
index 37d7457..97d17fa 100644
--- a/hw/pcie.c
+++ b/hw/pcie.c
@@ -139,9 +139,8 @@ void pcie_cap_deverr_reset(PCIDevice *dev)
  PCI_EXP_DEVCTL_FERE | PCI_EXP_DEVCTL_URRE);
 }
 
-static void hotplug_event_notify(PCIDevice *dev)
+static void hotplug_event_update_event_status(PCIDevice *dev)
 {
-bool prev = dev->exp.hpev_notified;
 uint32_t pos = dev->exp.exp_cap;
 uint8_t *exp_cap = dev->config + pos;
 uint16_t sltctl = pci_get_word(exp_cap + PCI_EXP_SLTCTL);
@@ -149,6 +148,13 @@ static void hotplug_event_notify(PCIDevice *dev)
 
 dev->exp.hpev_notified = (sltctl & PCI_EXP_SLTCTL_HPIE) &&
 (sltsta & sltctl & PCI_EXP_HP_EV_SUPPORTED);
+}
+
+static void hotplug_event_notify(PCIDevice *dev)
+{
+bool prev = dev->exp.hpev_notified;
+
+hotplug_event_update_event_status(dev);
 
 if (prev == dev->exp.hpev_notified) {
 return;
-- 
1.7.1.1

[Qemu-devel] [PATCH 5/6] pcie/slot: fix save/load

This patch fixes save/load of pcie slot which was broken by
cd870502e228f8f028f93fb585ae3b208fcb46c7.

Signed-off-by: Isaku Yamahata 
---
 hw/ioh3420.c|1 +
 hw/pcie.c   |7 +++
 hw/pcie.h   |1 +
 hw/xio3130_downstream.c |1 +
 4 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/hw/ioh3420.c b/hw/ioh3420.c
index 23aecbf..3cc129f 100644
--- a/hw/ioh3420.c
+++ b/hw/ioh3420.c
@@ -139,6 +139,7 @@ static const VMStateDescription vmstate_ioh3420 = {
 .version_id = 1,
 .minimum_version_id = 1,
 .minimum_version_id_old = 1,
+.post_load = pcie_cap_slot_post_load,
 .fields = (VMStateField[]) {
 VMSTATE_PCIE_DEVICE(port.br.dev, PCIESlot),
 /* TODO: AER */
diff --git a/hw/pcie.c b/hw/pcie.c
index 97d17fa..23e35dc 100644
--- a/hw/pcie.c
+++ b/hw/pcie.c
@@ -343,6 +343,13 @@ void pcie_cap_slot_write_config(PCIDevice *dev,
 }
 }
 
+int pcie_cap_slot_post_load(void *opaque, int version_id)
+{
+PCIDevice *dev = opaque;
+hotplug_event_update_event_status(dev);
+return 0;
+}
+
 void pcie_cap_slot_push_attention_button(PCIDevice *dev)
 {
 pcie_cap_slot_event(dev, PCI_EXP_HP_EV_ABP);
diff --git a/hw/pcie.h b/hw/pcie.h
index 39c6e47..8708504 100644
--- a/hw/pcie.h
+++ b/hw/pcie.h
@@ -95,6 +95,7 @@ void pcie_cap_slot_init(PCIDevice *dev, uint16_t slot);
 void pcie_cap_slot_reset(PCIDevice *dev);
 void pcie_cap_slot_write_config(PCIDevice *dev,
 uint32_t addr, uint32_t val, int len);
+int pcie_cap_slot_post_load(void *opaque, int version_id);
 void pcie_cap_slot_push_attention_button(PCIDevice *dev);
 
 void pcie_cap_root_init(PCIDevice *dev);
diff --git a/hw/xio3130_downstream.c b/hw/xio3130_downstream.c
index d46f911..854eba8 100644
--- a/hw/xio3130_downstream.c
+++ b/hw/xio3130_downstream.c
@@ -141,6 +141,7 @@ static const VMStateDescription vmstate_xio3130_downstream 
= {
 .version_id = 1,
 .minimum_version_id = 1,
 .minimum_version_id_old = 1,
+.post_load = pcie_cap_slot_post_load,
 .fields = (VMStateField[]) {
 VMSTATE_PCIE_DEVICE(port.br.dev, PCIESlot),
 /* TODO: AER */
-- 
1.7.1.1

[Qemu-devel] [PATCH 6/6] msix: remove range checks.

Same as 4b78560503a802eae3663ace9f9cf080319e7265
> config write handlers should be idempotent.
> So no need for range checks.

Signed-off-by: Isaku Yamahata 
---
 hw/msix.c |5 -
 1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/hw/msix.c b/hw/msix.c
index f66d255..20caa5e 100644
--- a/hw/msix.c
+++ b/hw/msix.c
@@ -157,14 +157,9 @@ static void msix_handle_mask_update(PCIDevice *dev, int 
vector)
 void msix_write_config(PCIDevice *dev, uint32_t addr,
uint32_t val, int len)
 {
-unsigned enable_pos = dev->msix_cap + MSIX_CONTROL_OFFSET;
 int vector;
 int i;
 
-if (!range_covers_byte(addr, len, enable_pos)) {
-return;
-}
-
 if (!msix_enabled(dev)) {
 return;
 }
-- 
1.7.1.1

[Qemu-devel] [PATCH 1/3] ide: Handle immediate bdrv_aio_flush failure

If bdrv_aio_flush returns NULL, this should be treated as an error.

Signed-off-by: Kevin Wolf 
---
 hw/ide/core.c |   12 +---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/hw/ide/core.c b/hw/ide/core.c
index bc3e916..484e0ca 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -811,10 +811,16 @@ static void ide_flush_cb(void *opaque, int ret)
 
 static void ide_flush_cache(IDEState *s)
 {
-if (s->bs) {
-bdrv_aio_flush(s->bs, ide_flush_cb, s);
-} else {
+BlockDriverAIOCB *acb;
+
+if (s->bs == NULL) {
 ide_flush_cb(s, 0);
+return;
+}
+
+acb = bdrv_aio_flush(s->bs, ide_flush_cb, s);
+if (acb == NULL) {
+ide_flush_cb(s, -EIO);
 }
 }
 
-- 
1.7.2.3

[Qemu-devel] [PATCH 3/3] scsi-disk: Fix immediate failure of bdrv_aio_*

Fix scsi-disk to use the usual completion paths that involve rerror/werror
handling instead of directly completing the requests in cases where
bdrv_aio_readv/writev returns NULL.

Signed-off-by: Kevin Wolf 
---
 hw/scsi-disk.c |   11 ++-
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index a1976ea..18b4d1a 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -178,8 +178,9 @@ static void scsi_read_request(SCSIDiskReq *r)
 qemu_iovec_init_external(&r->qiov, &r->iov, 1);
 r->req.aiocb = bdrv_aio_readv(s->bs, r->sector, &r->qiov, n,
   scsi_read_complete, r);
-if (r->req.aiocb == NULL)
-scsi_command_complete(r, CHECK_CONDITION, HARDWARE_ERROR);
+if (r->req.aiocb == NULL) {
+scsi_read_complete(r, -EIO);
+}
 }
 
 /* Read more data from scsi device into buffer.  */
@@ -274,9 +275,9 @@ static void scsi_write_request(SCSIDiskReq *r)
 qemu_iovec_init_external(&r->qiov, &r->iov, 1);
 r->req.aiocb = bdrv_aio_writev(s->bs, r->sector, &r->qiov, n,
scsi_write_complete, r);
-if (r->req.aiocb == NULL)
-scsi_command_complete(r, CHECK_CONDITION,
-  HARDWARE_ERROR);
+if (r->req.aiocb == NULL) {
+scsi_write_complete(r, -EIO);
+}
 } else {
 /* Invoke completion routine to fetch data from host.  */
 scsi_write_complete(r, 0);
-- 
1.7.2.3

[Qemu-devel] [PATCH 2/3] virtio-blk: Handle immediate flush failure properly

Fix virtio-blk to use the usual completion path that involves werror handling
instead of directly completing the request in cases where bdrv_aio_flush
returns NULL.

Signed-off-by: Kevin Wolf 
---
 hw/virtio-blk.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index dbe2070..49528a9 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -273,7 +273,7 @@ static void virtio_blk_handle_flush(VirtIOBlockReq *req, 
MultiReqBuffer *mrb)
 
 acb = bdrv_aio_flush(req->dev->bs, virtio_blk_flush_complete, req);
 if (!acb) {
-virtio_blk_req_complete(req, VIRTIO_BLK_S_IOERR);
+virtio_blk_flush_complete(req, -EIO);
 }
 }
 
-- 
1.7.2.3

[Qemu-devel] [PATCH 0/3] Consider werror/rerror on immediate bdrv_aio_* failure

There are still paths where werror/rerror is ignored and an error is directly
communicated to the guest. This series fixes some of them.

Kevin Wolf (3):
  ide: Handle immediate bdrv_aio_flush failure
  virtio-blk: Handle immediate flush failure properly
  scsi-disk: Fix immediate failure of bdrv_aio_*

 hw/ide/core.c   |   12 +---
 hw/scsi-disk.c  |   11 ++-
 hw/virtio-blk.c |2 +-
 3 files changed, 16 insertions(+), 9 deletions(-)

-- 
1.7.2.3

Re: [Qemu-devel] Re: [PATCH] vhost-net: Do not set features for backend when peer was deleted

On Wed, Oct 27, 2010 at 02:59:16PM +0800, Jason Wang wrote:
> Michael S. Tsirkin writes:
>  > On Wed, Oct 27, 2010 at 12:43:51AM +0800, Jason Wang wrote:
>  > > When hot-unplug a virtio nic with vhost-net backend, guest may
>  > > continue to program the nic even if its peer have been deleted. We can
>  > > not set features at this time as vhost_net_ack_features() may still
>  > > try to use the tap related vhost_net structure which have been freed
>  > > in tap_cleanup(). And setting offload features for a deleted backend
>  > > is also meaningless in this situation
>  > > 
>  > > Signed-off-by: Jason Wang 
>  > 
>  > Hmm. Actually, this is not enough.
>  > We really must stop and cleanup vhost net.
>  > 
> 
> But this patch just prevent the guest from programming a nic with its
> vhost-net backend deleted. The vhost net was still stopped and cleaned
> when the peer have been removed.

No, I think it was cleanup but not stopped first. E.g. try to migrate at
this point and see it crash. I suspect we also leak fds for notifiers
and what not.

>  > Two issues are 
>  > 1. vhost_net_stop needs virtio device pointer
>  > 2. virtio net has a vhost_started flag
>  > 
>  > Two ways to fix it that I see:
>  > 1. add a callback in nic and invoke when peer_deleted is set
>  > 2. add vhost_started and virtio device pointers in vhost
>  > 
>  > Path 1 seems easier ...
>  > 
>  > MST
>  > 
>  > > ---
>  > >  hw/virtio-net.c |3 +++
>  > >  1 files changed, 3 insertions(+), 0 deletions(-)
>  > > 
>  > > diff --git a/hw/virtio-net.c b/hw/virtio-net.c
>  > > index 7e1688c..68c8e48 100644
>  > > --- a/hw/virtio-net.c
>  > > +++ b/hw/virtio-net.c
>  > > @@ -245,6 +245,9 @@ static void virtio_net_set_features(VirtIODevice 
> *vdev, uint32_t features)
>  > >  {
>  > >  VirtIONet *n = to_virtio_net(vdev);
>  > >  
>  > > +if (n->nic->peer_deleted)
>  > > +return;
>  > > +
>  > >  n->mergeable_rx_bufs = !!(features & (1 << VIRTIO_NET_F_MRG_RXBUF));
>  > >  
>  > >  if (n->has_vnet_hdr) {
>  >

Re: [Qemu-devel] Re: [PATCH v6 07/12] pcie/hotplug: introduce pushing attention button command

On Wed, Oct 27, 2010 at 10:47:11AM +0900, Isaku Yamahata wrote:
> On Mon, Oct 25, 2010 at 04:02:36PM +0900, Isaku Yamahata wrote:
> > > > > What I am also saying is that the same command should be able
> > > > > to work for pci and express I think.
> > > > 
> > > > I see. Then, I think that the slot numbering needs to be discussed.
> > > 
> > > Yes.
> > > 
> > > > More concretely, it's what type of argument is passed for push attention
> > > > button command.
> > > > Here the slot number in general means that the number that is printed 
> > > > near
> > > > the physical slot. Not pci (segment, bus, device) triplets.
> > > > 
> > > > The current qemu pci hot plug abuses the triplets as the slot number
> > > > with the assumption of (segment = 0, bus = 0, device = slot number).
> > > > On the other hand, pcie hot plug has its own scheme to number the slots.
> > > > The correspondence between the triplets and the slot is provided
> > > > to the OS. (The standard pci hot plug has its own too which is different
> > > > from the pcie one.)
> > > > So users may want to operate with the slot number.
> > > > User's opinions are needed. Any comments?
> > > > 
> > > > thanks,
> > > 
> > > Can we just use the topological address everywhere?
> > > Bus numbers are guest assigned, so we can not always
> > > rely on them. They are nice for human monitor
> > > though and should be way to get from them to
> > > topology and back.
> > > And for bus 0 they are equivalent.
> > 
> > Yes, with some kind of conversion.
> > We could go with whichever addressing with (slight?) effort
> > to implement conversion.
> > The point is what users(libvirt? virt-manager?) want.
> 
> When pushing the attention button, we are talking to the hot plug
> controller, not the device in the slot.
> The button can be pushed even when the slot is empty.
> 
> In qemu pci hot plug case the button is used only for device
> ejection, so (segment, bus, device) triplet (or any address to specify
> the device in the slot) works.
> But such address doesn't work for pcie case. (nor for standard pci hot
> plug case)
> Address that will be used should be able to specify the slot itself
> without the device.

Not sure I understand.  The device number is the number of the slot on
the bus anyway, isn't it? The only issue is that the bus must be
specified by the topology used to reach it, not bus number
since that is guest assigned expect for the root which is always 0.


> -- 
> yamahata

[Qemu-devel] [PATCH] pci: improve w1c mask handling

- save/restore must not check w1c bits
  since they are in fact guest controlled
- clear w1c bits on reset

Note: for express there are different kinds of
reset, some leave part of config space alone.
We will likely need a sticky bit mask to implement this.

Signed-off-by: Michael S. Tsirkin 
---

Isaku, does the below make sense?

 hw/pci.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index e50de14..1a14a0e 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -141,7 +141,8 @@ static void pci_device_reset(PCIDevice *dev)
 pci_update_irq_status(dev);
 /* Clear all writeable bits */
 pci_word_test_and_clear_mask(dev->config + PCI_COMMAND,
- pci_get_word(dev->wmask + PCI_COMMAND));
+ pci_get_word(dev->wmask + PCI_COMMAND) |
+ pci_get_word(dev->w1cmask + PCI_COMMAND));
 dev->config[PCI_CACHE_LINE_SIZE] = 0x0;
 dev->config[PCI_INTERRUPT_LINE] = 0x0;
 for (r = 0; r < PCI_NUM_REGIONS; ++r) {
@@ -293,7 +294,8 @@ static int get_pci_config_device(QEMUFile *f, void *pv, 
size_t size)
 
 qemu_get_buffer(f, config, size);
 for (i = 0; i < size; ++i) {
-if ((config[i] ^ s->config[i]) & s->cmask[i] & ~s->wmask[i]) {
+if ((config[i] ^ s->config[i]) &
+s->cmask[i] & ~s->wmask[i] & ~s->w1cmask) {
 qemu_free(config);
 return -EINVAL;
 }
-- 
1.7.3.2.91.g446ac

[Qemu-devel] [PATCH] msi: minor cleanups

Comment fixup (tell what it does not what it does not do),
typo fix, whitespace fix.

Signed-off-by: Michael S. Tsirkin 
---
 hw/msi.c |7 +++
 1 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/hw/msi.c b/hw/msi.c
index 016e7a4..f03f519 100644
--- a/hw/msi.c
+++ b/hw/msi.c
@@ -155,9 +155,8 @@ int msi_init(struct PCIDevice *dev, uint8_t offset,
 pci_set_word(dev->wmask + msi_data_off(dev, msi64bit), 0x);
 
 if (msi_per_vector_mask) {
+/* Make mask bits 0 to nr_vectors - 1 writeable. */
 pci_set_long(dev->wmask + msi_mask_off(dev, msi64bit),
- /* (1U << nr_vectors) - 1 is undefined
-when nr_vectors = 32 */
  0x >> (PCI_MSI_VECTORS_MAX - nr_vectors));
 }
 return config_offset;
@@ -225,7 +224,7 @@ void msi_notify(PCIDevice *dev, unsigned int vector)
 return;
 }
 
-if (msi64bit){
+if (msi64bit) {
 address = pci_get_quad(dev->config + msi_address_lo_off(dev));
 } else {
 address = pci_get_long(dev->config + msi_address_lo_off(dev));
@@ -269,7 +268,7 @@ void msi_write_config(PCIDevice *dev, uint32_t addr, 
uint32_t val, int len)
flags,
pci_get_long(dev->config + msi_address_lo_off(dev)));
 if (msi64bit) {
-fprintf(stderr, " addrss-hi: 0x%"PRIx32,
+fprintf(stderr, " address-hi: 0x%"PRIx32,
 pci_get_long(dev->config + msi_address_hi_off(dev)));
 }
 fprintf(stderr, " data: 0x%"PRIx16,
-- 
1.7.3.2.91.g446ac

[Qemu-devel] [PATCH] msi: simplify range checks

config write handlers should be idempotent.
So no need for complex range checks: a simple
one checking that we are touching the relevant capability
will do.

Signed-off-by: Michael S. Tsirkin 
---

How does the below look?

 hw/msi.c |   46 +-
 1 files changed, 21 insertions(+), 25 deletions(-)

diff --git a/hw/msi.c b/hw/msi.c
index a949d82..016e7a4 100644
--- a/hw/msi.c
+++ b/hw/msi.c
@@ -257,34 +257,29 @@ void msi_write_config(PCIDevice *dev, uint32_t addr, 
uint32_t val, int len)
 uint32_t pending;
 int i;
 
-#ifdef MSI_DEBUG
-if (ranges_overlap(addr, len, dev->msi_cap, msi_cap_sizeof(flags))) {
-MSI_DEV_PRINTF(dev, "addr 0x%"PRIx32" val 0x%"PRIx32" len %d\n",
-   addr, val, len);
-MSI_DEV_PRINTF(dev, "ctrl: 0x%"PRIx16" address: 0x%"PRIx32,
-   flags,
-   pci_get_long(dev->config + msi_address_lo_off(dev)));
-if (msi64bit) {
-fprintf(stderr, " addrss-hi: 0x%"PRIx32,
-pci_get_long(dev->config + msi_address_hi_off(dev)));
-}
-fprintf(stderr, " data: 0x%"PRIx16,
-pci_get_word(dev->config + msi_data_off(dev, msi64bit)));
-if (flags & PCI_MSI_FLAGS_MASKBIT) {
-fprintf(stderr, " mask 0x%"PRIx32" pending 0x%"PRIx32,
-pci_get_long(dev->config + msi_mask_off(dev, msi64bit)),
-pci_get_long(dev->config + msi_pending_off(dev, 
msi64bit)));
-}
-fprintf(stderr, "\n");
+if (!ranges_overlap(addr, len, dev->msi_cap, msi_cap_sizeof(flags))) {
+return;
 }
-#endif
 
-/* Are we modified? */
-if (!(ranges_overlap(addr, len, msi_flags_off(dev), 2) ||
-  (msi_per_vector_mask &&
-   ranges_overlap(addr, len, msi_mask_off(dev, msi64bit), 4 {
-return;
+#ifdef MSI_DEBUG
+MSI_DEV_PRINTF(dev, "addr 0x%"PRIx32" val 0x%"PRIx32" len %d\n",
+   addr, val, len);
+MSI_DEV_PRINTF(dev, "ctrl: 0x%"PRIx16" address: 0x%"PRIx32,
+   flags,
+   pci_get_long(dev->config + msi_address_lo_off(dev)));
+if (msi64bit) {
+fprintf(stderr, " addrss-hi: 0x%"PRIx32,
+pci_get_long(dev->config + msi_address_hi_off(dev)));
 }
+fprintf(stderr, " data: 0x%"PRIx16,
+pci_get_word(dev->config + msi_data_off(dev, msi64bit)));
+if (flags & PCI_MSI_FLAGS_MASKBIT) {
+fprintf(stderr, " mask 0x%"PRIx32" pending 0x%"PRIx32,
+pci_get_long(dev->config + msi_mask_off(dev, msi64bit)),
+pci_get_long(dev->config + msi_pending_off(dev, msi64bit)));
+}
+fprintf(stderr, "\n");
+#endif
 
 if (!(flags & PCI_MSI_FLAGS_ENABLE)) {
 return;
-- 
1.7.3.2.91.g446ac

[Qemu-devel] Re: [PATCH 6/6] msix: remove range checks.

On Wed, Oct 27, 2010 at 07:21:21PM +0900, Isaku Yamahata wrote:
> Same as 4b78560503a802eae3663ace9f9cf080319e7265
> > config write handlers should be idempotent.
> > So no need for range checks.
> 
> Signed-off-by: Isaku Yamahata 

Well I changed my mind on 4b78560503a802eae3663ace9f9cf080319e7265 :) As
long as the check is simple, it does not hurt.

> ---
>  hw/msix.c |5 -
>  1 files changed, 0 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/msix.c b/hw/msix.c
> index f66d255..20caa5e 100644
> --- a/hw/msix.c
> +++ b/hw/msix.c
> @@ -157,14 +157,9 @@ static void msix_handle_mask_update(PCIDevice *dev, int 
> vector)
>  void msix_write_config(PCIDevice *dev, uint32_t addr,
> uint32_t val, int len)
>  {
> -unsigned enable_pos = dev->msix_cap + MSIX_CONTROL_OFFSET;
>  int vector;
>  int i;
>  
> -if (!range_covers_byte(addr, len, enable_pos)) {
> -return;
> -}
> -
>  if (!msix_enabled(dev)) {
>  return;
>  }
> -- 
> 1.7.1.1

Re: [Qemu-devel] Re: [PATCH] Implement a virtio GPU transport

2010-10-27 Thread Ian Molton


On 19/10/10 11:39, Avi Kivity wrote:

On 10/19/2010 12:31 PM, Ian Molton wrote:



2. should start with a patch to the virtio-pci spec to document what
you're doing


Where can I find that spec?


http://ozlabs.org/~rusty/virtio-spec/


Ok, but I'm not patching that until theres been some review.

There are links to the associated qemu and guest OS changes in my 
original email.



It doesnt, at present... It could be changed fairly easily ithout
breaking anything if that happens though.


The hypervisor and the guest can be changed independently. The driver
should be coded so that it doesn't depend on hypervisor implementation
details.


Fixed - updated patch tested and attached.

-Ian
diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile
index 30879df..35699a0 100644
--- a/drivers/gpu/Makefile
+++ b/drivers/gpu/Makefile
@@ -1 +1 @@
-obj-y			+= drm/ vga/
+obj-y			+= drm/ vga/ misc/
diff --git a/drivers/gpu/misc/Kconfig b/drivers/gpu/misc/Kconfig
new file mode 100644
index 000..50043d3
--- /dev/null
+++ b/drivers/gpu/misc/Kconfig
@@ -0,0 +1,8 @@
+config VIRTIOGL
+tristate "Virtio userspace memory transport"
+depends on VIRTIO_PCI
+default n
+help
+  A Driver to facilitate transferring data from userspace to a
+  hypervisor (eg. qemu)
+
diff --git a/drivers/gpu/misc/Makefile b/drivers/gpu/misc/Makefile
new file mode 100644
index 000..d9ab333
--- /dev/null
+++ b/drivers/gpu/misc/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIRTIOGL)  += virtio-gl.o
diff --git a/drivers/gpu/misc/virtio-gl.c b/drivers/gpu/misc/virtio-gl.c
new file mode 100644
index 000..ad3ba14
--- /dev/null
+++ b/drivers/gpu/misc/virtio-gl.c
@@ -0,0 +1,325 @@
+/*
+ * Copyright (C) 2010 Intel Corporation
+ *
+ * Author: Ian Molton 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEVICE_NAME "glmem"
+
+/* Define to use debugging checksums on transfers */
+#undef DEBUG_GLIO
+
+struct virtio_gl_data {
+	char *buffer;
+	int pages;
+	unsigned int pid;
+	struct completion done;
+};
+
+struct virtio_gl_header {
+	int pid;
+	int buf_size;
+	int r_buf_size;
+#ifdef DEBUG_GLIO
+	int sum;
+#endif
+	char buffer;
+} __packed;
+
+#define to_virtio_gl_data(a)   ((struct virtio_gl_data *)(a)->private_data)
+
+#ifdef DEBUG_GLIO
+#define SIZE_OUT_HEADER (sizeof(int)*4)
+#define SIZE_IN_HEADER (sizeof(int)*2)
+#else
+#define SIZE_OUT_HEADER (sizeof(int)*3)
+#define SIZE_IN_HEADER sizeof(int)
+#endif
+
+static struct virtqueue *vq;
+
+static void glmem_done(struct virtqueue *vq)
+{
+	struct virtio_gl_data *gldata;
+	int count;
+
+	gldata = virtqueue_get_buf(vq, &count);
+
+	if (!gldata)
+		BUG();
+
+	complete(&gldata->done);
+}
+
+/* This is videobuf_vmalloc_to_sg() from videobuf-dma-sg.c with
+ * some modifications
+ */
+static struct scatterlist *vmalloc_to_sg(struct scatterlist *sg_list,
+unsigned char *virt, unsigned int pages)
+{
+	struct page *pg;
+
+	/* unaligned */
+	BUG_ON((ulong)virt & ~PAGE_MASK);
+
+	/* Fill with elements for the data */
+	while (pages) {
+		pg = vmalloc_to_page(virt);
+		if (!pg)
+			goto err;
+
+		sg_set_page(sg_list, pg, PAGE_SIZE, 0);
+		virt += PAGE_SIZE;
+		sg_list++;
+		pages--;
+	}
+
+	return sg_list;
+
+err:
+	kfree(sg_list);
+	return NULL;
+}
+
+static int put_data(struct virtio_gl_data *gldata)
+{
+	struct scatterlist *sg, *sg_list;
+	unsigned int ret, o_page, i_page, sg_entries;
+	struct virtio_gl_header *header =
+(struct virtio_gl_header *)gldata->buffer;
+
+	ret = header->buf_size;
+
+	o_page = (header->buf_size + PAGE_SIZE-1) >> PAGE_SHIFT;
+	i_page = (header->r_buf_size + PAGE_SIZE-1) >> PAGE_SHIFT;
+
+	header->pid = gldata->pid;
+
+	if ((o_page && i_page) &&
+		(o_page > gldata->pages || i_page > gldata->pages)) {
+		i_page = 0;
+	}
+
+	if (o_page > gldata->pages)
+		o_page = gldata->pages;
+
+	if (i_page > gldata->pages)
+		i_page = gldata->pages;
+
+	if (!o_page)
+		o_page = 1;
+
+	sg_entries = o_page + i_page;
+
+	sg_list = kcalloc(sg_entries, sizeof(struct scatterlist), GFP_KERNEL);
+
+	if (!sg_list) {
+		ret = -EIO;
+		goto out;
+	}
+
+	sg_init_table(sg_list, sg_entries);
+
+	sg = vmalloc_to_sg(sg_list, gldata->buffer, o_page);
+	sg = vmalloc_to_s

[Qemu-devel] Re: [SeaBIOS] [PATCH] mark irq9 active high in DSDT

2010-10-27 Thread Avi Kivity


 On 10/25/2010 12:52 PM, Avi Kivity wrote:

I'm okay with making tags and branches of seabios for bug fixes.  So
far qemu/kvm has just grabbed various builds of seabios - is it
worthwhile to branch off of the seabios-0.6.1 version - which would
mean qemu/kvm would pull in additional changes beyond the bug fix
above?



qemu 0.12 is based on 0.5.1-stable, appears to be an untagged commit
qemu 0.13 is based on 17d3e46511, doesn't appear to be a part of a 
branch or a tag?


git-wise, tags are more important than branches.  You can always 
retrofit a branch to a tag (and you can always retrofit a tag to a 
commit hash).  For the qemu git repositories, neither matter so much 
since the commit is recorded in git; but the distro people really like 
nice stable tags with lots of digits and dots in them.




On the last kvm conf call Anthony said that he'll be happy to include an 
updated seabios with qemu 0.13.1, so a new release would be appreciated.



--
error compiling committee.c: too many arguments to function

[Qemu-devel] [Bug 655120] Re: VirtFS EFAULT when accessing not existing files

2010-10-27 Thread James Morse

Reproducible here with guest kernel 2.6.36 built for i686 and qemu-kvm built
from a fresh git clone taken on 27/10/2010.
Host kernel is 2.6.30.10105.2.23.fc11.i686.PAE
Guest 9p filesystem mounted as both 9p2000.u and 9p2000.L with the same problem.

In the guest syscall 'stat' on a non-existent path returns EFAULT (bad address)
instead of ENOENT.
This also affects syscall 'open', and is preventing new files from being
created.

I believe this is caused by 'v9fs_vfs_lookup' in 'fs/9p/vfs_inode.c' returning
EFAULT instead of ENOENT.
'p9_client_walk' also returns EFAULT instead of ENOENT.
Eventually we get to 'pdu_read' in 'net/9p/protocol.c', which is being called
to read '4 bytes', but calculates the space left in the 'pdu' (offset:10
size:11) as being 1. This call returns '3' (presumably how many bytes are left
unread).
In this case it gets back to 9pdu_vreadf, on line 178, (reading a 'd' 32bit
integer), which sets EFAULT as the error code.

This then propagates all the way back to vfs.

This looks to me like a short-read, but I don't know enough about the plan9
filesystem protocol to be able to debug this further.

** Attachment added: "Stack trace from pdu_read"

https://bugs.launchpad.net/qemu/+bug/655120/+attachment/1713038/+files/9p_shortread_stacktrace.txt

--
VirtFS EFAULT when accessing not existing files
https://bugs.launchpad.net/bugs/655120
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New

Bug description:
use as client Debian squeeze i386 with a custom kernel:
Linux (none) 2.6.35.5 #3 Thu Sep 23 18:36:02 UTC 2010 i686 GNU/Linux

And as host Debian squeeze amd64
Linux asd 2.6.32-5-amd64 #1 SMP Fri Sep 17 21:50:19 UTC 2010 x86_64 GNU/Linux

kvm version is:
kvm-88-5908-gdd67374

Started the client using:
sudo /usr/local/kvm/bin/qemu-system-x86_64 -m 1024 -kernel linux-2.6.35.5.qemu
-drive file=root.img,if=virtio -net
nic,macaddr=02:ca:ff:ee:ba:be,model=virtio,vlan=1 -net
tap,ifname=tap1,vlan=1,script=no -virtfs
local,path=/host,security_model=mapped,mount_tag=host -nographic

I've done following inside the guest:
$ mount -t 9p -o trans=virtio,version=9p2000.L host /mnt
$ ls -l /mnt/not-existing
ls: cannot access /mnt/not-existing: Bad address

This does not happen when not using 9p2000.L
$ mount -t 9p -o trans=virtio host /mnt
$ ls -l /mnt/not-existing
ls: cannot access /mnt/not-existing: No such file or directory

This return code will for example break make or many other tools.
$ echo $PATH
/mnt/usr/bin:/mnt/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$ make KERNELDIR=/usr/src/linux
make: execvp: pwd: Bad address
Makefile:54: /Makefile.linux: No such file or directory
make: *** No rule to make target `/Makefile.linux'. Stop.

[Qemu-devel] bonito: PCI_STATUS questions

I see code in bonito.c that clears bits:
PCI_STATUS_REC_MASTER_ABORT | PCI_STATUS_REC_TARGET_ABORT
on each read and write.

However
1. I don't see anything in code that would set these bits
2. The PCI spec says this about the status register:

Reads to this register behave normally. Writes are slightly different in
that bits can be reset, but not set. A one bit is reset (if it is not
read-only) whenever the register is written, and the write data in the
corresponding bit location is a 1. For instance, to clear bit 14 and not
affect any other bits, write the value 0100___b to the
register.

while the code in bonito.c resets the bits to 0 on each write.

Comments?

-- 
MST

[Qemu-devel] Re: [PATCH 0/6] pcie: fixes for pci branch

On Wed, Oct 27, 2010 at 07:21:15PM +0900, Isaku Yamahata wrote:
> This patch series fixes isseus which introduced by
> 5704608988972359473ce609f9e4884808115b58
> cd870502e228f8f028f93fb585ae3b208fcb46c7
> 4b78560503a802eae3663ace9f9cf080319e7265

OK, I applied this, except I basically backed out range check changes.
Pls take a look at the branch, and test if possible -
if OK with you I think we can merge this part.

> Isaku Yamahata (6):
>   pcie: fix pcie_cap_slot_write_config().
>   pcie/slot: fix hotplug_event_notify().
>   pcie/slot: clean up of hotplug_event_notify().
>   pcie/slot: factor out the logic to update hotplug event status.
>   pcie/slot: fix save/load
>   msix: remove range checks.
> 
>  hw/ioh3420.c|1 +
>  hw/msix.c   |5 -
>  hw/pcie.c   |   46 ++
>  hw/pcie.h   |1 +
>  hw/xio3130_downstream.c |1 +
>  5 files changed, 33 insertions(+), 21 deletions(-)

[Qemu-devel] Re: [PULL-stable] virtio, vhost, migration

On Tue, Oct 26, 2010 at 05:22:55PM +0200, Michael S. Tsirkin wrote:
> 
> The following changes since commit 6ed912999d6ef636a5be5ccb266d7d3c0f0310b4:
> 
>   Update for 0.13.0 release (2010-10-14 10:00:59 -0500)
> 
> are available in the git repository at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git stable-0.13
> 
> Michael S. Tsirkin (3):
>   vhost: enable log before starting vq
>   migration: don't segfault on invalid input
>   virtio: sanity-check available index

Ugh, the vhost patch is broken. Please don't merge yet, I will
send another request separately.

>  arch_init.c |3 +++
>  hw/vhost.c  |   20 ++--
>  hw/virtio.c |   11 +++
>  3 files changed, 24 insertions(+), 10 deletions(-)

Re: [Qemu-devel] [PATCH 0/6] The windows 7 audio support patch series.

2010-10-27 Thread malc

On Wed, 27 Oct 2010, Gerd Hoffmann wrote:

>   Hi,
> 
> This patch series brings a bunch of pulseaudio tweaks and two new sound
> devices.  Number one is the slightly improved usb-audio patch which was
> originally created by hpa.  Number two is a virtual HD Audio controller
> with HDA codecs.
> 

Nice timing there. I wonder how long it took bright folks at redhat to
code this HDA stuff? Since yesterday i was contacted by folks who wanted
to pay money to get VirtualBox's HDA ported to QEMU, and it took me from
16:00 today till basically 15 minutes ago to get the sound pumping from
DOS and Linux..

Regardless of the answer to my question the NIH is such a nice thing, eh?

[..snip..]

-- 
mailto:av1...@comtv.ru

Re: [Qemu-devel] [PATCH 0/6] The windows 7 audio support patch series.

2010-10-27 Thread malc

On Wed, 27 Oct 2010, malc wrote:

> On Wed, 27 Oct 2010, Gerd Hoffmann wrote:
> 
> >   Hi,
> > 
> > This patch series brings a bunch of pulseaudio tweaks and two new sound
> > devices.  Number one is the slightly improved usb-audio patch which was
> > originally created by hpa.  Number two is a virtual HD Audio controller
> > with HDA codecs.
> > 
> 
> Nice timing there. I wonder how long it took bright folks at redhat to
> code this HDA stuff? Since yesterday i was contacted by folks who wanted
> to pay money to get VirtualBox's HDA ported to QEMU, and it took me from
> 16:00 today till basically 15 minutes ago to get the sound pumping from
> DOS and Linux..
> 
> Regardless of the answer to my question the NIH is such a nice thing, eh?
> 
> [..snip..]
> 

Uh, Wu Fengguang did an initial stab at porting the code, sorry for 
fogetting to mention this.

P.S. It would be nice to see audio related stuff being CC-ed to audio
 maintainer btw.

-- 
mailto:av1...@comtv.ru

[Qemu-devel] [PATCH] block: fix the use of protocols in backing files

Signed-off-by: Anthony Liguori 

diff --git a/block.c b/block.c
index 1a965b2..00b6f21 100644
--- a/block.c
+++ b/block.c
@@ -603,10 +603,16 @@ int bdrv_open(BlockDriverState *bs, const char *filename, 
int flags,
 BlockDriver *back_drv = NULL;
 
 bs->backing_hd = bdrv_new("");
-path_combine(backing_filename, sizeof(backing_filename),
- filename, bs->backing_file);
-if (bs->backing_format[0] != '\0')
-back_drv = bdrv_find_format(bs->backing_format);
+back_drv = bdrv_find_protocol(bs->backing_file);
+if (!back_drv) {
+path_combine(backing_filename, sizeof(backing_filename),
+ filename, bs->backing_file);
+if (bs->backing_format[0] != '\0')
+back_drv = bdrv_find_format(bs->backing_format);
+} else {
+pstrcpy(backing_filename, sizeof(backing_filename),
+bs->backing_file);
+}
 
 /* backing files always opened read-only */
 back_flags =
-- 
1.7.0.4

Re: [Qemu-devel] [RFC 0/2]: QMP: Human Monitor passthrough


On 10/25/2010 03:06 PM, Luiz Capitulino wrote:

This is my first try on implementing HMP passthrough via QMP. I've tried
to follow Anthony's advice on creating a buffered char device.

If this approach is good (and the implementation is not faulty), I believe
this is very near a mergeble state (although I haven't tested much yet).
   


Looks good to me.

Regards,

Anthony Liguori


Example:

->  { "execute": "hmp_passthrough", "arguments": { "command-line": "print /i 
10+25" } }
<- { "return": "35\r\n" }

Thanks.

Re: [Qemu-devel] [PATCH] block: fix the use of protocols in backing files

2010-10-27 Thread malc

On Wed, 27 Oct 2010, Anthony Liguori wrote:

> Signed-off-by: Anthony Liguori 
> 
> diff --git a/block.c b/block.c
> index 1a965b2..00b6f21 100644
> --- a/block.c
> +++ b/block.c
> @@ -603,10 +603,16 @@ int bdrv_open(BlockDriverState *bs, const char 
> *filename, int flags,
>  BlockDriver *back_drv = NULL;
>  
>  bs->backing_hd = bdrv_new("");
> -path_combine(backing_filename, sizeof(backing_filename),
> - filename, bs->backing_file);
> -if (bs->backing_format[0] != '\0')
> -back_drv = bdrv_find_format(bs->backing_format);
> +back_drv = bdrv_find_protocol(bs->backing_file);
> +if (!back_drv) {
> +path_combine(backing_filename, sizeof(backing_filename),
> + filename, bs->backing_file);
> +if (bs->backing_format[0] != '\0')
> +back_drv = bdrv_find_format(bs->backing_format);

Sigh..

> +} else {
> +pstrcpy(backing_filename, sizeof(backing_filename),
> +bs->backing_file);
> +}
>  
>  /* backing files always opened read-only */
>  back_flags =
> 

-- 
mailto:av1...@comtv.ru

Re: [Qemu-devel] [PATCH] block: fix the use of protocols in backing files


On 10/27/2010 02:22 PM, malc wrote:

On Wed, 27 Oct 2010, Anthony Liguori wrote:

   

Signed-off-by: Anthony Liguori

diff --git a/block.c b/block.c
index 1a965b2..00b6f21 100644
--- a/block.c
+++ b/block.c
@@ -603,10 +603,16 @@ int bdrv_open(BlockDriverState *bs, const char *filename, 
int flags,
  BlockDriver *back_drv = NULL;

  bs->backing_hd = bdrv_new("");
-path_combine(backing_filename, sizeof(backing_filename),
- filename, bs->backing_file);
-if (bs->backing_format[0] != '\0')
-back_drv = bdrv_find_format(bs->backing_format);
+back_drv = bdrv_find_protocol(bs->backing_file);
+if (!back_drv) {
+path_combine(backing_filename, sizeof(backing_filename),
+ filename, bs->backing_file);
+if (bs->backing_format[0] != '\0')
+back_drv = bdrv_find_format(bs->backing_format);
 

Sigh..
   


Always good to see such clear and constructive comments...

I'll respin.

Regards,

Anthony Liguori

   

+} else {
+pstrcpy(backing_filename, sizeof(backing_filename),
+bs->backing_file);
+}

  /* backing files always opened read-only */
  back_flags =

[Qemu-devel] AIX emulated on x86 host

2010-10-27 Thread glen . c . bodie

I have an old AIX machine (IBM RS/6000 running AIX v5.x) and it's about to 
fall apart. I would like to migrate that machine's functions onto one of 
my VMware hosts, all of which are DELL 2950 servers (x86 architecture). I 
know VMware only runs x86 architecture guests. So I am planning a Windows 
2003 Server guest, running QEMU as really the only thing it is doing and 
inside QEMU I want to run that AIX machine's functions.

Fundamental question - think that will work?

If the answer is YES then I need to worry about creating the PPC disk 
image, loading AIX onto it, loading my AIX applications and migrating the 
data from the old hardware to the new emulated machine. Think I'm nuts? 
Got a better alternative?

~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
Thought for the day: The universe may be as big as they say, but it 
wouldn't be missed if it didn't exist. (a Gruk by Piet Hein)
Regards - Glen C. Bodie
Process Control Systems & Plant Computing Advisor,
Engineering Services Canada, Imperial Oil Limited
90 Wynford Dr, Toronto, Ontario, Canada M3C 1K5
( Voice: (416) 441-7702
: E-mail: glen.c.bo...@esso.caCall me on NetMeeting
P please consider the environment before printing this email 

<>

smime.p7s
Description: S/MIME Cryptographic Signature

[Qemu-devel] [PATCH] block: fix the use of protocols in backing files (v2)

Signed-off-by: Anthony Liguori 
---
v1 -> v2
 - Fix up CODING_STYLE of modified code

diff --git a/block.c b/block.c
index 1a965b2..029017e 100644
--- a/block.c
+++ b/block.c
@@ -603,10 +603,17 @@ int bdrv_open(BlockDriverState *bs, const char *filename, 
int flags,
 BlockDriver *back_drv = NULL;
 
 bs->backing_hd = bdrv_new("");
-path_combine(backing_filename, sizeof(backing_filename),
- filename, bs->backing_file);
-if (bs->backing_format[0] != '\0')
-back_drv = bdrv_find_format(bs->backing_format);
+back_drv = bdrv_find_protocol(bs->backing_file);
+if (!back_drv) {
+path_combine(backing_filename, sizeof(backing_filename),
+ filename, bs->backing_file);
+if (bs->backing_format[0] != '\0') {
+back_drv = bdrv_find_format(bs->backing_format);
+}
+} else {
+pstrcpy(backing_filename, sizeof(backing_filename),
+bs->backing_file);
+}
 
 /* backing files always opened read-only */
 back_flags =
-- 
1.7.0.4

Re: [Qemu-devel] About QEMU debugging console

On Wed, Oct 27, 2010 at 1:10 AM, Zhiyuan Shao  wrote:
> On Tue, 2010-10-26 at 18:59 +, Blue Swirl wrote:
>> On Tue, Oct 26, 2010 at 12:22 PM, Zhiyuan Shao  wrote:
>> > Hi team,
>> >
>> > I am a Qemu User, and using Qemu 0.13.0 to debugging the linux kernel
>> > code (Qemu+GDB).
>> >
>> > During the usage, I found the Qemu debugging console (i.e., entered by
>> > pressing Ctl+Alt+2 in Qemu SDL window or by passing "-monitor stdio" to
>> > Qemu in the command line) is rather difficult to use. It can not show
>> > some important information, e.g., on i386 platform, which is my major
>> > interest, it can not show IDT, GDT information. Regarding the page
>> > mapping information, "info tlb" actually do a really bad job.
>>
>> How is that bad?
>>
> I booted a Linux OS (i386 with PAE support), and has following
> virtual-to-physical mappings:
> [0xff00-,0xffbf-] -> [0x-, 0x00bf-]
> [0x-,0x00ff-] -> [0x-, 0x00ff-]
>
> while now, with "info mem" command of Qemu debugging console, the output
> is like:
> (qemu) info mem
> -0040 0040 -r-
> 00c0-00c08000 8000 -rw
> 00c08000-00c09000 1000 ur-
> 00c09000-00c0a000 1000 urw
> 00c0e000-00c0f000 1000 urw
> 00c1-00c11000 1000 -r-
> 00c11000-00c12000 1000 ur-
> 00c12000-00c13000 1000 -r-
> 00c14000-00c16000 2000 -r-
> 00c1b000-00c1e000 3000 -rw
> 00c2-00c4 0002 -rw
> 00c4-00c41000 1000 -r-
> 00c41000-00c42000 1000 ur-
> 00c42000-00c43000 1000 -rw
> 00c44000-00c6 0001c000 -rw
> 00c67000-00c7 9000 -rw
> 00c71000-00c74000 3000 ur-
> 00c75000-00c76000 1000 urw
> 00c77000-00c78000 1000 ur-
> 00c78000-00c79000 1000 -rw
> 00c7a000-00d0 00086000 -rw
> 00d18000-00d19000 1000 urw
> 00d19000-00d1a000 1000 -rw
> 00d1d000-00d1e000 1000 -r-
> 00d22000-00d23000 1000 -r-
> 00d2a000-00d2b000 1000 -rw
> 00df-00df1000 1000 -r-
> 00df1000-00df2000 1000 urw
> 00df4000-00df5000 1000 -r-
> 00df5000-00df6000 1000 urw
> 00df7000-00df8000 1000 urw
> 0100-0140 0040 -rw
> 0140-0180 0040 -r-
> 0180-01c0 0040 urw
> 01c0-0200 0040 -rw
> 04c0-0500 0040 ur-
> 05c0-0600 0040 -rw
> 0bc0-0c00 0040 -r-
> 0c80-0cc0 0040 urw
> 0d80-0e00 0080 ur-
> 0e40-0e80 0040 ur-
> 1040-1080 0040 -rw
> 1200-12001000 1000 -rw
> 12002000-12003000 1000 -rw
> 12004000-12005000 1000 -rw
> 12006000-12007000 1000 -rw
> 12008000-12009000 1000 -rw
> 1200a000-1200b000 1000 -rw
> 1200c000-1200d000 1000 -rw
> 1200e000-1200f000 1000 -rw
> 13bf-13bf1000 1000 -rw
> 13bf2000-13bf3000 1000 -rw
> 13bf4000-13bf5000 1000 -rw
> 13bf6000-13bf7000 1000 -rw
> 13bf8000-13bf9000 1000 -rw
> 13bfa000-13bfb000 1000 -rw
>
> Donot know what the "active virtual memory mappings" means for "info
> mem" command, but the results displayed is not very likely being
> correct.
>
> While with "info tlb" command:
>
> (qemu) info tlb
> : 15c0 -PDA-T--
> 00c0: f000f000 G-D-C--W
> 00c01000: f000f000 G-D-C--W
> 00c02000: f000e000 --DW
> 00c03000: f000f000 G-D-C--W
> 00c04000: f000f000 G-D-C--W
> 00c05000: f000f000 G-D-C--W
> 00c06000: f000f000 G-D-C--W
> 00c07000: f000f000 G-D-C--W
> 00c08000: f000f000 ---A--U-
> 00c09000: f000e000 G-UW
> 00c0e000: f000e000 G-D-C-UW
> 00c1: c0008000 G--ACT--
> 00c11000: f000f000 --D--TU-
> 00c12000: f000f000 --D-
> 00c14000: f000e000 G--ACT--
> 00c15000: f000f000 --D-CT--
> 00c1b000: f000f000 G-D-C--W
> 00c1c000: f000f000 G-D-C--W
> 00c1d000: f000f000 G-D-C--W
> 00c2: f000f000 G-D-C--W
> 00c21000: f000f000 G-D-C--W
> 00c22000: f000f000 G-D-C--W
> 00c23000: f000f000 G-D-C--W
> 00c24000: f000f000 G-D-C--W
> 00c25000: f000f000 G-D-C--W
> 00c26000: f000f000 G-D-C--W
> 00c27000: f000f000 G-D-C--W
> 00c28000: f000f000 G-D-C--W
> 00c29000: f000f000 G-D-C--W
> 00c2a000: f000f000 G-D-C--W
> 00c2b000: f000f000 G-D-C--W
> 00c2c000: f000f000 G-D-C--W
> 00c2d000: f000f000 G-D-C--W
> 00c2e000: f000f000 G-D-C--W
> 00c2f000: f000f000 G-D-C--W
> 00c3: f000f000 G-D-C--W
> 00c31000: f000f000 G-D-C--W
> 00c32000: f000f000 G-D-C--W
> 00c33000: f000f000 G-D-C--W
> 00c34000: f000f000 G-D-C--W
> 00c35000: f000f000 G-D-C--W
> 00c36000: f000f000 G-D-C--W
> 00c37000: f000f000 G-D-C--W
> 00c38000: f000f000 G-D-C--W
> 00c39000: f000f000 G-D-C--W
> 00c3a000: f000f000 G-D-C--W
> 00c3b000: f000f000 G-D-C--W
> 00c3c000: f000f000 G-D-C--W
> 00c3d000: f000f000 G-D-C--W
> 00c3e000: f000f000 G-D-C--W
> 00c3f000: f000f000 G-D-C--W
> 00c4: f000e000 --D-CT--
> 00c41000: 9fc0 ---ACTU-
> 00c42000: f000f000 G-D-C--W
> 00c44000: f000f000 G-D-C--W
> 00c45000: f000f000 G-D-C--W
> 00c46000: f000f000 G-D-C--W
> 00c47000: f000f000 G-D-C--W
> 00c48000: f000f000 G-D-C--W
> 00c49000: f000f000 G-D-C--W
> 00c4a000: f000f000 G-D-C--W
> 00c4b000

Re: [Qemu-devel] guest physical address equal host virtual address ?

On Wed, Oct 27, 2010 at 6:14 AM,   wrote:
>
>>As I remember it, it's on the lines of:
>
>>tlb_entry = env->tlb_table[mem_index][hash(guest_virtual_address)];
>>if (tlb_entry. == guest_virtual_address) {
>>   host_virtual_address = tlb_entry.addend
>>} else {
>>  call the slow path through __ld routines
>>}
>
> No,  At qemu-0.10.0
>         host_virtual_addres = guest virtual address + tlb_entry.addend
> not as :
>          host_virtual_address = tlb_entry.addend
>
> Can you explain more?

This is the TLB calculation when taking out checks, for the RAM address case:
index = (addr >> TARGET_PAGE_BITS) & (CPU_TLB_SIZE - 1);
tlb_addr = env->tlb_table[mmu_idx][index].ADDR_READ;
addend = env->tlb_table[mmu_idx][index].addend;
res = glue(glue(ld, USUFFIX), _raw)((uint8_t *)(long)(addr+addend));

TLB addend is calculated in exec.c, tlb_set_page():
addend = (unsigned long)qemu_get_ram_ptr(pd & TARGET_PAGE_MASK);
te->addend = addend - vaddr;

So taking into account both, the virtual address is subtracted,
leaving only host pointer to RAM area.

[Qemu-devel] AIX emulated on x86 host

2010-10-27 Thread glen . c . bodie

Sorry - first message had non-plain text by mistake. Trying again ...

I have an old AIX machine (IBM RS/6000 running AIX v5.x) and it's about to 
fall apart. I would like to migrate that machine's functions onto one of 
my VMware hosts, all of which are DELL 2950 servers (x86 architecture). I 
know VMware only runs x86 architecture guests. So I am planning a Windows 
2003 Server guest, running QEMU as really the only thing it is doing and 
inside QEMU I want to run that AIX machine's functions.

Fundamental question - think that will work?

If the answer is YES then I need to worry about creating the PPC disk 
image, loading AIX onto it, loading my AIX applications and migrating the 
data from the old hardware to the new emulated machine. Think I'm nuts? 
Got a better alternative?

Regards - Glen

Re: [Qemu-devel] [PATCH 1/2] Type-safe ioport callbacks

On Wed, Oct 27, 2010 at 9:26 AM, Avi Kivity  wrote:
>  On 10/26/2010 08:33 PM, Blue Swirl wrote:
>>
>> >
>> >  Why two types?  I think some devices use PIO on a PC and MMIO on other
>> >  architectures.  Sharing the type would allow sharing code.
>>
>> Then there are the functions provided by rwhandler.c. I think that
>> interface makes even more sense compared to 8/16/32 (and 64?) bit
>> handlers in many cases.
>
> On the other hand, that makes the transition harder.
>
> Perhaps we can have a type with {read,write}(addr, width), and another built
> on top that provides the traditional {read,write}[bwl](addr) to ease the
> transition.

That should work.

Re: [Qemu-devel] Which qemu ports actually work?

On Wed, Oct 27, 2010 at 8:39 AM, Torbjorn Granlund  wrote:
>  > "install64", which comes a bit longer.  It fails in a new way: it
>  > ignores keyboard input, This happens after the kernel has booted, and
>  > the installer has started.
>
>  Yes, ignoring keyboard input sounds right. The issue here is that
>  we're basically emulating a PPC32 machine, but plug in a PPC64
>  CPU. This works mostly, but for ADB it breaks, as the guest kernel
>  doesn't have support for our ADB controller. Unfortunately, keyboard
>  and mouse are attached using ADB.
>
>  One way to get around this is to use -usb -usbdevice keyboard.
>
> That makes no difference.  I suppose it is still using the adb keyboard.

I got to livecd prompt, with working keyboard using the following command line:
qemu-system-ppc64 -boot d -cdrom install-powerpc-minimal-2008.0.iso
-cpu 970fx -M mac99 -usb -usbdevice keyboard

At boot prompt, I just hit enter to select a G5 kernel.

[Qemu-devel] Chandra has invited you to join MySpace

2010-10-27 Thread Myspace

Title: Chandra has invited you to join MySpace





















 
 


 

Hello. Chandra has invited you to join MySpace.After accepting, you will be automatically connected with Chandra and have access to premium content, new friends and a huge music and video library. See you on MySpace!  




Accept now








 
 




















 

At MySpace we care about your privacy. Click here to unsubscribe from future emails like this.You can also contact us with any questions or concerns regarding your privacy at: http://faq.myspace.com/app/home/or write to us at: myspace.com, 8391 Beverly Blvd, #349, Los Angeles, CA 90048. © MySpace Inc. All Rights Reserved.

Re: [Qemu-devel] Which qemu ports actually work?

Blue Swirl  writes:

  On Wed, Oct 27, 2010 at 8:39 AM, Torbjorn Granlund  wrote:
  >  > "install64", which comes a bit longer.  It fails in a new way: it
  >  > ignores keyboard input, This happens after the kernel has booted, and
  >  > the installer has started.
  >
  >  Yes, ignoring keyboard input sounds right. The issue here is that
  >  we're basically emulating a PPC32 machine, but plug in a PPC64
  >  CPU. This works mostly, but for ADB it breaks, as the guest kernel
  >  doesn't have support for our ADB controller. Unfortunately, keyboard
  >  and mouse are attached using ADB.
  >
  >  One way to get around this is to use -usb -usbdevice keyboard.
  >
  > That makes no difference.  I suppose it is still using the adb keyboard.

  I got to livecd prompt, with working keyboard using the following command 
line:
  qemu-system-ppc64 -boot d -cdrom install-powerpc-minimal-2008.0.iso
  -cpu 970fx -M mac99 -usb -usbdevice keyboard

  At boot prompt, I just hit enter to select a G5 kernel.

Wow, it indeed works!  Later Gentoo releases fail in a way similar to
Debian (an early hang).  Did you fight your way through the contorted
Gentoo install in order to see if you get a bootable system?  (I'll try
that when I have time.)

The default nic cannot be used, -net nic,model=e1000 is needed.

I started a page that intends to save others from the trouble I have.
It is at .  I'll try and collect
enough info for getting started, or save others from wasting time on
things that do not work.

[qemu-de...@nongnu.org might block this message.  It lastly tried to
pseudo-mail back using an incorrect address, then reject my messages
with a 550 code.  Some anti-spam mechanism gone bad.]

-- 
Torbjörn

[Qemu-devel] Re: bonito: PCI_STATUS questions

2010-10-27 Thread chen huacai

Because the code in PMON and Linux kernel use these bits to verify r/w
operations. If one of them is 1 after r/w, PMON and Linux will
consider r/w has failed.
I guess that software will not set them to 1, because it is set by
hardware when operation fails.

On Thu, Oct 28, 2010 at 12:12 AM, Michael S. Tsirkin  wrote:
> I see code in bonito.c that clears bits:
> PCI_STATUS_REC_MASTER_ABORT | PCI_STATUS_REC_TARGET_ABORT
> on each read and write.
>
> However
> 1. I don't see anything in code that would set these bits
> 2. The PCI spec says this about the status register:
>
>        Reads to this register behave normally. Writes are slightly different 
> in
>        that bits can be reset, but not set. A one bit is reset (if it is not
>        read-only) whenever the register is written, and the write data in the
>        corresponding bit location is a 1. For instance, to clear bit 14 and 
> not
>        affect any other bits, write the value 0100___b to the
>        register.
>
> while the code in bonito.c resets the bits to 0 on each write.
>
> Comments?
>
> --
> MST
>



-- 
Huacai Chen

[Qemu-devel] Re: [PATCH] msi: minor cleanups

Looks good.

On Wed, Oct 27, 2010 at 04:30:03PM +0200, Michael S. Tsirkin wrote:
> Comment fixup (tell what it does not what it does not do),
> typo fix, whitespace fix.
> 
> Signed-off-by: Michael S. Tsirkin 
> ---
>  hw/msi.c |7 +++
>  1 files changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/msi.c b/hw/msi.c
> index 016e7a4..f03f519 100644
> --- a/hw/msi.c
> +++ b/hw/msi.c
> @@ -155,9 +155,8 @@ int msi_init(struct PCIDevice *dev, uint8_t offset,
>  pci_set_word(dev->wmask + msi_data_off(dev, msi64bit), 0x);
>  
>  if (msi_per_vector_mask) {
> +/* Make mask bits 0 to nr_vectors - 1 writeable. */
>  pci_set_long(dev->wmask + msi_mask_off(dev, msi64bit),
> - /* (1U << nr_vectors) - 1 is undefined
> -when nr_vectors = 32 */
>   0x >> (PCI_MSI_VECTORS_MAX - nr_vectors));
>  }
>  return config_offset;
> @@ -225,7 +224,7 @@ void msi_notify(PCIDevice *dev, unsigned int vector)
>  return;
>  }
>  
> -if (msi64bit){
> +if (msi64bit) {
>  address = pci_get_quad(dev->config + msi_address_lo_off(dev));
>  } else {
>  address = pci_get_long(dev->config + msi_address_lo_off(dev));
> @@ -269,7 +268,7 @@ void msi_write_config(PCIDevice *dev, uint32_t addr, 
> uint32_t val, int len)
> flags,
> pci_get_long(dev->config + msi_address_lo_off(dev)));
>  if (msi64bit) {
> -fprintf(stderr, " addrss-hi: 0x%"PRIx32,
> +fprintf(stderr, " address-hi: 0x%"PRIx32,
>  pci_get_long(dev->config + msi_address_hi_off(dev)));
>  }
>  fprintf(stderr, " data: 0x%"PRIx16,
> -- 
> 1.7.3.2.91.g446ac
> 

-- 
yamahata

[Qemu-devel] Re: [PATCH] pci: improve w1c mask handling

On Wed, Oct 27, 2010 at 04:05:58PM +0200, Michael S. Tsirkin wrote:
> - save/restore must not check w1c bits
>   since they are in fact guest controlled
> - clear w1c bits on reset
> 
> Note: for express there are different kinds of
> reset, some leave part of config space alone.
> We will likely need a sticky bit mask to implement this.
> 
> Signed-off-by: Michael S. Tsirkin 
> ---
> 
> Isaku, does the below make sense?
> 
>  hw/pci.c |6 --
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/pci.c b/hw/pci.c
> index e50de14..1a14a0e 100644
> --- a/hw/pci.c
> +++ b/hw/pci.c
> @@ -141,7 +141,8 @@ static void pci_device_reset(PCIDevice *dev)
>  pci_update_irq_status(dev);
>  /* Clear all writeable bits */
>  pci_word_test_and_clear_mask(dev->config + PCI_COMMAND,
> - pci_get_word(dev->wmask + PCI_COMMAND));
> + pci_get_word(dev->wmask + PCI_COMMAND) |
> + pci_get_word(dev->w1cmask + PCI_COMMAND));
>  dev->config[PCI_CACHE_LINE_SIZE] = 0x0;
>  dev->config[PCI_INTERRUPT_LINE] = 0x0;
>  for (r = 0; r < PCI_NUM_REGIONS; ++r) {
> @@ -293,7 +294,8 @@ static int get_pci_config_device(QEMUFile *f, void *pv, 
> size_t size)
>  
>  qemu_get_buffer(f, config, size);
>  for (i = 0; i < size; ++i) {
> -if ((config[i] ^ s->config[i]) & s->cmask[i] & ~s->wmask[i]) {
> +if ((config[i] ^ s->config[i]) &
> +s->cmask[i] & ~s->wmask[i] & ~s->w1cmask) {

[i] is needed for w1cmask.
~s->w1cmask[i]
   ^^^



>  qemu_free(config);
>  return -EINVAL;
>  }
> -- 
> 1.7.3.2.91.g446ac
> 

-- 
yamahata

Re: [Qemu-devel] About QEMU debugging console

2010-10-27 Thread Zhiyuan Shao

On Wed, 2010-10-27 at 20:07 +, Blue Swirl wrote:
> On Wed, Oct 27, 2010 at 1:10 AM, Zhiyuan Shao  wrote:
> > On Tue, 2010-10-26 at 18:59 +, Blue Swirl wrote:
> >> On Tue, Oct 26, 2010 at 12:22 PM, Zhiyuan Shao  wrote:
> >> > Hi team,
> >> >
> >> > I am a Qemu User, and using Qemu 0.13.0 to debugging the linux kernel
> >> > code (Qemu+GDB).
> >> >
> >> > During the usage, I found the Qemu debugging console (i.e., entered by
> >> > pressing Ctl+Alt+2 in Qemu SDL window or by passing "-monitor stdio" to
> >> > Qemu in the command line) is rather difficult to use. It can not show
> >> > some important information, e.g., on i386 platform, which is my major
> >> > interest, it can not show IDT, GDT information. Regarding the page
> >> > mapping information, "info tlb" actually do a really bad job.
> >>
> >> How is that bad?
> >>
> > I booted a Linux OS (i386 with PAE support), and has following
> > virtual-to-physical mappings:
> > [0xff00-,0xffbf-] -> [0x-, 0x00bf-]
> > [0x-,0x00ff-] -> [0x-, 0x00ff-]
> >
> > while now, with "info mem" command of Qemu debugging console, the output
> > is like:
> > (qemu) info mem
> > -0040 0040 -r-
> > 00c0-00c08000 8000 -rw
> > 00c08000-00c09000 1000 ur-
> > 00c09000-00c0a000 1000 urw
> > 00c0e000-00c0f000 1000 urw
> > 00c1-00c11000 1000 -r-
> > 00c11000-00c12000 1000 ur-
> > 00c12000-00c13000 1000 -r-
> > 00c14000-00c16000 2000 -r-
> > 00c1b000-00c1e000 3000 -rw
> > 00c2-00c4 0002 -rw
> > 00c4-00c41000 1000 -r-
> > 00c41000-00c42000 1000 ur-
> > 00c42000-00c43000 1000 -rw
> > 00c44000-00c6 0001c000 -rw
> > 00c67000-00c7 9000 -rw
> > 00c71000-00c74000 3000 ur-
> > 00c75000-00c76000 1000 urw
> > 00c77000-00c78000 1000 ur-
> > 00c78000-00c79000 1000 -rw
> > 00c7a000-00d0 00086000 -rw
> > 00d18000-00d19000 1000 urw
> > 00d19000-00d1a000 1000 -rw
> > 00d1d000-00d1e000 1000 -r-
> > 00d22000-00d23000 1000 -r-
> > 00d2a000-00d2b000 1000 -rw
> > 00df-00df1000 1000 -r-
> > 00df1000-00df2000 1000 urw
> > 00df4000-00df5000 1000 -r-
> > 00df5000-00df6000 1000 urw
> > 00df7000-00df8000 1000 urw
> > 0100-0140 0040 -rw
> > 0140-0180 0040 -r-
> > 0180-01c0 0040 urw
> > 01c0-0200 0040 -rw
> > 04c0-0500 0040 ur-
> > 05c0-0600 0040 -rw
> > 0bc0-0c00 0040 -r-
> > 0c80-0cc0 0040 urw
> > 0d80-0e00 0080 ur-
> > 0e40-0e80 0040 ur-
> > 1040-1080 0040 -rw
> > 1200-12001000 1000 -rw
> > 12002000-12003000 1000 -rw
> > 12004000-12005000 1000 -rw
> > 12006000-12007000 1000 -rw
> > 12008000-12009000 1000 -rw
> > 1200a000-1200b000 1000 -rw
> > 1200c000-1200d000 1000 -rw
> > 1200e000-1200f000 1000 -rw
> > 13bf-13bf1000 1000 -rw
> > 13bf2000-13bf3000 1000 -rw
> > 13bf4000-13bf5000 1000 -rw
> > 13bf6000-13bf7000 1000 -rw
> > 13bf8000-13bf9000 1000 -rw
> > 13bfa000-13bfb000 1000 -rw
> >
> > Donot know what the "active virtual memory mappings" means for "info
> > mem" command, but the results displayed is not very likely being
> > correct.
> >
> > While with "info tlb" command:
> >
> > (qemu) info tlb
> > : 15c0 -PDA-T--
> > 00c0: f000f000 G-D-C--W
> > 00c01000: f000f000 G-D-C--W
> > 00c02000: f000e000 --DW
> > 00c03000: f000f000 G-D-C--W
> > 00c04000: f000f000 G-D-C--W
> > 00c05000: f000f000 G-D-C--W
> > 00c06000: f000f000 G-D-C--W
> > 00c07000: f000f000 G-D-C--W
> > 00c08000: f000f000 ---A--U-
> > 00c09000: f000e000 G-UW
> > 00c0e000: f000e000 G-D-C-UW
> > 00c1: c0008000 G--ACT--
> > 00c11000: f000f000 --D--TU-
> > 00c12000: f000f000 --D-
> > 00c14000: f000e000 G--ACT--
> > 00c15000: f000f000 --D-CT--
> > 00c1b000: f000f000 G-D-C--W
> > 00c1c000: f000f000 G-D-C--W
> > 00c1d000: f000f000 G-D-C--W
> > 00c2: f000f000 G-D-C--W
> > 00c21000: f000f000 G-D-C--W
> > 00c22000: f000f000 G-D-C--W
> > 00c23000: f000f000 G-D-C--W
> > 00c24000: f000f000 G-D-C--W
> > 00c25000: f000f000 G-D-C--W
> > 00c26000: f000f000 G-D-C--W
> > 00c27000: f000f000 G-D-C--W
> > 00c28000: f000f000 G-D-C--W
> > 00c29000: f000f000 G-D-C--W
> > 00c2a000: f000f000 G-D-C--W
> > 00c2b000: f000f000 G-D-C--W
> > 00c2c000: f000f000 G-D-C--W
> > 00c2d000: f000f000 G-D-C--W
> > 00c2e000: f000f000 G-D-C--W
> > 00c2f000: f000f000 G-D-C--W
> > 00c3: f000f000 G-D-C--W
> > 00c31000: f000f000 G-D-C--W
> > 00c32000: f000f000 G-D-C--W
> > 00c33000: f000f000 G-D-C--W
> > 00c34000: f000f000 G-D-C--W
> > 00c35000: f000f000 G-D-C--W
> > 00c36000: f000f000 G-D-C--W
> > 00c37000: f000f000 G-D-C--W
> > 00c38000: f000f000 G-D-C--W
> > 00c39000: f000f000 G-D-C--W
> > 00c3a000: f000f000 G-D-C--W
> > 00c3b000: f000f000 G-D-C--W
> > 00c3c000: f000f000 G-D-C--W
> > 00c3d000: f000f000 G-D-C--W
> > 00c3e000: f000f000 G-D-C--W
> > 00c

[Qemu-devel] Re: [PATCH 0/6] pcie: fixes for pci branch

On Wed, Oct 27, 2010 at 06:40:48PM +0200, Michael S. Tsirkin wrote:
> On Wed, Oct 27, 2010 at 07:21:15PM +0900, Isaku Yamahata wrote:
> > This patch series fixes isseus which introduced by
> > 5704608988972359473ce609f9e4884808115b58
> > cd870502e228f8f028f93fb585ae3b208fcb46c7
> > 4b78560503a802eae3663ace9f9cf080319e7265
> 
> OK, I applied this, except I basically backed out range check changes.
> Pls take a look at the branch, and test if possible -
> if OK with you I think we can merge this part.

I took a look at it. It looks good.
-- 
yamahata

[Qemu-devel] Re: bonito: PCI_STATUS questions

On Thu, Oct 28, 2010 at 08:57:01AM +0800, chen huacai wrote:
> Because the code in PMON and Linux kernel use these bits to verify r/w
> operations. If one of them is 1 after r/w, PMON and Linux will
> consider r/w has failed.

Where's that code in Linux?

> I guess that software will not set them to 1, because it is set by
> hardware when operation fails.

So I guess just making these write 1 to clear according to spec will work?

> On Thu, Oct 28, 2010 at 12:12 AM, Michael S. Tsirkin  wrote:
> > I see code in bonito.c that clears bits:
> > PCI_STATUS_REC_MASTER_ABORT | PCI_STATUS_REC_TARGET_ABORT
> > on each read and write.
> >
> > However
> > 1. I don't see anything in code that would set these bits
> > 2. The PCI spec says this about the status register:
> >
> >        Reads to this register behave normally. Writes are slightly 
> > different in
> >        that bits can be reset, but not set. A one bit is reset (if it is not
> >        read-only) whenever the register is written, and the write data in 
> > the
> >        corresponding bit location is a 1. For instance, to clear bit 14 and 
> > not
> >        affect any other bits, write the value 0100___b to the
> >        register.
> >
> > while the code in bonito.c resets the bits to 0 on each write.
> >
> > Comments?
> >
> > --
> > MST
> >
> 
> 
> 
> -- 
> Huacai Chen

[Qemu-devel] Re: [PATCH] pci: improve w1c mask handling

On Thu, Oct 28, 2010 at 11:02:48AM +0900, Isaku Yamahata wrote:
> On Wed, Oct 27, 2010 at 04:05:58PM +0200, Michael S. Tsirkin wrote:
> > - save/restore must not check w1c bits
> >   since they are in fact guest controlled
> > - clear w1c bits on reset
> > 
> > Note: for express there are different kinds of
> > reset, some leave part of config space alone.
> > We will likely need a sticky bit mask to implement this.
> > 
> > Signed-off-by: Michael S. Tsirkin 
> > ---
> > 
> > Isaku, does the below make sense?
> > 
> >  hw/pci.c |6 --
> >  1 files changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/hw/pci.c b/hw/pci.c
> > index e50de14..1a14a0e 100644
> > --- a/hw/pci.c
> > +++ b/hw/pci.c
> > @@ -141,7 +141,8 @@ static void pci_device_reset(PCIDevice *dev)
> >  pci_update_irq_status(dev);
> >  /* Clear all writeable bits */
> >  pci_word_test_and_clear_mask(dev->config + PCI_COMMAND,
> > - pci_get_word(dev->wmask + PCI_COMMAND));
> > + pci_get_word(dev->wmask + PCI_COMMAND) |
> > + pci_get_word(dev->w1cmask + PCI_COMMAND));
> >  dev->config[PCI_CACHE_LINE_SIZE] = 0x0;
> >  dev->config[PCI_INTERRUPT_LINE] = 0x0;
> >  for (r = 0; r < PCI_NUM_REGIONS; ++r) {
> > @@ -293,7 +294,8 @@ static int get_pci_config_device(QEMUFile *f, void *pv, 
> > size_t size)
> >  
> >  qemu_get_buffer(f, config, size);
> >  for (i = 0; i < size; ++i) {
> > -if ((config[i] ^ s->config[i]) & s->cmask[i] & ~s->wmask[i]) {
> > +if ((config[i] ^ s->config[i]) &
> > +s->cmask[i] & ~s->wmask[i] & ~s->w1cmask) {
> 
> [i] is needed for w1cmask.
> ~s->w1cmask[i]
>^^^

Yes, I sent out a borken patch but it's correct on my branch.

> 
> 
> >  qemu_free(config);
> >  return -EINVAL;
> >  }
> > -- 
> > 1.7.3.2.91.g446ac
> > 
> 
> -- 
> yamahata

[Qemu-devel] [PATCH v2 0/2] pciinit: fix overflow when bar allocation

Okay, now added comments to members and functions as requested.
No essential code change.

Changes v1 -> v2:
- add comment.

Patch description:
This patch set fixes PCI bar allocation when bar overflow occured.
I checked if pmm_alloc facility can be used, but it doesn't suit for
pci bar allocation. So I resulted in new API, pci_region which
encapsulates region allocation and overflow checks.
The first patch introduces pci_region, and the second patch fixes
the overflow case with pci_region.

Isaku Yamahata (2):
  pci: introduce pci_region to manage pci io/memory/prefmemory regions.
  pciinit: use pci_region functions.

 Makefile |3 +-
 src/pci_region.c |   77 ++
 src/pciinit.c|  122 ++---
 src/util.h   |   28 
 4 files changed, 167 insertions(+), 63 deletions(-)
 create mode 100644 src/pci_region.c

[Qemu-devel] [PATCH v2 2/2] pciinit: use pci_region functions.

This patch cleans up pci region allocation with pci_region.
Now it is aware of overflow.

Signed-off-by: Isaku Yamahata 
---
 src/pciinit.c |  122 -
 1 files changed, 60 insertions(+), 62 deletions(-)

diff --git a/src/pciinit.c b/src/pciinit.c
index 0346423..2a01aaa 100644
--- a/src/pciinit.c
+++ b/src/pciinit.c
@@ -17,9 +17,10 @@
 
 static void pci_bios_init_device_in_bus(int bus);
 
-static u32 pci_bios_io_addr;
-static u32 pci_bios_mem_addr;
-static u32 pci_bios_prefmem_addr;
+static struct pci_region pci_bios_io_region;
+static struct pci_region pci_bios_mem_region;
+static struct pci_region pci_bios_prefmem_region;
+
 /* host irqs corresponding to PCI irqs A-D */
 const u8 pci_irqs[4] = {
 10, 10, 11, 11
@@ -54,7 +55,7 @@ static void pci_set_io_region_addr(u16 bdf, int region_num, 
u32 addr)
  */
 static int pci_bios_allocate_region(u16 bdf, int region_num)
 {
-u32 *paddr;
+struct pci_region *r;
 u32 ofs = pci_bar(bdf, region_num);
 
 u32 old = pci_config_readl(bdf, ofs);
@@ -74,41 +75,34 @@ static int pci_bios_allocate_region(u16 bdf, int region_num)
 
 u32 size = (~(val & mask)) + 1;
 if (val != 0) {
+const char *type;
+const char *msg;
 if (val & PCI_BASE_ADDRESS_SPACE_IO) {
-paddr = &pci_bios_io_addr;
-if (ALIGN(*paddr, size) + size >= 64 * 1024) {
-dprintf(1,
-"io region of (bdf 0x%x bar %d) can't be mapped.\n",
-bdf, region_num);
-size = 0;
-}
+r = &pci_bios_io_region;
+type = "io";
+msg = "";
 } else if ((val & PCI_BASE_ADDRESS_MEM_PREFETCH) &&
- /* keep behaviour on bus = 0 */
- pci_bdf_to_bus(bdf) != 0 &&
- /* If pci_bios_prefmem_addr == 0, keep old behaviour */
- pci_bios_prefmem_addr != 0) {
-paddr = &pci_bios_prefmem_addr;
-if (ALIGN(*paddr, size) + size >= BUILD_PCIPREFMEM_END) {
-dprintf(1,
-"prefmem region of (bdf 0x%x bar %d) can't be mapped. "
-"decrease BUILD_PCIMEM_SIZE and recompile. size %x\n",
-bdf, region_num, BUILD_PCIPREFMEM_SIZE);
-size = 0;
-}
+   /* keep behaviour on bus = 0 */
+   pci_bdf_to_bus(bdf) != 0 &&
+   /* If pci_bios_prefmem_addr == 0, keep old behaviour */
+   pci_region_addr(&pci_bios_prefmem_region) != 0) {
+r = &pci_bios_prefmem_region;
+type = "prefmem";
+msg = "decrease BUILD_PCIMEM_SIZE and recompile. size %x";
 } else {
-paddr = &pci_bios_mem_addr;
-if (ALIGN(*paddr, size) + size >= BUILD_PCIMEM_END) {
-dprintf(1,
-"mem region of (bdf 0x%x bar %d) can't be mapped. "
-"increase BUILD_PCIMEM_SIZE and recompile. size %x\n",
-bdf, region_num, BUILD_PCIMEM_SIZE);
-size = 0;
-}
+r = &pci_bios_mem_region;
+type = "mem";
+msg = "increase BUILD_PCIMEM_SIZE and recompile.";
 }
-if (size > 0) {
-*paddr = ALIGN(*paddr, size);
-pci_set_io_region_addr(bdf, region_num, *paddr);
-*paddr += size;
+u32 addr = pci_region_alloc(r, size);
+if (addr > 0) {
+pci_set_io_region_addr(bdf, region_num, addr);
+} else {
+size = 0;
+dprintf(1,
+"%s region of (bdf 0x%x bar %d) can't be mapped. "
+"%s size %x\n",
+type, bdf, region_num, msg, pci_region_size(r));
 }
 }
 
@@ -163,33 +157,34 @@ static void pci_bios_init_device_bridge(u16 bdf, void 
*arg)
 pci_bios_allocate_region(bdf, 1);
 pci_bios_allocate_region(bdf, PCI_ROM_SLOT);
 
-u32 io_old = pci_bios_io_addr;
-u32 mem_old = pci_bios_mem_addr;
-u32 prefmem_old = pci_bios_prefmem_addr;
+u32 io_old = pci_region_addr(&pci_bios_io_region);
+u32 mem_old = pci_region_addr(&pci_bios_mem_region);
+u32 prefmem_old = pci_region_addr(&pci_bios_prefmem_region);
 
 /* IO BASE is assumed to be 16 bit */
-pci_bios_io_addr = ALIGN(pci_bios_io_addr, PCI_IO_ALIGN);
-pci_bios_mem_addr = ALIGN(pci_bios_mem_addr, PCI_MEMORY_ALIGN);
-pci_bios_prefmem_addr =
-ALIGN(pci_bios_prefmem_addr, PCI_PREF_MEMORY_ALIGN);
+if (pci_region_align(&pci_bios_io_region, PCI_IO_ALIGN) == 0) {
+pci_region_disable(&pci_bios_io_region);
+}
+if (pci_region_align(&pci_bios_mem_region, PCI_MEMORY_ALIGN) == 0) {
+pci_region_disable(&pci_bios_mem_region);
+}
+if (pci_region_align(&pci_bios_prefmem_region,
+ PCI_PREF_MEMORY_ALIGN) == 0) {
+

[Qemu-devel] [PATCH v2 1/2] pci: introduce pci_region to manage pci io/memory/prefmemory regions.

This patch adds helper functions to manage pci area.

Signed-off-by: Isaku Yamahata 

---
Changes v1 -> v2
- add comments
---
 Makefile |3 +-
 src/pci_region.c |   77 ++
 src/util.h   |   28 +++
 3 files changed, 107 insertions(+), 1 deletions(-)
 create mode 100644 src/pci_region.c

diff --git a/Makefile b/Makefile
index 9d412f1..1663a5d 100644
--- a/Makefile
+++ b/Makefile
@@ -19,7 +19,8 @@ SRCBOTH=misc.c pmm.c stacks.c output.c util.c block.c 
floppy.c ata.c mouse.c \
 SRC16=$(SRCBOTH) system.c disk.c font.c
 SRC32FLAT=$(SRCBOTH) post.c shadow.c memmap.c coreboot.c boot.c \
   acpi.c smm.c mptable.c smbios.c pciinit.c optionroms.c mtrr.c \
-  lzmadecode.c bootsplash.c jpeg.c usb-hub.c paravirt.c dev-i440fx.c
+  lzmadecode.c bootsplash.c jpeg.c usb-hub.c paravirt.c dev-i440fx.c \
+  pci_region.c
 SRC32SEG=util.c output.c pci.c pcibios.c apm.c stacks.c
 
 cc-option = $(shell if test -z "`$(1) $(2) -S -o /dev/null -xc \
diff --git a/src/pci_region.c b/src/pci_region.c
new file mode 100644
index 000..c8656cb
--- /dev/null
+++ b/src/pci_region.c
@@ -0,0 +1,77 @@
+// helper functions to manage pci io/memory/prefetch memory region
+//
+// Copyright (C) 2009 Isaku Yamahata 
+//
+// This file may be distributed under the terms of the GNU LGPLv3 license.
+//
+//
+
+#include "util.h"
+
+#define PCI_REGION_DISABLED (-1)
+
+void pci_region_init(struct pci_region *r, u32 start, u32 end)
+{
+r->start = start;
+r->end = end;
+
+r->cur_end = start;
+}
+
+// PCI_REGION_DISABLED represents that the region is in special state.
+// its value is chosen such that cur_end can't be PCI_REGION_DISABLED normally.
+u32 pci_region_disable(struct pci_region *r)
+{
+return r->cur_end = PCI_REGION_DISABLED;
+}
+
+static int pci_region_disabled(const struct pci_region *r)
+{
+return r->cur_end == PCI_REGION_DISABLED;
+}
+
+static u32 pci_region_alloc_align(struct pci_region *r, u32 size, u32 align)
+{
+if (pci_region_disabled(r)) {
+return 0;
+}
+
+u32 s = ALIGN(r->cur_end, align);
+if (s > r->end || s < r->cur_end) {
+return 0;
+}
+u32 e = s + size;
+if (e > r->end || e < s) {
+return 0;
+}
+r->cur_end = e;
+return s;
+}
+
+u32 pci_region_alloc(struct pci_region *r, u32 size)
+{
+return pci_region_alloc_align(r, size, size);
+}
+
+u32 pci_region_align(struct pci_region *r, u32 align)
+{
+return pci_region_alloc_align(r, 0, align);
+}
+
+void pci_region_revert(struct pci_region *r, u32 addr)
+{
+r->cur_end = addr;
+}
+
+u32 pci_region_addr(const struct pci_region *r)
+{
+if (pci_region_disabled(r)){
+return r->end;
+}
+return r->cur_end;
+}
+
+u32 pci_region_size(const struct pci_region *r)
+{
+return r->end - r->start;
+}
diff --git a/src/util.h b/src/util.h
index 5cc9f17..17eedd0 100644
--- a/src/util.h
+++ b/src/util.h
@@ -344,6 +344,34 @@ void qemu_prep_reset(void);
 void smm_save_and_copy(void);
 void smm_relocate_and_restore(void);
 
+// pci_region.c
+// region allocator. pci region allocates the requested region
+// sequentially with overflow check.
+struct pci_region {
+// The region is [start, region).
+u32 start;
+u32 end;
+
+// The next allocation is start from this.
+// i.e. [start, cur_end) is allocated.
+// Right after initialization cur_end == start.
+u32 cur_end;
+};
+// initialize the pci_region of [start, end)
+void pci_region_init(struct pci_region *r, u32 start, u32 end);
+// allocate the region of size
+u32 pci_region_alloc(struct pci_region *r, u32 size);
+// make the next allocation aligned to align
+u32 pci_region_align(struct pci_region *r, u32 align);
+// revert the allocation to addr.
+void pci_region_revert(struct pci_region *r, u32 addr);
+// make the allocation fail.
+u32 pci_region_disable(struct pci_region *r);
+// returns the current allocation point.
+u32 pci_region_addr(const struct pci_region *r);
+// returns the region size.
+u32 pci_region_size(const struct pci_region *r);
+
 // pciinit.c
 extern const u8 pci_irqs[4];
 void pci_bios_allocate_regions(u16 bdf, void *arg);
-- 
1.7.1.1

[Qemu-devel] Re: [PATCH v2 1/2] pci: introduce pci_region to manage pci io/memory/prefmemory regions.

On Thu, Oct 28, 2010 at 02:04:05PM +0900, Isaku Yamahata wrote:
> This patch adds helper functions to manage pci area.
> 
> Signed-off-by: Isaku Yamahata 
> 
> ---
> Changes v1 -> v2
> - add comments
> ---
>  Makefile |3 +-
>  src/pci_region.c |   77 
> ++
>  src/util.h   |   28 +++
>  3 files changed, 107 insertions(+), 1 deletions(-)
>  create mode 100644 src/pci_region.c
> 
> diff --git a/Makefile b/Makefile
> index 9d412f1..1663a5d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -19,7 +19,8 @@ SRCBOTH=misc.c pmm.c stacks.c output.c util.c block.c 
> floppy.c ata.c mouse.c \
>  SRC16=$(SRCBOTH) system.c disk.c font.c
>  SRC32FLAT=$(SRCBOTH) post.c shadow.c memmap.c coreboot.c boot.c \
>acpi.c smm.c mptable.c smbios.c pciinit.c optionroms.c mtrr.c \
> -  lzmadecode.c bootsplash.c jpeg.c usb-hub.c paravirt.c dev-i440fx.c
> +  lzmadecode.c bootsplash.c jpeg.c usb-hub.c paravirt.c dev-i440fx.c \
> +  pci_region.c
>  SRC32SEG=util.c output.c pci.c pcibios.c apm.c stacks.c
>  
>  cc-option = $(shell if test -z "`$(1) $(2) -S -o /dev/null -xc \
> diff --git a/src/pci_region.c b/src/pci_region.c
> new file mode 100644
> index 000..c8656cb
> --- /dev/null
> +++ b/src/pci_region.c
> @@ -0,0 +1,77 @@
> +// helper functions to manage pci io/memory/prefetch memory region
> +//
> +// Copyright (C) 2009 Isaku Yamahata 
> +//
> +// This file may be distributed under the terms of the GNU LGPLv3 license.
> +//
> +//
> +
> +#include "util.h"
> +
> +#define PCI_REGION_DISABLED (-1)
> +
> +void pci_region_init(struct pci_region *r, u32 start, u32 end)
> +{
> +r->start = start;
> +r->end = end;
> +
> +r->cur_end = start;
> +}
> +
> +// PCI_REGION_DISABLED represents that the region is in special state.
> +// its value is chosen such that cur_end can't be PCI_REGION_DISABLED 
> normally.
> +u32 pci_region_disable(struct pci_region *r)
> +{
> +return r->cur_end = PCI_REGION_DISABLED;
> +}
> +
> +static int pci_region_disabled(const struct pci_region *r)
> +{
> +return r->cur_end == PCI_REGION_DISABLED;
> +}
> +
> +static u32 pci_region_alloc_align(struct pci_region *r, u32 size, u32 align)
> +{
> +if (pci_region_disabled(r)) {
> +return 0;
> +}
> +
> +u32 s = ALIGN(r->cur_end, align);
> +if (s > r->end || s < r->cur_end) {
> +return 0;
> +}
> +u32 e = s + size;
> +if (e > r->end || e < s) {
> +return 0;
> +}
> +r->cur_end = e;
> +return s;
> +}
> +
> +u32 pci_region_alloc(struct pci_region *r, u32 size)
> +{
> +return pci_region_alloc_align(r, size, size);
> +}
> +
> +u32 pci_region_align(struct pci_region *r, u32 align)
> +{
> +return pci_region_alloc_align(r, 0, align);
> +}
> +
> +void pci_region_revert(struct pci_region *r, u32 addr)
> +{
> +r->cur_end = addr;
> +}
> +
> +u32 pci_region_addr(const struct pci_region *r)
> +{
> +if (pci_region_disabled(r)){
> +return r->end;
> +}
> +return r->cur_end;
> +}
> +
> +u32 pci_region_size(const struct pci_region *r)
> +{
> +return r->end - r->start;
> +}
> diff --git a/src/util.h b/src/util.h
> index 5cc9f17..17eedd0 100644
> --- a/src/util.h
> +++ b/src/util.h
> @@ -344,6 +344,34 @@ void qemu_prep_reset(void);
>  void smm_save_and_copy(void);
>  void smm_relocate_and_restore(void);
>  
> +// pci_region.c
> +// region allocator. pci region allocates the requested region
> +// sequentially with overflow check.
> +struct pci_region {
> +// The region is [start, region).

[start end)?

> +u32 start;
> +u32 end;
> +
> +// The next allocation is start from this.
> +// i.e. [start, cur_end) is allocated.
> +// Right after initialization cur_end == start.
> +u32 cur_end;

What is the value for a region at 0xf000 and size 0x1000?

Maybe first, last is better to detect this?

> +};
> +// initialize the pci_region of [start, end)
> +void pci_region_init(struct pci_region *r, u32 start, u32 end);
> +// allocate the region of size
> +u32 pci_region_alloc(struct pci_region *r, u32 size);
> +// make the next allocation aligned to align
> +u32 pci_region_align(struct pci_region *r, u32 align);
> +// revert the allocation to addr.
> +void pci_region_revert(struct pci_region *r, u32 addr);
> +// make the allocation fail.
> +u32 pci_region_disable(struct pci_region *r);
> +// returns the current allocation point.
> +u32 pci_region_addr(const struct pci_region *r);
> +// returns the region size.
> +u32 pci_region_size(const struct pci_region *r);
> +
>  // pciinit.c
>  extern const u8 pci_irqs[4];
>  void pci_bios_allocate_regions(u16 bdf, void *arg);
> -- 
> 1.7.1.1

[Qemu-devel] [PULL] virtio, vhost, migration, pci, net

OK this is try 2, with bad vhost patch dropped, but I also tacked on
pcie support and some other fixes.

The following changes since commit 758c309f0a5cb52441a1ee015566cf9cd96fa933:

  seabios: Update to 0.6.1 (2010-10-25 16:43:41 -0500)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git for_anthony

Blue Swirl (1):
  Introduce range.h

This one is identical to what we already have on master, it got cherry
picked to pci branch to avoid bisect issues.

Isaku Yamahata (28):
  pci: move out pci internal structures, PCIBus, PCIBridge, and 
pci_bus_info.
  pci/bridge: split out pci bridge code into pci_bridge.c from pci.c
  pci_bridge: rename PCIBridge::bus -> PCIBridge::sec_bus.
  pci_bridge: clean up: remove pci_{register, unregister}_secondary_bus()
  pci_bridge: introduce pci bridge library.
  pci: consolidate pci_add_capability_at_offset() into pci_add_capability().
  pci bridge: add helper function for ssvid capability.
  pci: call hotplug callback even when not hotplug case for later use.
  pci: make pci_parse_devfn() aware of func.
  pci_ids.h: add vendor id of Texas Intesruments
  pci: sorting out type confusion in pci_register_bar().
  pci: don't ignore invalid parameter for pci_register_bar().
  pci: improve signature of pci_register_bar().
  pci: implement RW1C register framework.
  msix: clear not only INTA, but all INTx when MSI-X is enabled.
  pci: make pci_del_capability() update for w1cmask
  pci: introduce helper functions to test-and-{clear, set} mask in 
configuration space
  pci: introduce helper function to handle msi-x and msi.
  pci: use pci_word_test_and_clear_mask() in pci_device_reset()
  msi: implements msi
  pcie: add pcie constants to pcie_regs.h
  pcie: helper functions for pcie capability and extended capability
  pcie: comment on hpev_intx
  pci/bridge: fix pci_bridge_reset()
  pcie port: define struct PCIEPort/PCIESlot and helper functions
  ioh3420: pcie root port in X58 ioh
  x3130: pcie upstream port
  x3130: pcie downstream port

Jason Wang (1):
  net: properly handle illegal fd/vhostfd from command line

Michael S. Tsirkin (10):
  migration: don't segfault on invalid input
  virtio: sanity-check available index
  qemu-options.def: add to generated header list
  pcie: simplify range check
  pcie: clean up hot plug notification
  pci: improve w1c mask handling
  msi: simplify range checks
  msi: minor cleanups
  pcie: update satus on reset
  Merge branch 'pci' into for_anthony

 Makefile|7 +-
 Makefile.objs   |   13 +-
 arch_init.c |3 +
 hw/acpi_piix4.c |3 +
 hw/apb_pci.c|   56 --
 hw/dec_pci.c|   46 -
 hw/eepro100.c   |4 +-
 hw/ioh3420.c|  186 
 hw/ioh3420.h|   10 +
 hw/msi.c|  347 ++
 hw/msi.h|   41 
 hw/msix.c   |8 +-
 hw/pci.c|  322 -
 hw/pci.h|  105 -
 hw/pci_bridge.c |  266 +++
 hw/pci_bridge.h |   66 ++
 hw/pci_ids.h|2 +
 hw/pci_internals.h  |   47 
 hw/pcie.c   |  541 +++
 hw/pcie.h   |  120 +++
 hw/pcie_port.c  |  116 ++
 hw/pcie_port.h  |   51 +
 hw/pcie_regs.h  |  154 ++
 hw/virtio.c |   11 +
 hw/xio3130_downstream.c |  188 
 hw/xio3130_downstream.h |   11 +
 hw/xio3130_upstream.c   |  174 +++
 hw/xio3130_upstream.h   |   10 +
 net.c   |   16 +-
 qemu-common.h   |4 +
 30 files changed, 2637 insertions(+), 291 deletions(-)
 create mode 100644 hw/ioh3420.c
 create mode 100644 hw/ioh3420.h
 create mode 100644 hw/msi.c
 create mode 100644 hw/msi.h
 create mode 100644 hw/pci_bridge.c
 create mode 100644 hw/pci_bridge.h
 create mode 100644 hw/pci_internals.h
 create mode 100644 hw/pcie.c
 create mode 100644 hw/pcie.h
 create mode 100644 hw/pcie_port.c
 create mode 100644 hw/pcie_port.h
 create mode 100644 hw/pcie_regs.h
 create mode 100644 hw/xio3130_downstream.c
 create mode 100644 hw/xio3130_downstream.h
 create mode 100644 hw/xio3130_upstream.c
 create mode 100644 hw/xio3130_upstream.h

[Qemu-devel] aminata

2010-10-27 Thread aminata

Cher Monsieur 
 C'est avec plaisir que je m'adresse à ma lettre, je suis HAJI Barry Aminata l'épouse de feu le général de la Guinée. 
 Mon mari a été assassiné pour des raisons politiques en Guinée. Et avant sa mort, il avait gagné et un contrat avec le gouvernement d'une très grande quantité d'argent, je ne peux pas vous dire le montant d'argent dans cette lettre à cause de mes problèmes actuels. Parce que, après la mort de mon mari, j'ai été aussi menacé par le gouvernement parce qu'ils voulaient récupérer tout l'argent du contrat qu'il a donné à mon défunt mari, et j'ai vu l'amour de mes enfants et leur avenir avenir, j'ai dit au gouvernement que je ne savait pas où mon mari avait gardé l'argent, puis le gouvernement a saisi tous les investissements que mon mari avait fait en Guinée. 
 Craignant pour ma vie, j'ai dû fuir d'asile comme des réfugiés politiques à Londres, où je suis actuellement écrit cette lettre, je suis réfugié à Londres. 
Je suis une mère de 3 enfants, 2 garçons et 1 fille, je voudrais que mes enfants soient loin de leurs besoins et de la sécurité. C'est pourquoi j'ai choisi donc d'investir avec vous parce que ça m'a fait réaliser que c'est un pays musulman et de la paix et un homme musulman est un sincère et honnête est pour cette raison, sans même vous connaître, je confie mes secrets (mon mari avait déposé au capital d'une société immobilière dans la capitale du Bénin Cotonou.) 
 Avant de choisir, j'ai prié et jeûné pour Dieu m'a révélé que vous êtes un bon musulman. 
Je veux envoyer une partie de cet argent sous vos soins, afin que nous puissions investir conjointement dans votre pays avec mon fils et acheter une maison pour s'y installer à votre service. 
 Il s'agit d'une lettre confidentielle si vous n'êtes pas intéressé, je vous prie par Allah à rester anonyme. Au cas où vous êtes intéressé, et m'a envoyé tous ces coordonnées ci-dessous. 
  Votre numéro de téléphone: 
  Votre numéro de fax: 
  Votre adresse: 
Votre âge 
 S'il vous plaît s'il vous plaît n'oubliez pas de citer vos coordonnées me permettrait de vous contacter. 
 S'il vous plaît accepter mes salutations les meilleures 
  
 Mon numéro de téléphone: +447031889707

mon e-mail: barrya191 @ gmail.com

[Qemu-devel] Re: [PATCH v2 1/2] pci: introduce pci_region to manage pci io/memory/prefmemory regions.

On Thu, Oct 28, 2010 at 07:56:41AM +0200, Michael S. Tsirkin wrote:
> > diff --git a/src/util.h b/src/util.h
> > index 5cc9f17..17eedd0 100644
> > --- a/src/util.h
> > +++ b/src/util.h
> > @@ -344,6 +344,34 @@ void qemu_prep_reset(void);
> >  void smm_save_and_copy(void);
> >  void smm_relocate_and_restore(void);
> >  
> > +// pci_region.c
> > +// region allocator. pci region allocates the requested region
> > +// sequentially with overflow check.
> > +struct pci_region {
> > +// The region is [start, region).
> 
> [start end)?

Yes. Will fix.

> > +u32 start;
> > +u32 end;
> > +
> > +// The next allocation is start from this.
> > +// i.e. [start, cur_end) is allocated.
> > +// Right after initialization cur_end == start.
> > +u32 cur_end;
> 
> What is the value for a region at 0xf000 and size 0x1000?
>
> 
> Maybe first, last is better to detect this?

You mean [first, last] instead of [start, end).
Maybe Makes sense.
Anyway the area right below 4G can't be used for PCI
because it's used for LAPIC and so on.


> 
> > +};
> > +// initialize the pci_region of [start, end)
> > +void pci_region_init(struct pci_region *r, u32 start, u32 end);
> > +// allocate the region of size
> > +u32 pci_region_alloc(struct pci_region *r, u32 size);
> > +// make the next allocation aligned to align
> > +u32 pci_region_align(struct pci_region *r, u32 align);
> > +// revert the allocation to addr.
> > +void pci_region_revert(struct pci_region *r, u32 addr);
> > +// make the allocation fail.
> > +u32 pci_region_disable(struct pci_region *r);
> > +// returns the current allocation point.
> > +u32 pci_region_addr(const struct pci_region *r);
> > +// returns the region size.
> > +u32 pci_region_size(const struct pci_region *r);
> > +
> >  // pciinit.c
> >  extern const u8 pci_irqs[4];
> >  void pci_bios_allocate_regions(u16 bdf, void *arg);
> > -- 
> > 1.7.1.1
> 

-- 
yamahata

[Qemu-devel] Re: [PATCH v2 2/2] pciinit: use pci_region functions.