headers
Michael S. Tsirkin | 1 Apr 2011 01:42
Picon
Favicon

Re: [PATCH RFC] vga: flag vga ram for notifiers

On Thu, Mar 31, 2011 at 04:49:46PM -0500, Anthony Liguori wrote:
> On 03/31/2011 04:38 PM, Michael S. Tsirkin wrote:
> >
> >>That seems like a clearer API, yes. I think it makes it much more
> >>obvious what it's trying to achieve.
> >>
> >>-- PMM
> >Maybe register_dma_area - its' not 100% virtio specific.
> 
> It's never been clear to me whether that's true or not.  I've heard
> mixed things about whether devices DMA to other devices.  I've never
> been able to find something in a specification stating
> authoritatively one way or another.
> 
> Regards,
> 
> Anthony Liguori
> 

AFAIK the capability of cross-talk between PCI devices
exists in PCI and is optional in PCI Express.

PCI spec says:
	Full multi-master capability allowing any PCI master peer-to-peer
	access to any PCI master/target.

The Express spec says:
	"The capability to route peer-to-peer transactions between hierarchy
	domains through a Root Complex is optional and implementation dependent.
	For example, an implementation may incorporate a real or virtual Switch
(Continue reading)

Permalink | Reply | 2 comments |
headers
Anthony Liguori | 1 Apr 2011 02:44

Re: [PATCH RFC] vga: flag vga ram for notifiers

On 03/31/2011 06:42 PM, Michael S. Tsirkin wrote:
> On Thu, Mar 31, 2011 at 04:49:46PM -0500, Anthony Liguori wrote:
>> On 03/31/2011 04:38 PM, Michael S. Tsirkin wrote:
>>>> That seems like a clearer API, yes. I think it makes it much more
>>>> obvious what it's trying to achieve.
>>>>
>>>> -- PMM
>>> Maybe register_dma_area - its' not 100% virtio specific.
>> It's never been clear to me whether that's true or not.  I've heard
>> mixed things about whether devices DMA to other devices.  I've never
>> been able to find something in a specification stating
>> authoritatively one way or another.
>>
>> Regards,
>>
>> Anthony Liguori
>>
> AFAIK the capability of cross-talk between PCI devices
> exists in PCI and is optional in PCI Express.
>
> PCI spec says:
> 	Full multi-master capability allowing any PCI master peer-to-peer
> 	access to any PCI master/target.
>
> The Express spec says:
> 	"The capability to route peer-to-peer transactions between hierarchy
> 	domains through a Root Complex is optional and implementation dependent.
> 	For example, an implementation may incorporate a real or virtual Switch
> 	internally within the Root Complex to enable full peer-to- peer support
> 	in a software transparent way."
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael S. Tsirkin | 1 Apr 2011 03:07
Picon
Favicon

Re: [PATCH RFC] vga: flag vga ram for notifiers

On Thu, Mar 31, 2011 at 07:44:35PM -0500, Anthony Liguori wrote:
> On 03/31/2011 06:42 PM, Michael S. Tsirkin wrote:
> >On Thu, Mar 31, 2011 at 04:49:46PM -0500, Anthony Liguori wrote:
> >>On 03/31/2011 04:38 PM, Michael S. Tsirkin wrote:
> >>>>That seems like a clearer API, yes. I think it makes it much more
> >>>>obvious what it's trying to achieve.
> >>>>
> >>>>-- PMM
> >>>Maybe register_dma_area - its' not 100% virtio specific.
> >>It's never been clear to me whether that's true or not.  I've heard
> >>mixed things about whether devices DMA to other devices.  I've never
> >>been able to find something in a specification stating
> >>authoritatively one way or another.
> >>
> >>Regards,
> >>
> >>Anthony Liguori
> >>
> >AFAIK the capability of cross-talk between PCI devices
> >exists in PCI and is optional in PCI Express.
> >
> >PCI spec says:
> >	Full multi-master capability allowing any PCI master peer-to-peer
> >	access to any PCI master/target.
> >
> >The Express spec says:
> >	"The capability to route peer-to-peer transactions between hierarchy
> >	domains through a Root Complex is optional and implementation dependent.
> >	For example, an implementation may incorporate a real or virtual Switch
> >	internally within the Root Complex to enable full peer-to- peer support
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Gibson | 1 Apr 2011 06:15
Picon

[PATCH 02/27] Allow qemu_devtree_setprop() to take arbitrary values

From: David Gibson <dwg <at> au1.ibm.com>

