On Tue, Nov 17, 2020 at 04:44:52AM -0500, Michael S. Tsirkin wrote:
> On Mon, Nov 16, 2020 at 02:38:12PM +, Stefan Hajnoczi wrote:
> > On Wed, Nov 11, 2020 at 03:41:59PM +, Dr. David Alan Gilbert wrote:
> > > * Stefan Hajnoczi (stefa...@redhat.com) wrote:
> > > > On Wed, Nov 11, 2020 at 12:
* Stefan Hajnoczi (stefa...@redhat.com) wrote:
> On Wed, Nov 11, 2020 at 04:18:34PM +, Thanos Makatos wrote:
> >
> > > VFIO Migration
> > > ==
> > > This document describes how to ensure migration compatibility for VFIO
> > > devices,
> > > including mdev and vfio-user devices.
> >
* Alex Williamson (alex.william...@redhat.com) wrote:
> On Mon, 16 Nov 2020 14:52:26 +0100
> Cornelia Huck wrote:
>
> > On Mon, 16 Nov 2020 11:02:51 +
> > Stefan Hajnoczi wrote:
> >
> > > On Wed, Nov 11, 2020 at 04:35:43PM +0100, Cornelia Huck wrote:
> > > > On Wed, 11 Nov 2020 15:14:49 +
On Mon, Nov 16, 2020 at 02:38:12PM +, Stefan Hajnoczi wrote:
> On Wed, Nov 11, 2020 at 03:41:59PM +, Dr. David Alan Gilbert wrote:
> > * Stefan Hajnoczi (stefa...@redhat.com) wrote:
> > > On Wed, Nov 11, 2020 at 12:56:26PM +, Dr. David Alan Gilbert wrote:
> > > > * Stefan Hajnoczi (stef
On Mon, 16 Nov 2020 14:52:26 +0100
Cornelia Huck wrote:
> On Mon, 16 Nov 2020 11:02:51 +
> Stefan Hajnoczi wrote:
>
> > On Wed, Nov 11, 2020 at 04:35:43PM +0100, Cornelia Huck wrote:
> > > On Wed, 11 Nov 2020 15:14:49 +
> > > Stefan Hajnoczi wrote:
> > >
> > > > On Wed, Nov 11,
On Wed, Nov 11, 2020 at 04:18:34PM +, Thanos Makatos wrote:
>
> > VFIO Migration
> > ==
> > This document describes how to ensure migration compatibility for VFIO
> > devices,
> > including mdev and vfio-user devices.
>
> Is this something all VFIO/user devices will have to suppor
On Wed, Nov 11, 2020 at 03:41:59PM +, Dr. David Alan Gilbert wrote:
> * Stefan Hajnoczi (stefa...@redhat.com) wrote:
> > On Wed, Nov 11, 2020 at 12:56:26PM +, Dr. David Alan Gilbert wrote:
> > > * Stefan Hajnoczi (stefa...@redhat.com) wrote:
> > > > Orchestrating Migrations
> > > >
On Mon, 16 Nov 2020 11:02:51 +
Stefan Hajnoczi wrote:
> On Wed, Nov 11, 2020 at 04:35:43PM +0100, Cornelia Huck wrote:
> > On Wed, 11 Nov 2020 15:14:49 +
> > Stefan Hajnoczi wrote:
> >
> > > On Wed, Nov 11, 2020 at 12:48:53PM +0100, Cornelia Huck wrote:
> > > > On Tue, 10 Nov 2020 1
On Mon, Nov 16, 2020 at 01:48:58PM +0100, Gerd Hoffmann wrote:
> > > In validating QEMU migration compatibility we merely compare the
> > > versioned machine type.
> >
> > Thinking more about this, maybe the big picture is:
> >
> > Today the managment tool controls the variables in the migration
On Mon, Nov 16, 2020 at 12:45:49PM +, Daniel P. Berrangé wrote:
> > This won't work for devices: same device needs to work with
> > both upstream and Red Hat and migrate upstream-upstream and Red Hat-Red Hat
> > (though not upstream-Red Hat).
>
> That's fine, we can cope with that. It simply
> > In validating QEMU migration compatibility we merely compare the
> > versioned machine type.
>
> Thinking more about this, maybe the big picture is:
>
> Today the managment tool controls the variables in the migration (the
> device configuration). It has knowledge of the VMM, can set a machin
On Mon, Nov 16, 2020 at 07:34:25AM -0500, Michael S. Tsirkin wrote:
> On Mon, Nov 16, 2020 at 12:05:18PM +, Daniel P. Berrangé wrote:
> > On Mon, Nov 16, 2020 at 07:03:03AM -0500, Michael S. Tsirkin wrote:
> > > On Mon, Nov 16, 2020 at 11:41:25AM +, Daniel P. Berrangé wrote:
> > > > > I
On Mon, Nov 16, 2020 at 12:05:18PM +, Daniel P. Berrangé wrote:
> On Mon, Nov 16, 2020 at 07:03:03AM -0500, Michael S. Tsirkin wrote:
> > On Mon, Nov 16, 2020 at 11:41:25AM +, Daniel P. Berrangé wrote:
> > > > It is possible to simplify the problem, but we'll lose freedom. For
> > > > e
On Mon, Nov 16, 2020 at 11:41:25AM +, Daniel P. Berrangé wrote:
> > It is possible to simplify the problem, but we'll lose freedom. For
> > example, hard coding knowledge of the device implementation into the
> > management tool eliminates the need for a general migration checking
> > algorith
On Wed, Nov 11, 2020 at 03:48:50PM +, Daniel P. Berrangé wrote:
> In terms of validation I can't help but feel the whole proposal is
> really very complicated.
>
> In validating QEMU migration compatibility we merely compare the
> versioned machine type.
>
> IIUC, in this proposal, it would
On Mon, Nov 16, 2020 at 07:03:03AM -0500, Michael S. Tsirkin wrote:
> On Mon, Nov 16, 2020 at 11:41:25AM +, Daniel P. Berrangé wrote:
> > > It is possible to simplify the problem, but we'll lose freedom. For
> > > example, hard coding knowledge of the device implementation into the
> > > manag
On Mon, Nov 16, 2020 at 11:15:24AM +, Stefan Hajnoczi wrote:
> On Wed, Nov 11, 2020 at 03:48:50PM +, Daniel P. Berrangé wrote:
> > On Wed, Nov 11, 2020 at 02:36:15PM +, Stefan Hajnoczi wrote:
> > > On Tue, Nov 10, 2020 at 12:12:31PM +0100, Paolo Bonzini wrote:
> > > > On 10/11/20 10:53,
On Wed, Nov 11, 2020 at 04:28:10PM +0100, Cornelia Huck wrote:
> On Wed, 11 Nov 2020 15:10:14 +
> Stefan Hajnoczi wrote:
> > On Tue, Nov 10, 2020 at 01:14:04PM -0700, Alex Williamson wrote:
> > > On Tue, 10 Nov 2020 09:53:49 +
> > > Stefan Hajnoczi wrote:
> > Or we could create a kobject
On Wed, Nov 11, 2020 at 03:48:50PM +, Daniel P. Berrangé wrote:
> On Wed, Nov 11, 2020 at 02:36:15PM +, Stefan Hajnoczi wrote:
> > On Tue, Nov 10, 2020 at 12:12:31PM +0100, Paolo Bonzini wrote:
> > > On 10/11/20 10:53, Stefan Hajnoczi wrote:
> > Yes, the current syntax supports sparse range
On Wed, Nov 11, 2020 at 04:35:43PM +0100, Cornelia Huck wrote:
> On Wed, 11 Nov 2020 15:14:49 +
> Stefan Hajnoczi wrote:
>
> > On Wed, Nov 11, 2020 at 12:48:53PM +0100, Cornelia Huck wrote:
> > > On Tue, 10 Nov 2020 13:14:04 -0700
> > > Alex Williamson wrote:
> > > > On Tue, 10 Nov 2020 09
On Wed, Nov 11, 2020 at 03:48:50PM +, Daniel P. Berrangé wrote:
> On Wed, Nov 11, 2020 at 02:36:15PM +, Stefan Hajnoczi wrote:
> > On Tue, Nov 10, 2020 at 12:12:31PM +0100, Paolo Bonzini wrote:
> > > On 10/11/20 10:53, Stefan Hajnoczi wrote:
> In terms of validation I can't help but feel th
On Wed, 11 Nov 2020 15:48:50 +
Daniel P. Berrangé wrote:
> In terms of validation I can't help but feel the whole proposal is
> really very complicated.
>
> In validating QEMU migration compatibility we merely compare the
> versioned machine type.
>
> IIUC, in this proposal, it would be mor
> VFIO Migration
> ==
> This document describes how to ensure migration compatibility for VFIO
> devices,
> including mdev and vfio-user devices.
Is this something all VFIO/user devices will have to support? If it's not
mandatory, how can a device advertise support?
> Multiple devic
On Wed, Nov 11, 2020 at 02:36:15PM +, Stefan Hajnoczi wrote:
> On Tue, Nov 10, 2020 at 12:12:31PM +0100, Paolo Bonzini wrote:
> > On 10/11/20 10:53, Stefan Hajnoczi wrote:
> > > "allowed_values"
> > >The list all values that the device implementation accepts for this
> > > migration
> > >
* Stefan Hajnoczi (stefa...@redhat.com) wrote:
> On Wed, Nov 11, 2020 at 12:56:26PM +, Dr. David Alan Gilbert wrote:
> > * Stefan Hajnoczi (stefa...@redhat.com) wrote:
> > > Orchestrating Migrations
> > >
> > > In order to migrate a device a *migration parameter list* m
On Wed, 11 Nov 2020 15:14:49 +
Stefan Hajnoczi wrote:
> On Wed, Nov 11, 2020 at 12:48:53PM +0100, Cornelia Huck wrote:
> > On Tue, 10 Nov 2020 13:14:04 -0700
> > Alex Williamson wrote:
> > > On Tue, 10 Nov 2020 09:53:49 +
> > > Stefan Hajnoczi wrote:
> >
> > > > Device models sup
On Wed, Nov 11, 2020 at 12:19:18PM +0100, Cornelia Huck wrote:
> On Tue, 10 Nov 2020 09:53:49 +
> Stefan Hajnoczi wrote:
>
> (...)
>
> > The meaning of the migration parameter and its possible values are specific
> > to
> > the device, but values are based on one of the following types:
> >
On Wed, Nov 11, 2020 at 12:56:26PM +, Dr. David Alan Gilbert wrote:
> * Stefan Hajnoczi (stefa...@redhat.com) wrote:
> > Orchestrating Migrations
> >
> > In order to migrate a device a *migration parameter list* must first be
> > built
> > on the source. Each migration
On Wed, 11 Nov 2020 15:10:14 +
Stefan Hajnoczi wrote:
> On Tue, Nov 10, 2020 at 01:14:04PM -0700, Alex Williamson wrote:
> > On Tue, 10 Nov 2020 09:53:49 +
> > Stefan Hajnoczi wrote:
> > Documentation/filesystems/sysfs.rst:
> > ---
> > Attributes
> > ~~
> >
> > Attributes can be
On Wed, Nov 11, 2020 at 12:48:53PM +0100, Cornelia Huck wrote:
> On Tue, 10 Nov 2020 13:14:04 -0700
> Alex Williamson wrote:
> > On Tue, 10 Nov 2020 09:53:49 +
> > Stefan Hajnoczi wrote:
>
> > > Device models supported by an mdev driver and their details can be read
> > > from
> > > the mig
On Tue, Nov 10, 2020 at 01:14:04PM -0700, Alex Williamson wrote:
> On Tue, 10 Nov 2020 09:53:49 +
> Stefan Hajnoczi wrote:
> Documentation/filesystems/sysfs.rst:
> ---
> Attributes
> ~~
>
> Attributes can be exported for kobjects in the form of regular files in
> the filesystem. Sysfs
On Tue, Nov 10, 2020 at 12:12:31PM +0100, Paolo Bonzini wrote:
> On 10/11/20 10:53, Stefan Hajnoczi wrote:
> > "allowed_values"
> >The list all values that the device implementation accepts for this
> > migration
> >parameter. Integer ranges can be described using "-" strings.
> >
> >
* Stefan Hajnoczi (stefa...@redhat.com) wrote:
> v3:
> * Introduce migration info JSON to describe migration parameters
> * Rework mdev sysfs interface
> * Propose standard interface for vfio-user device emulation programs
>
> VFIO Migration
> ==
> This document describes how to ens
On Tue, 10 Nov 2020 13:14:04 -0700
Alex Williamson wrote:
> On Tue, 10 Nov 2020 09:53:49 +
> Stefan Hajnoczi wrote:
> > Device models supported by an mdev driver and their details can be read from
> > the migration_info.json attr. Each mdev type supports one device model. If a
> > parent de
On Tue, 10 Nov 2020 09:53:49 +
Stefan Hajnoczi wrote:
(...)
> The meaning of the migration parameter and its possible values are specific to
> the device, but values are based on one of the following types:
> * bool - booleans (on/off)
> * int - integers (0, 1, 2, ...)
> * str - character st
On Tue, 10 Nov 2020 09:53:49 +
Stefan Hajnoczi wrote:
> VFIO mdev Drivers
> -
> The following mdev type sysfs attrs are available for managing device
> instances::
>
> /sys/...//mdev_supported_types//
> create - writing a UUID to this file instantiates a device
> mig
On 10/11/20 10:53, Stefan Hajnoczi wrote:
"allowed_values"
The list all values that the device implementation accepts for this migration
parameter. Integer ranges can be described using "-" strings.
Examples: ['a', 'b', 'c'], [1, 5, 7], ['0-255', 512, '1024-2048'], [true]
This membe
v3:
* Introduce migration info JSON to describe migration parameters
* Rework mdev sysfs interface
* Propose standard interface for vfio-user device emulation programs
VFIO Migration
==
This document describes how to ensure migration compatibility for VFIO devices,
including mdev an
38 matches
Mail list logo
