On Fri, 1 Jul 2011 17:32:43 -0500
Anthony Liguori anth...@codemonkey.ws wrote:
On 07/01/2011 11:43 AM, Scott Wood wrote:
However, we'll need to address the question of what it means to say irq 10
It depends on what the bus is. If you're going to declare system bus
which is sort of what
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Sent: Thursday, June 30, 2011 7:58 PM
To: Yoder Stuart-B08248
Cc: qemu-devel@nongnu.org; Wood Scott-B07421; Alexander Graf;
alex.william...@redhat.com;
anth...@codemonkey.ws; d...@au1.ibm.com;
On 05.07.2011, at 20:19, Yoder Stuart-B08248 wrote:
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Sent: Thursday, June 30, 2011 7:58 PM
To: Yoder Stuart-B08248
Cc: qemu-devel@nongnu.org; Wood Scott-B07421; Alexander Graf;
So you're basically saying we should tackle these 3 issues separately:
* actually pass through a device
* generate interrupt links
* model the guest device tree dynamically based on whatever the user
gives us
Yes.
Paul
One feature we need for QEMU/KVM on embedded Power Architecture is the
ability to do passthru assignment of SoC I/O devices and memory. An
important use case in embedded is creating static partitions--
taking physical memory and I/O devices (non-PCI) and partitioning
them between the host
On 01.07.2011, at 13:16, Paul Brook wrote:
One feature we need for QEMU/KVM on embedded Power Architecture is the
ability to do passthru assignment of SoC I/O devices and memory. An
important use case in embedded is creating static partitions--
taking physical memory and I/O devices
On 01.07.2011, at 02:58, Benjamin Herrenschmidt wrote:
On Thu, 2011-06-30 at 15:59 +, Yoder Stuart-B08248 wrote:
One feature we need for QEMU/KVM on embedded Power Architecture is the
ability to do passthru assignment of SoC I/O devices and memory. An
important use case in embedded is
On 01.07.2011, at 13:55, Paul Brook wrote:
But the real challenge is how to expose the device to the guest device
tree. Especially when it comes to links between dt nodes, interrupt maps,
etc. We basically have 3 choices there:
* take the host device tree pieces and modify them
*
But the real challenge is how to expose the device to the guest device
tree. Especially when it comes to links between dt nodes, interrupt maps,
etc. We basically have 3 choices there:
* take the host device tree pieces and modify them
* provide device tree chunks for each device
On 07/01/2011 06:40 AM, Alexander Graf wrote:
On 01.07.2011, at 02:58, Benjamin Herrenschmidt wrote:
On Thu, 2011-06-30 at 15:59 +, Yoder Stuart-B08248 wrote:
One feature we need for QEMU/KVM on embedded Power Architecture is the
ability to do passthru assignment of SoC I/O devices and
On 06/30/2011 07:58 PM, Benjamin Herrenschmidt wrote:
On Thu, 2011-06-30 at 15:59 +, Yoder Stuart-B08248 wrote:
This avoids needing to pass the host device tree, but could
get awkward-- the i2c example above is very simple, some device
nodes are very large with a complex
On 07/01/2011 07:02 AM, Alexander Graf wrote:
On 01.07.2011, at 13:55, Paul Brook wrote:
But the real challenge is how to expose the device to the guest device
tree. Especially when it comes to links between dt nodes, interrupt maps,
etc. We basically have 3 choices there:
* take the
So, from a qemu command line perspective, all you should have to do is
pass qemu the device-tree -path- to the device you want to pass-trough
(you may support passing a full hierarchy here).
I agree in principle but I think it should be done in a slightly
different way.
I think we
On 07/01/2011 07:52 AM, Paul Brook wrote:
So, from a qemu command line perspective, all you should have to do is
pass qemu the device-tree -path- to the device you want to pass-trough
(you may support passing a full hierarchy here).
I agree in principle but I think it should be done in a
On Fri, 1 Jul 2011 10:58:14 +1000
Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
So, from a qemu command line perspective, all you should have to do is
pass qemu the device-tree -path- to the device you want to pass-trough
(you may support passing a full hierarchy here).
That is for
On Fri, 1 Jul 2011 07:10:45 -0500
Anthony Liguori anth...@codemonkey.ws wrote:
I agree in principle but I think it should be done in a slightly
different way.
I think we ought to support composing a device by passthrough. For
instance, something like:
[physical-device mydev]
On Fri, 1 Jul 2011 18:03:01 +0100
Paul Brook p...@codesourcery.com wrote:
Basically you should start by implementing full emulation of a device with
similar characteristics to the one you want to passthrough.
That's not going to happen.
Once you've done all the above, host device
irq[0].guest_irq = 10
This should be independent of anything to do with device tree. This
would be useful for x86 too to assign platform devices (like the HPET).
That's fine, as long as there's something layered on top of it for the case
where we do want to reference something in the
On Fri, 1 Jul 2011 12:16:35 +0100
Paul Brook p...@codesourcery.com wrote:
One feature we need for QEMU/KVM on embedded Power Architecture is the
ability to do passthru assignment of SoC I/O devices and memory. An
important use case in embedded is creating static partitions--
taking
On Fri, 1 Jul 2011 18:03:01 +0100
Paul Brook p...@codesourcery.com wrote:
Basically you should start by implementing full emulation of a device
with similar characteristics to the one you want to passthrough.
That's not going to happen.
Why is your device so unique? How does it
On Fri, 1 Jul 2011 21:59:35 +0100
Paul Brook p...@codesourcery.com wrote:
On Fri, 1 Jul 2011 18:03:01 +0100
Paul Brook p...@codesourcery.com wrote:
Basically you should start by implementing full emulation of a device
with similar characteristics to the one you want to passthrough.
On 07/01/2011 11:43 AM, Scott Wood wrote:
On Fri, 1 Jul 2011 07:10:45 -0500
Anthony Liguorianth...@codemonkey.ws wrote:
I agree in principle but I think it should be done in a slightly
different way.
I think we ought to support composing a device by passthrough. For
instance, something
On 07/01/2011 12:03 PM, Paul Brook wrote:
irq[0].guest_irq = 10
This should be independent of anything to do with device tree. This
would be useful for x86 too to assign platform devices (like the HPET).
That's fine, as long as there's something layered on top of it for the case
where we do
On Fri, 2011-07-01 at 21:59 +0100, Paul Brook wrote:
On Fri, 1 Jul 2011 18:03:01 +0100
Paul Brook p...@codesourcery.com wrote:
Basically you should start by implementing full emulation of a device
with similar characteristics to the one you want to passthrough.
That's not going
Why is your device so unique? How does it interact with the guest system
and what features does it require that doen't exist in any device that
can be emulated?
Perhaps I misunderstood what you meant by similar characteristics. I see
no reason to spend a bunch of time implementing full
On Fri, 2011-07-01 at 21:59 +0100, Paul Brook wrote:
On Fri, 1 Jul 2011 18:03:01 +0100
Paul Brook p...@codesourcery.com wrote:
Basically you should start by implementing full emulation of a device
with similar characteristics to the one you want to passthrough.
That's not
On 02.07.2011, at 01:50, Paul Brook wrote:
On Fri, 2011-07-01 at 21:59 +0100, Paul Brook wrote:
On Fri, 1 Jul 2011 18:03:01 +0100
Paul Brook p...@codesourcery.com wrote:
Basically you should start by implementing full emulation of a device
with similar characteristics to the one you want
One feature we need for QEMU/KVM on embedded Power Architecture is the
ability to do passthru assignment of SoC I/O devices and memory. An
important use case in embedded is creating static partitions--
taking physical memory and I/O devices (non-PCI) and partitioning
them between the host
On Thu, 2011-06-30 at 15:59 +, Yoder Stuart-B08248 wrote:
One feature we need for QEMU/KVM on embedded Power Architecture is the
ability to do passthru assignment of SoC I/O devices and memory. An
important use case in embedded is creating static partitions--
taking physical memory and
29 matches
Mail list logo
