From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: Gleb Natapov <gleb@redhat.com>,
kvm@vger.kernel.org, Alexander Graf <agraf@suse.de>,
linux-kernel@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [PATCH v8] KVM: PPC: reserve a capability and ioctl numbers for realmode VFIO
Date: Wed, 28 Aug 2013 11:26:31 +1000 [thread overview]
Message-ID: <1377653191.3819.146.camel@pasglop> (raw)
In-Reply-To: <521D4977.7060803@ozlabs.ru>
On Wed, 2013-08-28 at 10:51 +1000, Alexey Kardashevskiy wrote:
> The ioctl I made up is basically a copy of KVM_CREATE_SPAPR_TCE which does
> the same thing for emulated devices and it is there for quite a while but
> it is not really extensible. And these two ioctls share some bits of code.
> Now we will have 2 pieces of code which do almost the same thing but in a
> different way. Kinda sucks :(
Right. Thus the question, Gleb, we can either:
- Keep Alexey patch as-is allowing us to *finally* merge that stuff
that's been around for monthes
- Convert *both* existing TCE objects to the new
KVM_CREATE_DEVICE, and have some backward compat code for the old one.
I don't think it makes sense to have the "emulated TCE" and "IOMMU TCE"
objects use a fundamentally different API and infrastructure.
> >> So my stuff is not going to upstream again. Heh. Ok. I'll implement it.
> >>
> > Thanks! Should I keep KVM_CAP_SPAPR_MULTITCE capability patch or can I
> > drop it for now?
>
> Please keep it, it is unrelated to the IOMMU-VFIO thing.
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: Gleb Natapov <gleb@redhat.com>,
linuxppc-dev@lists.ozlabs.org,
David Gibson <david@gibson.dropbear.id.au>,
Paul Mackerras <paulus@samba.org>,
kvm@vger.kernel.org, Alexander Graf <agraf@suse.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v8] KVM: PPC: reserve a capability and ioctl numbers for realmode VFIO
Date: Wed, 28 Aug 2013 11:26:31 +1000 [thread overview]
Message-ID: <1377653191.3819.146.camel@pasglop> (raw)
In-Reply-To: <521D4977.7060803@ozlabs.ru>
On Wed, 2013-08-28 at 10:51 +1000, Alexey Kardashevskiy wrote:
> The ioctl I made up is basically a copy of KVM_CREATE_SPAPR_TCE which does
> the same thing for emulated devices and it is there for quite a while but
> it is not really extensible. And these two ioctls share some bits of code.
> Now we will have 2 pieces of code which do almost the same thing but in a
> different way. Kinda sucks :(
Right. Thus the question, Gleb, we can either:
- Keep Alexey patch as-is allowing us to *finally* merge that stuff
that's been around for monthes
- Convert *both* existing TCE objects to the new
KVM_CREATE_DEVICE, and have some backward compat code for the old one.
I don't think it makes sense to have the "emulated TCE" and "IOMMU TCE"
objects use a fundamentally different API and infrastructure.
> >> So my stuff is not going to upstream again. Heh. Ok. I'll implement it.
> >>
> > Thanks! Should I keep KVM_CAP_SPAPR_MULTITCE capability patch or can I
> > drop it for now?
>
> Please keep it, it is unrelated to the IOMMU-VFIO thing.
next prev parent reply other threads:[~2013-08-28 1:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-15 7:49 [PATCH v8] KVM: PPC: reserve a capability and ioctl numbers for realmode VFIO Alexey Kardashevskiy
2013-08-15 7:49 ` Alexey Kardashevskiy
2013-08-27 7:56 ` Gleb Natapov
2013-08-27 7:56 ` Gleb Natapov
2013-08-27 8:42 ` Alexey Kardashevskiy
2013-08-27 8:42 ` Alexey Kardashevskiy
2013-08-27 10:58 ` Gleb Natapov
2013-08-27 10:58 ` Gleb Natapov
2013-08-28 0:51 ` Alexey Kardashevskiy
2013-08-28 0:51 ` Alexey Kardashevskiy
2013-08-28 1:26 ` Benjamin Herrenschmidt [this message]
2013-08-28 1:26 ` Benjamin Herrenschmidt
2013-08-28 6:38 ` Gleb Natapov
2013-08-28 6:38 ` Gleb Natapov
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=1377653191.3819.146.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=agraf@suse.de \
--cc=aik@ozlabs.ru \
--cc=david@gibson.dropbear.id.au \
--cc=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paulus@samba.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.