Re: REST service for libvirt to simplify SEV(ES) launch measurement

Some comments on the example protocol stuff On 2/23/22 1:38 PM, Dov Murik wrote: > +cc Tobin, James > > On 23/02/2022 19:28, Daniel P. Berrangé wrote: >> >> >> What could this look like from POV of an attestation server API, if >> we assume HTTPS REST service with a simple JSON payload .>> >> >>

Re: REST service for libvirt to simplify SEV(ES) launch measurement

On 2/24/22 7:26 AM, Daniel P. Berrangé wrote: > On Wed, Feb 23, 2022 at 03:33:22PM -0500, Tobin Feldman-Fitzthum wrote: >> >> >> On 2/23/22 1:38 PM, Dov Murik wrote: >>> +cc Tobin, James >>> >>> On 23/02/2022 19:28, Daniel P. Berrangé wrote: Extending management apps using libvirt to

Re: GSoC 2022 CI project idea proposal

On Fri, Feb 25, 2022 at 05:14:41PM +, Daniel P. Berrangé wrote: > On Fri, Feb 25, 2022 at 08:36:10AM -0800, Andrea Bolognani wrote: > > If you're trying to reproduce a CI failure locally so that you can > > debug it, or performing validation before posting patches, you don't > > want to spell

Re: GSoC 2022 CI project idea proposal

On Fri, Feb 25, 2022 at 08:36:10AM -0800, Andrea Bolognani wrote: > On Fri, Feb 25, 2022 at 02:09:13PM +, Daniel P. Berrangé wrote: > > I've never got on very well with the 'lcitool build' command as its > > a bit of a black box you don't have much control over. In its current > > impl, it

Re: GSoC 2022 CI project idea proposal

On Fri, Feb 25, 2022 at 02:09:13PM +, Daniel P. Berrangé wrote: > I've never got on very well with the 'lcitool build' command as its > a bit of a black box you don't have much control over. In its current > impl, it also means that lcitool has to know about build commands for > each project

[libvirt PATCH 1/5] nwfilter: stop using recursive mutex for IP learning

The virNWFilterLockIface method is only called from one place, the learnIPAddressThread method. This is the entry point for the learning thread on the interface in question. As such there is never any recursive locking on this mutex from the same thread. This appears to have been the case since

[libvirt PATCH 0/5] nwfilter: fix deadlock with binding create/delete

Historically the nwfilter driver didn't keep track of any instances of filters. When it needed to rebuild filters it called back to the virt drivers to ask them to re-create the filters for their VMs. This lead to some complex locking requirements where the virt driver needed to acquire locks on

[libvirt PATCH 5/5] nwfilter: make some gentech driver methods static

The virNWFilterTechDriverForName & virNWFilterUpdateInstantiateFilter methods are only used within the same source file, so don't need to be exported. Signed-off-by: Daniel P. Berrangé --- src/nwfilter/nwfilter_gentech_driver.c | 4 ++-- src/nwfilter/nwfilter_gentech_driver.h | 5 - 2 files

[libvirt PATCH 4/5] nwfilter: remove decl of virNWFilterCreateVarHashmap

This method doesn't exist since commit d1a7c08eb145d8b9d9c4a268f43b1590049a Author: Daniel P. Berrangé Date: Thu Apr 26 12:26:51 2018 +0100 nwfilter: convert the gentech driver code to use virNWFilterBindingDefPtr Signed-off-by: Daniel P. Berrangé ---

[libvirt PATCH 3/5] qemu,lxc: remove use to nwfilter update lock

Now that the virNWFilterBinding APIs are using the nwfilter update lock directly, there is no need for the virt drivers to do it themselves. Signed-off-by: Daniel P. Berrangé --- src/lxc/lxc_driver.c | 6 -- src/qemu/qemu_driver.c| 18 -- src/qemu/qemu_migration.c

[libvirt PATCH 2/5] nwfilter: hold filter update lock when creating/deleting bindings

