On Fri, 7 Oct 2016 10:46:22 +0530
Kirti Wankhede wrote:
> Ping..
>
> Pulling the questions at the top.
>
> >> Will libvirt report 'description' RO attribute, its output would be
> >> string, so that user could be able to see the configuration of that
> >> profile?
> >>
> >
> > Daniel,
> > Wai
Ping..
Pulling the questions at the top.
>> Will libvirt report 'description' RO attribute, its output would be
>> string, so that user could be able to see the configuration of that
>> profile?
>>
>
> Daniel,
> Waiting for your input on this.
>
>> We can have 'class' as optional attribute. So In
On 9/30/2016 10:49 AM, Kirti Wankhede wrote:
>
...
>> Hi Daniel,
>>
>> Here you are proposing to add a class named "gpu", which will make all
>> those gpu
>> related attributes mandatory, which libvirt can allow user to better
>> parse/present a particular mdev configur
On 9/29/2016 8:12 PM, Tian, Kevin wrote:
>> From: Daniel P. Berrange [mailto:berra...@redhat.com]
>> Sent: Thursday, September 29, 2016 10:39 PM
>>
>> On Thu, Sep 29, 2016 at 02:35:48PM +, Tian, Kevin wrote:
From: Daniel P. Berrange [mailto:berra...@redhat.com]
Sent: Thursday, Septe
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Thursday, September 29, 2016 10:39 PM
>
> On Thu, Sep 29, 2016 at 02:35:48PM +, Tian, Kevin wrote:
> > > From: Daniel P. Berrange [mailto:berra...@redhat.com]
> > > Sent: Thursday, September 29, 2016 4:06 PM
> > >
> > > On Wed, Se
On Thu, Sep 29, 2016 at 02:35:48PM +, Tian, Kevin wrote:
> > From: Daniel P. Berrange [mailto:berra...@redhat.com]
> > Sent: Thursday, September 29, 2016 4:06 PM
> >
> > On Wed, Sep 28, 2016 at 12:48:33PM -0700, Neo Jia wrote:
> > > On Tue, Sep 20, 2016 at 10:47:53AM +0100, Daniel P. Berrange
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Thursday, September 29, 2016 4:06 PM
>
> On Wed, Sep 28, 2016 at 12:48:33PM -0700, Neo Jia wrote:
> > On Tue, Sep 20, 2016 at 10:47:53AM +0100, Daniel P. Berrange wrote:
> > > On Tue, Sep 20, 2016 at 02:05:52AM +0530, Kirti Wankhede w
7. Hot-plug
It is same syntax to create a virtual device for hot-plug.
>>>
>>> How do groups work with hotplug? Can a device be creating into an
>>> existing, running group? Can a device be removed from an existing,
>>> running group? Th
On Wed, Sep 28, 2016 at 12:48:33PM -0700, Neo Jia wrote:
> On Tue, Sep 20, 2016 at 10:47:53AM +0100, Daniel P. Berrange wrote:
> > On Tue, Sep 20, 2016 at 02:05:52AM +0530, Kirti Wankhede wrote:
> > >
> > > Hi libvirt experts,
> > >
> > > Thanks for valuable input on v1 version of RFC.
> > >
> >
On Tue, Sep 20, 2016 at 10:47:53AM +0100, Daniel P. Berrange wrote:
> On Tue, Sep 20, 2016 at 02:05:52AM +0530, Kirti Wankhede wrote:
> >
> > Hi libvirt experts,
> >
> > Thanks for valuable input on v1 version of RFC.
> >
> > Quick brief, VFIO based mediated device framework provides a way to
>
On 9/23/2016 12:55 AM, Tian, Kevin wrote:
>> From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
>> Sent: Wednesday, September 21, 2016 12:23 AM
>>>
> I have
> a hard time believing that a given vendor can even allocate unique type
> ids for their own devices. Unique type id across v
> From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> Sent: Wednesday, September 21, 2016 12:23 AM
> >
> >>> I have
> >>> a hard time believing that a given vendor can even allocate unique type
> >>> ids for their own devices. Unique type id across vendors is not
> >>> practical. So which attri
On Thu, 22 Sep 2016 09:41:20 +0530
Kirti Wankhede wrote:
> > My concern is that a type id seems arbitrary but we're specifying that
> > it be unique. We already have something unique, the name. So why try
> > to make the type id unique as well? A vendor can accidentally create
> >>
> My concern is that a type id seems arbitrary but we're specifying that
> it be unique. We already have something unique, the name. So why try
> to make the type id unique as well? A vendor can accidentally create
> their vendor driver so that a given name means something ver
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Thursday, September 22, 2016 11:02 AM
>
> On Thu, 22 Sep 2016 02:33:01 +
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > Sent: Wednesday, September 21, 2016 12:37 PM
> > >
> > >
On Thu, 22 Sep 2016 02:33:01 +
"Tian, Kevin" wrote:
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Wednesday, September 21, 2016 12:37 PM
> >
> > On Wed, 21 Sep 2016 03:56:21 +
> > "Tian, Kevin" wrote:
> >
> > > > From: Kirti Wankhede [mailto:kwankh...@nvidia
> From: Tian, Kevin
> Sent: Thursday, September 22, 2016 10:33 AM
>
> >
> > > Another example is class-specific attributes such
> > > as 'resolution', etc. which you listed under 'display class'. All those
> > > attributes should be moved to mdev directory. Only class ID is
> > > required under ea
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Wednesday, September 21, 2016 12:43 PM
>
> On Wed, 21 Sep 2016 04:10:53 +
> "Tian, Kevin" wrote:
>
> > > From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> > > Sent: Wednesday, September 21, 2016 12:23 AM
> > >
> > >
> > >
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Wednesday, September 21, 2016 12:37 PM
>
> On Wed, 21 Sep 2016 03:56:21 +
> "Tian, Kevin" wrote:
>
> > > From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> > > Sent: Tuesday, September 20, 2016 10:22 PM
> > > >>
> > > >> '
On Thu, 22 Sep 2016 00:04:14 +0530
Kirti Wankhede wrote:
> On 9/20/2016 10:20 PM, Alex Williamson wrote:
> > On Tue, 20 Sep 2016 21:53:16 +0530
> > Kirti Wankhede wrote:
> >
> >> On 9/20/2016 8:13 PM, Alex Williamson wrote:
> >>> On Tue, 20 Sep 2016 19:51:58 +0530
> >>> Kirti Wankhede wrot
On 9/20/2016 10:20 PM, Alex Williamson wrote:
> On Tue, 20 Sep 2016 21:53:16 +0530
> Kirti Wankhede wrote:
>
>> On 9/20/2016 8:13 PM, Alex Williamson wrote:
>>> On Tue, 20 Sep 2016 19:51:58 +0530
>>> Kirti Wankhede wrote:
>>>
On 9/20/2016 3:06 AM, Alex Williamson wrote:
> On Tue,
On Tue, Sep 20, 2016 at 07:21:07PM +0200, Paolo Bonzini wrote:
>
>
> On 20/09/2016 17:14, Daniel P. Berrange wrote:
> > Any VM which
> > uses the separate namespace is tainted, which means if theres a bug
> > report we'll require the reported to remove whatever config caused
> > the tainting and
On Wed, 21 Sep 2016 04:10:53 +
"Tian, Kevin" wrote:
> > From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> > Sent: Wednesday, September 21, 2016 12:23 AM
> >
> >
> > On 9/20/2016 8:13 PM, Alex Williamson wrote:
> > > On Tue, 20 Sep 2016 19:51:58 +0530
> > > Kirti Wankhede wrote:
> > >
On Wed, 21 Sep 2016 03:56:21 +
"Tian, Kevin" wrote:
> > From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> > Sent: Tuesday, September 20, 2016 10:22 PM
> > >>
> > >> 'max_instance':
> > >> Read-Only file. Mandatory.
> > >> Returns integer. Returns maximum mdev device could be cre
> From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> Sent: Wednesday, September 21, 2016 12:23 AM
>
>
> On 9/20/2016 8:13 PM, Alex Williamson wrote:
> > On Tue, 20 Sep 2016 19:51:58 +0530
> > Kirti Wankhede wrote:
> >
> >> On 9/20/2016 3:06 AM, Alex Williamson wrote:
> >>> On Tue, 20 Sep 2016
> From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> Sent: Tuesday, September 20, 2016 10:22 PM
> >>
> >> 'max_instance':
> >> Read-Only file. Mandatory.
> >> Returns integer. Returns maximum mdev device could be created
> >> at the moment when this file is read. This count would be upda
On 20/09/2016 17:14, Daniel P. Berrange wrote:
> Any VM which
> uses the separate namespace is tainted, which means if theres a bug
> report we'll require the reported to remove whatever config caused
> the tainting and then reproduce the problem.
>
> If the vendor specific mdev parameters are t
On Tue, 20 Sep 2016 21:53:16 +0530
Kirti Wankhede wrote:
> On 9/20/2016 8:13 PM, Alex Williamson wrote:
> > On Tue, 20 Sep 2016 19:51:58 +0530
> > Kirti Wankhede wrote:
> >
> >> On 9/20/2016 3:06 AM, Alex Williamson wrote:
> >>> On Tue, 20 Sep 2016 02:05:52 +0530
> >>> Kirti Wankhede wrote
On Tue, Sep 20, 2016 at 10:01:18PM +0530, Kirti Wankhede wrote:
>
>
> On 9/20/2016 8:44 PM, Daniel P. Berrange wrote:
> > On Tue, Sep 20, 2016 at 05:05:43PM +0200, Paolo Bonzini wrote:
> >>
> >>
> >> On 20/09/2016 16:58, Daniel P. Berrange wrote:
> > As I've said in my earlier reply - libvirt
On Tue, Sep 20, 2016 at 10:12:20PM +0530, Kirti Wankhede wrote:
>
>
> On 9/20/2016 10:06 PM, Daniel P. Berrange wrote:
> > On Tue, Sep 20, 2016 at 10:01:18PM +0530, Kirti Wankhede wrote:
> >>
> >>
> >> On 9/20/2016 8:44 PM, Daniel P. Berrange wrote:
> >>> On Tue, Sep 20, 2016 at 05:05:43PM +0200,
On 9/20/2016 10:06 PM, Daniel P. Berrange wrote:
> On Tue, Sep 20, 2016 at 10:01:18PM +0530, Kirti Wankhede wrote:
>>
>>
>> On 9/20/2016 8:44 PM, Daniel P. Berrange wrote:
>>> On Tue, Sep 20, 2016 at 05:05:43PM +0200, Paolo Bonzini wrote:
On 20/09/2016 16:58, Daniel P. Berrange wro
On Tue, Sep 20, 2016 at 10:01:18PM +0530, Kirti Wankhede wrote:
>
>
> On 9/20/2016 8:44 PM, Daniel P. Berrange wrote:
> > On Tue, Sep 20, 2016 at 05:05:43PM +0200, Paolo Bonzini wrote:
> >>
> >>
> >> On 20/09/2016 16:58, Daniel P. Berrange wrote:
> > As I've said in my earlier reply - libvirt
On 9/20/2016 8:44 PM, Daniel P. Berrange wrote:
> On Tue, Sep 20, 2016 at 05:05:43PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 20/09/2016 16:58, Daniel P. Berrange wrote:
> As I've said in my earlier reply - libvirt will *NOT* support passing
> arbitrary vendor specific parameters as a blob
On 9/20/2016 8:13 PM, Alex Williamson wrote:
> On Tue, 20 Sep 2016 19:51:58 +0530
> Kirti Wankhede wrote:
>
>> On 9/20/2016 3:06 AM, Alex Williamson wrote:
>>> On Tue, 20 Sep 2016 02:05:52 +0530
>>> Kirti Wankhede wrote:
>>>
Hi libvirt experts,
'create':
Write-o
On Tue, Sep 20, 2016 at 08:05:01PM +0530, Kirti Wankhede wrote:
>
>
> On 9/20/2016 3:55 AM, Alex Williamson wrote:
> > On Mon, 19 Sep 2016 23:50:56 +0200
> > Paolo Bonzini wrote:
> >
> >> On 19/09/2016 23:36, Alex Williamson wrote:
> >>> On Tue, 20 Sep 2016 02:05:52 +0530
> >>> Kirti Wankhede
On Tue, Sep 20, 2016 at 04:49:09PM +0200, Paolo Bonzini wrote:
>
>
> On 20/09/2016 16:41, Daniel P. Berrange wrote:
> > As I've said in my earlier reply - libvirt will *NOT* support passing
> > arbitrary vendor specific parameters as a blob via the XML. Everything
> > that appears in the XML must
On Tue, Sep 20, 2016 at 05:05:43PM +0200, Paolo Bonzini wrote:
>
>
> On 20/09/2016 16:58, Daniel P. Berrange wrote:
> > > > As I've said in my earlier reply - libvirt will *NOT* support passing
> > > > arbitrary vendor specific parameters as a blob via the XML. Everything
> > > > that appears in
On 20/09/2016 16:41, Daniel P. Berrange wrote:
> As I've said in my earlier reply - libvirt will *NOT* support passing
> arbitrary vendor specific parameters as a blob via the XML. Everything
> that appears in the XML must be *fully* specified and explicitly
> represented in the XML as a distinc
On 20/09/2016 16:58, Daniel P. Berrange wrote:
> > > As I've said in my earlier reply - libvirt will *NOT* support passing
> > > arbitrary vendor specific parameters as a blob via the XML. Everything
> > > that appears in the XML must be *fully* specified and explicitly
> > > represented in the X
On 9/20/2016 3:06 AM, Alex Williamson wrote:
> On Tue, 20 Sep 2016 02:05:52 +0530
> Kirti Wankhede wrote:
>
>> Hi libvirt experts,
>>
>> Thanks for valuable input on v1 version of RFC.
>>
>> Quick brief, VFIO based mediated device framework provides a way to
>> virtualize their devices without
On 9/20/2016 3:55 AM, Alex Williamson wrote:
> On Mon, 19 Sep 2016 23:50:56 +0200
> Paolo Bonzini wrote:
>
>> On 19/09/2016 23:36, Alex Williamson wrote:
>>> On Tue, 20 Sep 2016 02:05:52 +0530
>>> Kirti Wankhede wrote:
'fb_length':
Read-only file. Mandatory.
Returns {K
On Tue, 20 Sep 2016 20:05:01 +0530
Kirti Wankhede wrote:
> On 9/20/2016 3:55 AM, Alex Williamson wrote:
> > On Mon, 19 Sep 2016 23:50:56 +0200
> > Paolo Bonzini wrote:
> >
> >> On 19/09/2016 23:36, Alex Williamson wrote:
> >>> On Tue, 20 Sep 2016 02:05:52 +0530
> >>> Kirti Wankhede wrote:
On Tue, 20 Sep 2016 19:51:58 +0530
Kirti Wankhede wrote:
> On 9/20/2016 3:06 AM, Alex Williamson wrote:
> > On Tue, 20 Sep 2016 02:05:52 +0530
> > Kirti Wankhede wrote:
> >
> >> Hi libvirt experts,
> >>
> >> Thanks for valuable input on v1 version of RFC.
> >>
> >> Quick brief, VFIO based med
On Tue, Sep 20, 2016 at 02:05:52AM +0530, Kirti Wankhede wrote:
>
> Hi libvirt experts,
>
> Thanks for valuable input on v1 version of RFC.
>
> Quick brief, VFIO based mediated device framework provides a way to
> virtualize their devices without SR-IOV, like NVIDIA vGPU, Intel KVMGT
> and IBM's
> From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> Sent: Tuesday, September 20, 2016 4:36 AM
>
>
> Hi libvirt experts,
>
> Thanks for valuable input on v1 version of RFC.
>
> Quick brief, VFIO based mediated device framework provides a way to
> virtualize their devices without SR-IOV, like
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Tuesday, September 20, 2016 5:36 AM
>
> > In the above example directory '11' represents a type id of mdev device.
> > 'name', 'fb_length', 'resolution', 'heads', 'max_instance' and
> > 'requires_group' would be Read-Only files th
On Mon, 19 Sep 2016 23:50:56 +0200
Paolo Bonzini wrote:
> On 19/09/2016 23:36, Alex Williamson wrote:
> > On Tue, 20 Sep 2016 02:05:52 +0530
> > Kirti Wankhede wrote:
> >> 'fb_length':
> >> Read-only file. Mandatory.
> >> Returns {K,M,G}, size of framebuffer.
> >
> > This can't be m
On 19/09/2016 23:36, Alex Williamson wrote:
> On Tue, 20 Sep 2016 02:05:52 +0530
> Kirti Wankhede wrote:
>> 'fb_length':
>> Read-only file. Mandatory.
>> Returns {K,M,G}, size of framebuffer.
>
> This can't be mandatory, it's only relevant to vGPU devices, vGPUs are
> just one user of m
On Tue, 20 Sep 2016 02:05:52 +0530
Kirti Wankhede wrote:
> Hi libvirt experts,
>
> Thanks for valuable input on v1 version of RFC.
>
> Quick brief, VFIO based mediated device framework provides a way to
> virtualize their devices without SR-IOV, like NVIDIA vGPU, Intel KVMGT
> and IBM's channel
Hi libvirt experts,
Thanks for valuable input on v1 version of RFC.
Quick brief, VFIO based mediated device framework provides a way to
virtualize their devices without SR-IOV, like NVIDIA vGPU, Intel KVMGT
and IBM's channel IO. This framework reuses VFIO APIs for all the
functionalities for med
50 matches
Mail list logo
