New "rme-guest" QEMU object addition

New "rme-guest" QEMU object addition

[Itaru Kitayama]

Hi Jean, Mathieu,

I’ve been using you guys’ ccs/v3 QEMU for some time to bring up an Realm instance without a major issue, and as a one who is making changes libvirt to support CCA, I wonder if you could merge the v3 local changes under qap dir first so I can query the feature from libvirt?

Thanks,
Itaru.

Re: New "rme-guest" QEMU object addition

[Daniel P. Berrangé]

On Thu, Nov 21, 2024 at 02:34:24PM +0900, Itaru Kitayama wrote:
> Hi Jean, Mathieu,
> 
> I’ve been using you guys’ ccs/v3 QEMU for some time to bring
> up an Realm instance without a major issue, and as a one who
> is making changes libvirt to support CCA, I wonder if you
> could merge the v3 local changes under qap dir first so I
> can query the feature from libvirt?

Is the CCA host kernel support merged yet ?  As a general rule we would
not expect to merge QEMU support for a feature, until after the corresponding
kernel support is merged.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: New "rme-guest" QEMU object addition

[Itaru Kitayama]

> On Nov 21, 2024, at 18:53, Daniel P. Berrangé <berrange@redhat.com> wrote:
> 
> On Thu, Nov 21, 2024 at 02:34:24PM +0900, Itaru Kitayama wrote:
>> Hi Jean, Mathieu,
>> 
>> I’ve been using you guys’ ccs/v3 QEMU for some time to bring
>> up an Realm instance without a major issue, and as a one who
>> is making changes libvirt to support CCA, I wonder if you
>> could merge the v3 local changes under qap dir first so I
>> can query the feature from libvirt?
> 
> Is the CCA host kernel support merged yet ?  As a general rule we would
> not expect to merge QEMU support for a feature, until after the corresponding
> kernel support is merged.
> 

Ah, only the guest part. So now I understand.

Thanks,
Itaru.

> With regards,
> Daniel
> -- 
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
> 

Re: New "rme-guest" QEMU object addition

[Daniel P. Berrangé]

On Thu, Nov 21, 2024 at 06:55:18PM +0900, Itaru Kitayama wrote:
> 
> 
> > On Nov 21, 2024, at 18:53, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > 
> > On Thu, Nov 21, 2024 at 02:34:24PM +0900, Itaru Kitayama wrote:
> >> Hi Jean, Mathieu,
> >> 
> >> I’ve been using you guys’ ccs/v3 QEMU for some time to bring
> >> up an Realm instance without a major issue, and as a one who
> >> is making changes libvirt to support CCA, I wonder if you
> >> could merge the v3 local changes under qap dir first so I
> >> can query the feature from libvirt?
> > 
> > Is the CCA host kernel support merged yet ?  As a general rule we would
> > not expect to merge QEMU support for a feature, until after the corresponding
> > kernel support is merged.
> > 
> 
> Ah, only the guest part. So now I understand.

You can still post PoC patches for libvirt based on the latest out of
tree QEMU code. We'll review them in the normal way, and then when the
kernel & QEMU stuff does merge, there'll be minimal further delay on
merging the libvirt side.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: New "rme-guest" QEMU object addition

[Itaru Kitayama]

Hi Daniel,

> On Nov 21, 2024, at 18:58, Daniel P. Berrangé <berrange@redhat.com> wrote:
> 
> On Thu, Nov 21, 2024 at 06:55:18PM +0900, Itaru Kitayama wrote:
>> 
>> 
>>> On Nov 21, 2024, at 18:53, Daniel P. Berrangé <berrange@redhat.com> wrote:
>>> 
>>> On Thu, Nov 21, 2024 at 02:34:24PM +0900, Itaru Kitayama wrote:
>>>> Hi Jean, Mathieu,
>>>> 
>>>> I’ve been using you guys’ ccs/v3 QEMU for some time to bring
>>>> up an Realm instance without a major issue, and as a one who
>>>> is making changes libvirt to support CCA, I wonder if you
>>>> could merge the v3 local changes under qap dir first so I
>>>> can query the feature from libvirt?
>>> 
>>> Is the CCA host kernel support merged yet ?  As a general rule we would
>>> not expect to merge QEMU support for a feature, until after the corresponding
>>> kernel support is merged.
>>> 
>> 
>> Ah, only the guest part. So now I understand.
> 
> You can still post PoC patches for libvirt based on the latest out of
> tree QEMU code. We'll review them in the normal way, and then when the
> kernel & QEMU stuff does merge, there'll be minimal further delay on
> merging the libvirt side.

