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;
>> alex.w
> -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 Fri, 1 Jul 2011 17:32:43 -0500
Anthony Liguori 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 we call ISA f
> 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
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 wrote:
> Basically you should start by implementing full emulation of a device
> with similar characteristics to the one you wan
> On Fri, 2011-07-01 at 21:59 +0100, Paul Brook wrote:
> > > On Fri, 1 Jul 2011 18:03:01 +0100
> > >
> > > Paul Brook wrote:
> > > > Basically you should start by implementing full emulation of a device
> > > > with similar characteristics to the one you want to passthrough.
> > >
> > > That's n
> > 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 implemen
On Fri, 2011-07-01 at 21:59 +0100, Paul Brook wrote:
> > On Fri, 1 Jul 2011 18:03:01 +0100
> >
> > Paul Brook 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 happ
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 07/01/2011 11:43 AM, Scott Wood wrote:
On Fri, 1 Jul 2011 07:10:45 -0500
Anthony Liguori 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 "m
On Fri, 1 Jul 2011 21:59:35 +0100
Paul Brook wrote:
> > On Fri, 1 Jul 2011 18:03:01 +0100
> >
> > Paul Brook 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 hap
> On Fri, 1 Jul 2011 18:03:01 +0100
>
> Paul Brook 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 interact with the gu
On Fri, 1 Jul 2011 12:16:35 +0100
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
> > 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 some
On Fri, 1 Jul 2011 18:03:01 +0100
Paul Brook 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 passthrough should be relativ
On Fri, 1 Jul 2011 07:10:45 -0500
Anthony Liguori 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"]
> region[0].file = "/d
On Fri, 1 Jul 2011 10:58:14 +1000
Benjamin Herrenschmidt 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 normal MMIO mapped
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 slight
> > 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 th
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 host
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 hierarch
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 me
> 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 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 the
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 embed
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
> 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 hos
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
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 Linux
29 matches
Mail list logo