The nwfilter update lock is historically acquired by the virt drivers in order to achieve serialization between nwfilter define/undefine, and instantiation/teardown of filters. When running in the modular daemons, however, the mutex that the virt drivers are locking is in a completely different

libvirt-8.1.0 release candidate 2

I have just tagged v8.1.0-rc2 in the repository and pushed signed tarballs and source RPMs to https://libvirt.org/sources/ Please give the release candidate some testing and in case you find a serious issue which should have a fix in the upcoming release, feel free to reply to this thread to make

Re: GSoC 2022 CI project idea proposal

On Fri, Feb 25, 2022 at 05:49:39AM -0800, Andrea Bolognani wrote: > On Fri, Feb 25, 2022 at 12:30:08PM +0100, Erik Skultety wrote: > > On Fri, Feb 25, 2022 at 03:02:49AM -0800, Andrea Bolognani wrote: > > > Do you have any high-level concerns about the ci/build approach I > > > vaguely described?

Re: GSoC 2022 CI project idea proposal

On Fri, Feb 25, 2022 at 05:49:39AM -0800, Andrea Bolognani wrote: > On Fri, Feb 25, 2022 at 12:30:08PM +0100, Erik Skultety wrote: > > On Fri, Feb 25, 2022 at 03:02:49AM -0800, Andrea Bolognani wrote: > > > Do you have any high-level concerns about the ci/build approach I > > > vaguely described?

Re: GSoC 2022 CI project idea proposal

On Fri, Feb 25, 2022 at 12:30:08PM +0100, Erik Skultety wrote: > On Fri, Feb 25, 2022 at 03:02:49AM -0800, Andrea Bolognani wrote: > > Do you have any high-level concerns about the ci/build approach I > > vaguely described? The finer details are of course far from being set > > in stone, but I

Re: [libvirt][PATCH RESEND v10 5/5] qemu: Add command-line to generate SGX EPC memory backend

On 2/24/22 21:19, Yang, Lin A wrote: > On 2/22/22, 1:19 AM, "Michal Prívozník" wrote: > >   > >> On 2/16/22 11:25, Michal Prívozník wrote: > >> > >> >> diff --git a/tests/qemuxml2argvdata/sgx-epc.x86_64-6.2.0.args >> >> b/tests/qemuxml2argvdata/sgx-epc.x86_64-6.2.0.args > >> >> new file

Re: GSoC 2022 introduction

On a Thursday in 2022, Moteen Shah wrote: Hello, This is Moteen Shah, Welcome, Moteen! Jano I have completed the build of the project and also read the contribution.html , I am still trying to figure out the issues I can work on, it would be really

Re: GSoC 2022 introduction

On 2/24/22 18:08, Moteen Shah wrote: > Hello,  > This is Moteen Shah,  > I have completed the build of the project and also read > the contribution.html ,  > I am still trying to figure out the issues I can work on, it would be > really helpful if you can give

Re: GSoC 2022 CI project idea proposal

On Fri, Feb 25, 2022 at 03:02:49AM -0800, Andrea Bolognani wrote: > On Fri, Feb 25, 2022 at 11:31:39AM +0100, Erik Skultety wrote: > > On Thu, Feb 24, 2022 at 06:49:29AM -0800, Andrea Bolognani wrote: > > > I'm not entirely convinced that requiring the use of lcitool for this > > > task is

Re: GSoC 2022 CI project idea proposal

On Fri, Feb 25, 2022 at 11:31:39AM +0100, Erik Skultety wrote: > On Thu, Feb 24, 2022 at 06:49:29AM -0800, Andrea Bolognani wrote: > > I'm not entirely convinced that requiring the use of lcitool for this > > task is necessarily the best idea though. Ideally, it should be > > possible for

Re: GSoC 2022 CI project idea proposal

On Thu, Feb 24, 2022 at 06:49:29AM -0800, Andrea Bolognani wrote: > On Tue, Feb 22, 2022 at 05:04:02PM +0100, Erik Skultety wrote: > > So, we're offloading as much CI configuration/workflow stuff to lcitool > > as possible. We can generate config files, install/update machines > > (local or