Currently qemu_devtree_setprop() expects the new property value to be
given as a uint32_t *.  While property values consisting of u32s are
common, in general they can have any bytestring value.

Therefore, this patch alters the function to take a void * instead,
allowing callers to easily give anything as the property value.

Signed-off-by: David Gibson <david <at> gibson.dropbear.id.au>
---
 device_tree.c |    2 +-
 device_tree.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/device_tree.c b/device_tree.c
index 426a631..21be070 100644
--- a/device_tree.c
+++ b/device_tree.c
 <at>  <at>  -74,7 +74,7  <at>  <at>  fail:
 }

 int qemu_devtree_setprop(void *fdt, const char *node_path,
-                         const char *property, uint32_t *val_array, int size)
+                         const char *property, void *val_array, int size)
 {
     int offset;

diff --git a/device_tree.h b/device_tree.h
index f05c4e7..cecd98f 100644
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Gibson | 1 Apr 2011 06:15
Picon

[PATCH 03/27] Add a hook to allow hypercalls to be emulated on PowerPC

PowerPC and POWER chips since the POWER4 and 970 have a special
hypervisor mode, and a corresponding form of the system call
instruction which traps to the hypervisor.

qemu currently has stub implementations of hypervisor mode.  That
is, the outline is there to allow qemu to run a PowerPC hypervisor
under emulation.  There are a number of details missing so this
won't actually work at present, but the idea is there.

What there is no provision at all, is for qemu to instead emulate
the hypervisor itself.  That is to have hypercalls trap into qemu
and their result be emulated from qemu, rather than running
hypervisor code within the emulated system.

Hypervisor hardware aware KVM implementations are in the works and
it would  be useful for debugging and development to also allow
full emulation of the same para-virtualized guests as such a KVM.

Therefore, this patch adds a hook which will allow a machine to
set up emulation of hypervisor calls.

Signed-off-by: David Gibson <dwg <at> au1.ibm.com>
---
 target-ppc/cpu.h    |    2 ++
 target-ppc/helper.c |    8 ++++++++
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index 124bbbf..36ca342 100644
--- a/target-ppc/cpu.h
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Gibson | 1 Apr 2011 06:15
Picon

[PATCH 01/27] Clean up PowerPC SLB handling code

Currently the SLB information when emulating a PowerPC 970 is
storeed in a structure with the unhelpfully named fields 'tmp'
and 'tmp64'.  While the layout in these fields does match the
description of the SLB in the architecture document, it is not
convenient either for looking up the SLB, or for emulating the
slbmte instruction.

This patch, therefore, reorganizes the SLB entry structure to be
divided in the the "ESID related" and "VSID related" fields as
they are divided in instructions accessing the SLB.

In addition to making the code smaller and more readable, this will
make it easier to implement for the 1TB segments used in more
recent PowerPC chips.

Signed-off-by: David Gibson <dwg <at> au1.ibm.com>
---
 target-ppc/cpu.h       |   29 +++++++-
 target-ppc/helper.c    |  178 ++++++++++++++----------------------------------
 target-ppc/helper.h    |    1 -
 target-ppc/op_helper.c |    9 +--
 4 files changed, 80 insertions(+), 137 deletions(-)

diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index deb8d7c..124bbbf 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
 <at>  <at>  -43,6 +43,8  <at>  <at> 
 # define TARGET_VIRT_ADDR_SPACE_BITS 64
 #endif
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Gibson | 1 Apr 2011 06:15
Picon

[0/27] Implement emulation of pSeries logical partitions (v6)

This patch series adds a "pseries" machine to qemu, allowing it to
emulate IBM pSeries logical partitions.  More specifically it
implements the interface defined by the "PowerPC Architecture Platform
Requirements" document (PAPR, or sPAPR for short).

Along the way we add a bunch of support for more modern ppc CPUs than
are currently supported.  It also makes some significant cleanups to
the translation code for hash page table based ppc MMUs.

Please apply.

---

Changes since v5 of this series:
 * Include source for SLOF as a git submodule
 * Move our private hcalls (well. only one so far) to a range
   explicitly reserved by PAPR for this purpose.
 * Allocate an ample 1024 irqs in the XICS controller, rather than
   having a somewhat dubious calculation of precisely how many we
   need.

Changes since v4 of this series:
 * Fix build breakages for powerpc targets other than ppc64 full system.
 * Since the pseries platform requires libfdt, only compile it when
   configured with --enable-fdt
 * Give an informative error if invoked with insufficient guest RAM to
   run the partition firmware.  Without this, giving insufficient RAM
   - such as qemu's default 64M - would lead to the firmware failing
   cryptically partway through boot.
(Continue reading)

Permalink | Reply | 41 comments |
headers
David Gibson | 1 Apr 2011 06:15
Picon

[PATCH 12/27] Add POWER7 support for ppc

This adds emulation support for the recent POWER7 cpu to qemu.  It's far
from perfect - it's missing a number of POWER7 features so far, including
any support for VSX or decimal floating point instructions.  However, it's
close enough to boot a kernel with the POWER7 PVR.

Signed-off-by: David Gibson <dwg <at> au1.ibm.com>
---
 hw/ppc.c                    |   35 ++++++++++++++
 hw/ppc.h                    |    1 +
 target-ppc/cpu.h            |   16 ++++++
 target-ppc/helper.c         |    6 ++
 target-ppc/translate_init.c |  107 +++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 165 insertions(+), 0 deletions(-)

diff --git a/hw/ppc.c b/hw/ppc.c
index b55a848..dabb816 100644
--- a/hw/ppc.c
+++ b/hw/ppc.c
 <at>  <at>  -247,6 +247,41  <at>  <at>  void ppc970_irq_init (CPUState *env)
     env->irq_inputs = (void **)qemu_allocate_irqs(&ppc970_set_irq, env,
                                                   PPC970_INPUT_NB);
 }