Thanks. Noted. We’ll send a series when it’s ready probably based upon Linaro’s cca/v3 or the updated
version if available.

Thanks,
Itaru.  

> 
> With regards,
> Daniel
> -- 
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
> 

Re: New "rme-guest" QEMU object addition

[Jean-Philippe Brucker]

Hi Itaru,

On Thu, Nov 21, 2024 at 02:34:24PM +0900, Itaru Kitayama wrote:
> Hi Jean, Mathieu,
> 
> I’ve been using you guys’ ccs/v3 QEMU for some time to bring up an Realm instance without a major issue, and as a one who is making changes libvirt to support CCA, I wonder if you could merge the v3 local changes under qap dir first so I can query the feature from libvirt?

I'm not very familiar with libvirt, which changes are needed for query,
this one:
https://git.codelinaro.org/linaro/dcap/qemu/-/commit/250732e03bf0bd2e2a9058358707baf51d0193cb#68c067b8d3c460fb3331256759e405f48df64c73
?

The problem for upstreaming QEMU VMM patches is that the whole series
depends on the updated KVM API, so until that gets merged in Linux I can't
get the QEMU patches merged
https://git.codelinaro.org/linaro/dcap/qemu/-/commit/bb044aeb5bf888f193b1def0a4d03de2ff8389ac
https://lore.kernel.org/linux-arm-kernel/20241004152804.72508-1-steven.price@arm.com/
And without the KVM API we can't allow users to create a rme-guest object,
since it wouldn't be functional.

Thanks,
Jean

Re: New "rme-guest" QEMU object addition

[Itaru Kitayama]

Hi Jean,

> On Nov 21, 2024, at 19:00, Jean-Philippe Brucker <jean-philippe@linaro.org> wrote:
> 
> Hi Itaru,
> 
> On Thu, Nov 21, 2024 at 02:34:24PM +0900, Itaru Kitayama wrote:
>> Hi Jean, Mathieu,
>> 
>> I’ve been using you guys’ ccs/v3 QEMU for some time to bring up an Realm instance without a major issue, and as a one who is making changes libvirt to support CCA, I wonder if you could merge the v3 local changes under qap dir first so I can query the feature from libvirt?
> 
> I'm not very familiar with libvirt, which changes are needed for query,
> this one:
> https://git.codelinaro.org/linaro/dcap/qemu/-/commit/250732e03bf0bd2e2a9058358707baf51d0193cb#68c067b8d3c460fb3331256759e405f48df64c73
> ?

Yes, but I wasn’t aware of the Kim-rme,c code under the target/arm. I am trying to generate C code using the QAPI so that we can issue QMP command like other CoCo, SEV(-SNP) and SGX.
Is this the way forward for Arm CCA support I wonder?

For now the focus is on getting a reasonable output of `virsh domcapabilities —emulatorbin qemu-system-aarch64` and getting virsh edit can be finished without a complain if I added <launchSecurity/> and <cca/>
elements.
 
Thanks,
Itaru.

> 
> The problem for upstreaming QEMU VMM patches is that the whole series
> depends on the updated KVM API, so until that gets merged in Linux I can't
> get the QEMU patches merged
> https://git.codelinaro.org/linaro/dcap/qemu/-/commit/bb044aeb5bf888f193b1def0a4d03de2ff8389ac
> https://lore.kernel.org/linux-arm-kernel/20241004152804.72508-1-steven.price@arm.com/
> And without the KVM API we can't allow users to create a rme-guest object,
> since it wouldn't be functional.
> 
> Thanks,
> Jean