| Message ID | 20250212112958.38023-1-philmd@linaro.org (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | meson: Display summary of Darwin libraries detected | expand |
On Wed, Feb 12, 2025 at 12:29:58PM +0100, Philippe Mathieu-Daudé wrote: > Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> > --- > meson.build | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/meson.build b/meson.build > index 18cf9e2913b..10f4c9fd30d 100644 > --- a/meson.build > +++ b/meson.build > @@ -4826,6 +4826,13 @@ summary_info += {'libdw': libdw} > if host_os == 'freebsd' > summary_info += {'libinotify-kqueue': inotify} > endif > +if host_os == 'darwin' > + summary_info += {'Hypervisor support': hvf} > + summary_info += {'CoreFoundation support': coref} > + summary_info += {'IOKit support': iokit} > + summary_info += {'ParavirtualizedGraphics support': pvg} > + summary_info += {'Metal support': metal} These last 4 make sense, but I believe we already report HVF earlier in the accelerators block: summary_info += {'KVM support': config_all_accel.has_key('CONFIG_KVM')} summary_info += {'HVF support': config_all_accel.has_key('CONFIG_HVF')} summary_info += {'WHPX support': config_all_accel.has_key('CONFIG_WHPX')} summary_info += {'NVMM support': config_all_accel.has_key('CONFIG_NVMM')} summary_info += {'Xen support': xen.found()} IIUC CONFIG_HVF is present if 'hvf.found()' With regards, Daniel
On 2/12/25 12:29, Philippe Mathieu-Daudé wrote: > Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> > --- > meson.build | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/meson.build b/meson.build > index 18cf9e2913b..10f4c9fd30d 100644 > --- a/meson.build > +++ b/meson.build > @@ -4826,6 +4826,13 @@ summary_info += {'libdw': libdw} > if host_os == 'freebsd' > summary_info += {'libinotify-kqueue': inotify} > endif > +if host_os == 'darwin' > + summary_info += {'Hypervisor support': hvf} > + summary_info += {'CoreFoundation support': coref} > + summary_info += {'IOKit support': iokit} > + summary_info += {'ParavirtualizedGraphics support': pvg} > + summary_info += {'Metal support': metal} > +endif I think all of these are going to be present anyway, because they're mandatory (except IOKit which _is_ going to be there, and HVF which is present elsewhere) and there's no version indication for Apple frameworks. However, adding pvg and metal here makes sense if: - "config PVG" is added to Kconfig.host with the corresponding assignment to host_kconfig - "depends on PVG" is added to "config MAC_PVG" - after which, host_os = "darwin" is not needed anymore in hw/display/meson.build Also, it's not clear to me if PVG can also work with TCG, and therefore the MMIO version can be used on x86 Macs? If so the 'if cpu = "aarch64"' in hw/display/meson.build seems wrong. Either way, the Kconfig file does not need "depends on AARCH64" and it should have just depends on MAC_PVG with an "imply" somewhere in hw/arm/Kconfig. Paolo
On Mon, 17 Feb 2025 at 19:37, Paolo Bonzini <pbonzini@redhat.com> wrote: > On 2/12/25 12:29, Philippe Mathieu-Daudé wrote: > > Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> > > --- > > meson.build | 7 +++++++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/meson.build b/meson.build > > index 18cf9e2913b..10f4c9fd30d 100644 > > --- a/meson.build > > +++ b/meson.build > > @@ -4826,6 +4826,13 @@ summary_info += {'libdw': libdw} > > if host_os == 'freebsd' > > summary_info += {'libinotify-kqueue': inotify} > > endif > > +if host_os == 'darwin' > > + summary_info += {'Hypervisor support': hvf} > > + summary_info += {'CoreFoundation support': coref} > > + summary_info += {'IOKit support': iokit} > > + summary_info += {'ParavirtualizedGraphics support': pvg} > > + summary_info += {'Metal support': metal} > > +endif > I think all of these are going to be present anyway, because they're > mandatory (except IOKit which _is_ going to be there, and HVF which is > present elsewhere) and there's no version indication for Apple frameworks. Realistically, all of these are always present on supported Darwin versions. > However, adding pvg and metal here makes sense if: > > - "config PVG" is added to Kconfig.host with the corresponding > assignment to host_kconfig > > - "depends on PVG" is added to "config MAC_PVG" > > - after which, host_os = "darwin" is not needed anymore in > hw/display/meson.build > > Also, it's not clear to me if PVG can also work with TCG, and therefore > the MMIO version can be used on x86 Macs? If so the 'if cpu = > "aarch64"' in hw/display/meson.build seems wrong. This bit I can answer. PVG is not in any way tied to HVF and so can be used with TCG. HOWEVER It is not cross-architecture. So, the PVG guest drivers with x86-64 macOS don't give useful results with the aarch64 macOS host PVG framework. (I suspect a mismatch in texture memory layout and perhaps some other data format issues - Apple's GPUs use a "swizzled" memory layout, whereas Intel/AMD/NVIDIA's do not.) Additionally, the MMIO variant in particular uses the IOSurfaceMapper APIs (PGIOSurfaceHostDevice, PGIOSurfaceHostDeviceDescriptor, usingIOSurfaceMapper) which are only present in the aarch64 version of the host ParavirtualizedGraphics.framework. In summary, hw/display/apple-gfx-mmio.m has a hard dependency on aarch64 *host* systems, and both apple-gfx device variants only make sense when host arch matches guest arch. (Unless you're a developer attempting to find a workaround to the incompatibility.) I'm very much not a Meson expert, so this was my best attempt at encoding these facts in the build system. (And nobody suggested anything better during review.) > Either way, the Kconfig file does not need "depends on AARCH64" and it > should have just > > depends on MAC_PVG > > with an "imply" somewhere in hw/arm/Kconfig. > > Paolo > > Phil
On Tue, Feb 18, 2025 at 3:55 PM Phil Dennis-Jordan <phil@philjordan.eu> wrote: > It is not cross-architecture. So, the PVG guest drivers with x86-64 macOS don't > give useful results with the aarch64 macOS host PVG framework. (I suspect a > mismatch in texture memory layout and perhaps some other data format issues > Apple's GPUs use a "swizzled" memory layout, whereas Intel/AMD/NVIDIA's do not.) Thanks, that helps. > In summary, hw/display/apple-gfx-mmio.m has a hard dependency on aarch64 *host* > systems, and both apple-gfx device variants only make sense when host arch matches > guest arch. (Unless you're a developer attempting to find a workaround to the > incompatibility.) I'm very much not a Meson expert, so this was my best attempt at > encoding these facts in the build system. (And nobody suggested anything better during > review.) I'll find a way to do that, thanks. I also would prefer to add --enable/--disable-pvg; I can take care of that, but I just need to know... >> Either way, the Kconfig file does not need "depends on AARCH64" and it >> should have just >> >> depends on MAC_PVG >> >> with an "imply" somewhere in hw/arm/Kconfig. ... which boards should enable MAC_PVG_MMIO? Is it only VIRT, or something else? Paolo
On Wed, 19 Feb 2025 at 11:28, Paolo Bonzini <pbonzini@redhat.com> wrote: > On Tue, Feb 18, 2025 at 3:55 PM Phil Dennis-Jordan <phil@philjordan.eu> > wrote: > > It is not cross-architecture. So, the PVG guest drivers with x86-64 > macOS don't > > give useful results with the aarch64 macOS host PVG framework. (I > suspect a > > mismatch in texture memory layout and perhaps some other data format > issues > > Apple's GPUs use a "swizzled" memory layout, whereas Intel/AMD/NVIDIA's > do not.) > > Thanks, that helps. > > > In summary, hw/display/apple-gfx-mmio.m has a hard dependency on aarch64 > *host* > > systems, and both apple-gfx device variants only make sense when host > arch matches > > guest arch. (Unless you're a developer attempting to find a workaround > to the > > incompatibility.) I'm very much not a Meson expert, so this was my best > attempt at > > encoding these facts in the build system. (And nobody suggested anything > better during > > review.) > > I'll find a way to do that, thanks. I also would prefer to add > --enable/--disable-pvg; I > can take care of that, but I just need to know... >> Either way, the Kconfig file does not need "depends on AARCH64" and it > >> should have just > >> > >> depends on MAC_PVG > >> > >> with an "imply" somewhere in hw/arm/Kconfig. > > ... which boards should enable MAC_PVG_MMIO? Is it only VIRT, or something > else? I doubt anyone will be able to use it productively with virt, but I am regularly surprised by people's creativity. The intended target machine is vmapple, which is the only known way to run aarch64 macOS guests. The PVG patches were part of that series, the PCI variant is useful independently of it though; Philippe said at one point early Jan/late Dec he was going to merge the rest of the patch series containing that machine type, but there were some question marks about the software GICv3 dependency and HVF I believe. I'll try to rebase that series and re-post it in the next few days - I've been too busy with another project to stay on top of chasing that down, but I'd really like to get it done for 10.0. Phil
On Wed, Feb 19, 2025 at 11:36 AM Phil Dennis-Jordan <phil@philjordan.eu> wrote: >> ... which boards should enable MAC_PVG_MMIO? Is it only VIRT, or something >> else? > > I doubt anyone will be able to use it productively with virt, but I am regularly surprised by people's creativity. Ah okay, so for now it's effectively dead code. > The intended target machine is vmapple, which is the only known way > to run aarch64 macOS guests. [...] > I'll try to rebase that series and re-post it in the next few days Thanks, I'll keep an eye on that. Paolo
On 19/2/25 11:38, Paolo Bonzini wrote: > On Wed, Feb 19, 2025 at 11:36 AM Phil Dennis-Jordan <phil@philjordan.eu> wrote: >>> ... which boards should enable MAC_PVG_MMIO? Is it only VIRT, or something >>> else? >> >> I doubt anyone will be able to use it productively with virt, but I am regularly surprised by people's creativity. > > Ah okay, so for now it's effectively dead code. Correct (still tested before merging). I have Phil's vmapple series queued but it fails the '--disable-hvf' build config so I had to drop it before sending the PR. I kept the PVG device to save Phil from respining again and again the same patches, hoping for a quick fix to merge the rest, waiting for an update on whether Phil's suggestion to fix the GIC dependency was OK or not, but no update so far, see: https://lore.kernel.org/qemu-devel/CAAibmn0puNwDvHcU8xYi1EJ=dnAEhasoTKCk0kmF4DiQfR7dHQ@mail.gmail.com/ and my proposal: https://lore.kernel.org/qemu-devel/20241227202435.48055-1-philmd@linaro.org/ And now I see Phil's reply which I missed ...: https://lore.kernel.org/qemu-devel/CAAibmn1g6+btdRX99ZUvbaBm7hP_AnAGNfDHz4Wgi3fPn=waOw@mail.gmail.com/ > >> The intended target machine is vmapple, which is the only known way >> to run aarch64 macOS guests. [...] >> I'll try to rebase that series and re-post it in the next few days > > Thanks, I'll keep an eye on that. > > Paolo >
diff --git a/meson.build b/meson.build index 18cf9e2913b..10f4c9fd30d 100644 --- a/meson.build +++ b/meson.build @@ -4826,6 +4826,13 @@ summary_info += {'libdw': libdw} if host_os == 'freebsd' summary_info += {'libinotify-kqueue': inotify} endif +if host_os == 'darwin' + summary_info += {'Hypervisor support': hvf} + summary_info += {'CoreFoundation support': coref} + summary_info += {'IOKit support': iokit} + summary_info += {'ParavirtualizedGraphics support': pvg} + summary_info += {'Metal support': metal} +endif summary(summary_info, bool_yn: true, section: 'Dependencies') if host_arch == 'unknown'
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> --- meson.build | 7 +++++++ 1 file changed, 7 insertions(+)