qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Auger <eric.auger@linaro.org>
To: Alexander Graf <agraf@suse.de>,
	eric.auger@st.com, christoffer.dall@linaro.org,
	qemu-devel@nongnu.org, kim.phillips@freescale.com,
	a.rigo@virtualopensystems.com
Cc: peter.maydell@linaro.org, patches@linaro.org,
	stuart.yoder@freescale.com, alex.williamson@redhat.com,
	christophe.barnichon@st.com, a.motakis@virtualopensystems.com,
	kvmarm@lists.cs.columbia.edu
Subject: Re: [Qemu-devel] [RFC v3 06/10] virt: Assign a VFIO platform device with -device option
Date: Thu, 26 Jun 2014 11:30:49 +0200	[thread overview]
Message-ID: <53ABE849.4070102@linaro.org> (raw)
In-Reply-To: <53ABE723.8030107@suse.de>

On 06/26/2014 11:25 AM, Alexander Graf wrote:
> 
> On 26.06.14 10:53, Eric Auger wrote:
>> On 06/25/2014 11:30 PM, Alexander Graf wrote:
>>> On 02.06.14 09:49, Eric Auger wrote:
>>>> This patch aims at allowing the end-user to specify the device he
>>>> wants to directly assign to his mach-virt guest in the QEMU command
>>>> line.
>>>>
>>>> The QEMU platform device becomes generic.
>>>>
>>>> Current choice is to reuse the "-device" option.
>>>>
>>>> For example when assigning Calxeda Midway xgmac device this option
>>>> is used:
>>>> -device vfio-platform,vfio_device="fff51000.ethernet",\
>>>> compat="calxeda/hb-xgmac",mmap-timeout-ms=1000
>>> I think we're walking into the right direction, but there is one major
>>> nit I have. I don't think we should have a -device vfio-platform. I
>>> think we should have a -device vfio-xgmac that maybe inherits from an
>>> abstrace vfio-platform class.
>>>
>>> That way machine code can assemble the device tree according to the
>>> device and you can also implement hardware specific hacks or
>>> dependencies if you need them - for example the MMIO masking to find an
>>> EOI you did earlier.
>> I must admit I am lacking experience of other devices than my dear
>> xgmac. I can just say that for the time beeing the approach seems to fit
>> some ARM Amba devices like PL330 DMA. We need to go further to identity
>> the limits of this generic approach.
> 
> No, I think we're better off not faking anything generic at all, because
> I'm 99.9% sure it will never be generic in real-world device cases.
> 
> And if we start doing things generically, people will soon want to have
> other mad additions to do device specific things in generic code, such
> as "take the device tree from the host, but modify property x, y and z".
> Better be clear about our limits from the beginning :).
> 
> Imagine vfio-platform as a transport, similar to TCP. We have ports and
> moving data from left to right is always the same, but whether you need
> to open 2 ports to get a working FTP data transfer is up to the
> implementation of the protocol above. Same thing here.
OK you convinced me. I will investigate that way then.
Eric
> 
> 
> Alex
> 

  reply	other threads:[~2014-06-26  9:31 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-02  7:49 [Qemu-devel] [RFC v3 00/10] KVM platform device passthrough Eric Auger
2014-06-02  7:49 ` [Qemu-devel] [RFC v3 01/10] hw/arm/virt: add a xgmac device Eric Auger
2014-06-02  7:49 ` [Qemu-devel] [RFC v3 02/10] vfio: move hw/misc/vfio.c to hw/vfio/pci.c Eric Auger
2014-06-02  7:49 ` [Qemu-devel] [RFC v3 03/10] vfio: add vfio-platform support Eric Auger
2014-06-25 21:21   ` Alexander Graf
2014-06-26  7:47     ` Eric Auger
2014-06-26  9:56       ` Alexander Graf
2014-06-02  7:49 ` [Qemu-devel] [RFC v3 04/10] vfio: simplifed DPRINTF calls using device name Eric Auger
2014-06-25 21:22   ` Alexander Graf
2014-06-02  7:49 ` [Qemu-devel] [RFC v3 05/10] vfio: Add initial IRQ support in platform device Eric Auger
2014-06-25 21:28   ` Alexander Graf
2014-06-25 21:40     ` Alex Williamson
2014-06-26  8:41       ` Eric Auger
2014-06-02  7:49 ` [Qemu-devel] [RFC v3 06/10] virt: Assign a VFIO platform device with -device option Eric Auger
2014-06-25 21:30   ` Alexander Graf
2014-06-26  8:53     ` Eric Auger
2014-06-26  9:25       ` Alexander Graf
2014-06-26  9:30         ` Eric Auger [this message]
2014-06-25 22:28   ` Peter Maydell
2014-06-25 22:28     ` Alexander Graf
2014-06-26  7:39       ` Eric Auger
2014-06-02  7:49 ` [Qemu-devel] [RFC v3 07/10] Add EXEC_FLAG to VFIO DMA mappings Eric Auger
2014-06-02  7:49 ` [Qemu-devel] [RFC v3 08/10] Add AMBA devices support to VFIO Eric Auger
2014-06-02  7:49 ` [Qemu-devel] [RFC v3 09/10] Always use eventfd as notifying mechanism Eric Auger
2014-06-02  7:49 ` [Qemu-devel] [RFC v3 10/10] vfio: Add irqfd support in platform device Eric Auger
2014-06-25 21:35   ` Alexander Graf
2014-06-25 21:54     ` Alex Williamson
2014-06-25 22:02       ` Alexander Graf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53ABE849.4070102@linaro.org \
    --to=eric.auger@linaro.org \
    --cc=a.motakis@virtualopensystems.com \
    --cc=a.rigo@virtualopensystems.com \
    --cc=agraf@suse.de \
    --cc=alex.williamson@redhat.com \
    --cc=christoffer.dall@linaro.org \
    --cc=christophe.barnichon@st.com \
    --cc=eric.auger@st.com \
    --cc=kim.phillips@freescale.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=patches@linaro.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stuart.yoder@freescale.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).