+
+/* POWER7 internal IRQ controller */
+static void power7_set_irq (void *opaque, int pin, int level)
+{
+    CPUState *env = opaque;
+    int cur_level;
+
+    LOG_IRQ("%s: env %p pin %d level %d\n", __func__,
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Gibson | 1 Apr 2011 06:15
Picon

[PATCH 04/27] Implement PowerPC slbmfee and slbmfev instructions

For a 64-bit PowerPC target, qemu correctly implements translation
through the segment lookaside buffer.  Likewise it supports the
slbmte instruction which is used to load entries into the SLB.

However, it does not emulate the slbmfee and slbmfev instructions
which read SLB entries back into registers.  Because these are
only occasionally used in guests (mostly for debugging) we get
away with it.

However, given the recent SLB cleanups, it becomes quite easy to
implement these, and thereby allow, amongst other things, a guest
Linux to use xmon's command to dump the SLB.

Signed-off-by: David Gibson <dwg <at> au1.ibm.com>
---
 target-ppc/cpu.h       |    2 ++
 target-ppc/helper.c    |   26 ++++++++++++++++++++++++++
 target-ppc/helper.h    |    2 ++
 target-ppc/op_helper.c |   20 ++++++++++++++++++++
 target-ppc/translate.c |   31 ++++++++++++++++++++++++++++++-
 5 files changed, 80 insertions(+), 1 deletions(-)

diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index 36ca342..f293f85 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
 <at>  <at>  -779,6 +779,8  <at>  <at>  void ppc_store_asr (CPUPPCState *env, target_ulong value);
 target_ulong ppc_load_slb (CPUPPCState *env, int slb_nr);
 target_ulong ppc_load_sr (CPUPPCState *env, int sr_nr);
 int ppc_store_slb (CPUPPCState *env, target_ulong rb, target_ulong rs);
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Gibson | 1 Apr 2011 06:15
Picon

[PATCH 09/27] Use "hash" more consistently in ppc mmu code

Currently, get_segment() has a variable called hash.  However it doesn't
(quite) get the hash value for the ppc hashed page table.  Instead it
gets the hash shifted - effectively the offset of the hash bucket within
the hash page table.

As well, as being different to the normal use of plain "hash" in the
architecture documentation, this usage necessitates some awkward 32/64
dependent masks and shifts which clutter up the path in get_segment().

This patch alters the code to use raw hash values through get_segment()
including storing raw hashes instead of pte group offsets in the ctx
structure.  This cleans up the path noticeably.

This does necessitate 32/64 dependent shifts when the hash values are
taken out of the ctx structure and used, but those paths already have
32/64 bit variants so this is less awkward than it was in get_segment().

Signed-off-by: David Gibson <dwg <at> au1.ibm.com>
---
 target-ppc/cpu.h    |    5 ++-
 target-ppc/helper.c |   95 ++++++++++++++++++++++++--------------------------
 2 files changed, 50 insertions(+), 50 deletions(-)

diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index ead4566..cee1057 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
 <at>  <at>  -367,6 +367,9  <at>  <at>  union ppc_tlb_t {
 #define SDR_64_HTABSIZE        0x000000000000001FULL
 #endif /* defined(TARGET_PPC64 */
(Continue reading)

Permalink | Reply | 0 comments |

Gmane