On Mon, 8 Jan 2024, Alex Williamson wrote:
On Mon, 8 Jan 2024 23:32:04 +0530 (IST)
Vivek Kashyap wrote:
On Mon, 8 Jan 2024, Alex Williamson wrote:
On Mon, 8 Jan 2024 18:42:19 +0530 (IST)
Vivek Kashyap wrote:
...
As I've stated above, for libvirt we should consider only passing it via
On Mon, 8 Jan 2024 23:32:04 +0530 (IST)
Vivek Kashyap wrote:
> On Mon, 8 Jan 2024, Alex Williamson wrote:
>
> > On Mon, 8 Jan 2024 18:42:19 +0530 (IST)
> > Vivek Kashyap wrote:
> >
> >> ...
> As I've stated above, for libvirt we should consider only passing it via
> the 'secret' o
On Mon, 8 Jan 2024, Alex Williamson wrote:
On Mon, 8 Jan 2024 18:42:19 +0530 (IST)
Vivek Kashyap wrote:
...
As I've stated above, for libvirt we should consider only passing it via
the 'secret' object.
Sounds good. Will follow this up.
Alex - will you be working on the qemu update?
I
On Mon, 8 Jan 2024 18:42:19 +0530 (IST)
Vivek Kashyap wrote:
> ...
> >> As I've stated above, for libvirt we should consider only passing it via
> >> the 'secret' object.
>
> Sounds good. Will follow this up.
>
> Alex - will you be working on the qemu update?
I'm not the one driving a use c
...
As I've stated above, for libvirt we should consider only passing it via
the 'secret' object.
Sounds good. Will follow this up.
Alex - will you be working on the qemu update?
Forgot to add:
If you need a way to test it with a libvirt-started VM in the interim
until the qemu commandline
On Mon, Jan 08, 2024 at 12:44:01 +0100, Peter Krempa wrote:
> On Mon, Jan 08, 2024 at 17:05:45 +0530, Vivek Kashyap wrote:
> > >
> > > If there is even a slight expectation of confidentiality (IMO just
> > > calling it a 'secret' in documentation is enough to justify that
> > > expectation) it sho
On Mon, Jan 08, 2024 at 17:05:45 +0530, Vivek Kashyap wrote:
> >
> > If there is even a slight expectation of confidentiality (IMO just
> > calling it a 'secret' in documentation is enough to justify that
> > expectation) it should be treated as such.
> >
> > Thus qemu needs to add the possibilit
If there is even a slight expectation of confidentiality (IMO just
calling it a 'secret' in documentation is enough to justify that
expectation) it should be treated as such.
Thus qemu needs to add the possibility to pass it via the 'secret'
object, so that libvirt can pass it encrypted. On the
On Wed, Jan 03, 2024 at 22:42:41 +0530, Vivek Kashyap wrote:
>
>
> On Tue, 2 Jan 2024, Alex Williamson wrote:
>
> > On Tue, 2 Jan 2024 18:55:10 +0530
> > Vivek Kashyap wrote:
> >
> > > The VFIO PCI ABI has been extended to require userspace PF driver to set
> > > a VF token to a known value.
On Tue, 2 Jan 2024, Alex Williamson wrote:
On Tue, 2 Jan 2024 18:55:10 +0530
Vivek Kashyap wrote:
The VFIO PCI ABI has been extended to require userspace PF driver to set
a VF token to a known value. The VF drivers are then required to provide
this token to access the VF device. The vf-tok
On Tue, 2 Jan 2024 18:55:10 +0530
Vivek Kashyap wrote:
> The VFIO PCI ABI has been extended to require userspace PF driver to set
> a VF token to a known value. The VF drivers are then required to provide
> this token to access the VF device. The vf-token is set by the PF driver
> before VF dri
The VFIO PCI ABI has been extended to require userspace PF driver to set
a VF token to a known value. The VF drivers are then required to provide
this token to access the VF device. The vf-token is set by the PF driver
before VF drivers can access the device. The kernel provides no means to
retrie
12 matches
Mail list logo
