[PATCH 1/1] kernel/x86: merge "generic" into "legacy"

Stefan Lippers-Hollmann s.l-h at gmx.de
Thu Jan 4 16:16:00 PST 2024


Hi

On 2024-01-03, Elliott Mitchell wrote:
> On Tue, Jan 02, 2024 at 04:44:04PM -0800, Elliott Mitchell wrote:
[…]
> > --- a/target/linux/x86/legacy/config-6.1
> > +++ b/target/linux/x86/legacy/config-6.1
>
> > @@ -92,35 +113,91 @@ CONFIG_DRM_RADEON=y
> >  CONFIG_DRM_SCHED=y
> >  CONFIG_DRM_TTM=y
> >  CONFIG_DRM_TTM_HELPER=y
> > +CONFIG_DRM_VIRTIO_GPU=y
> >  CONFIG_DRM_VRAM_HELPER=y
> > +CONFIG_EFI=y
> > +CONFIG_EFIVAR_FS=m
>
> I'm unsure about this.  I don't know whether any P4s actually had EFI
> firmware.  According to the handy resource, initial versions of EFI were
> out by 2004 so some P4s might have had EFI.  I never touched them due to
> their terrible characteristics so I don't actually know.

Second generation Atom had 64 bit capable CPUs, but often a 32-bit
UEFI, given that our x86_64 images only ship with 64 bit UEFI
support, using an i386 image with 32 bit UEFI might be necessary for
those (it's not ideal, of course).

> > @@ -154,15 +237,38 @@ CONFIG_ISA_BUS_API=y
> >  CONFIG_ISO9660_FS=y
> >  # CONFIG_JOLIET is not set
> >  CONFIG_KCMP=y
> > +CONFIG_KVM=y
> > +CONFIG_KVM_AMD=y
> > +CONFIG_KVM_ASYNC_PF=y
> > +CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT=y
> > +CONFIG_KVM_GUEST=y
> > +CONFIG_KVM_INTEL=y
> > +CONFIG_KVM_MMIO=y
> > +CONFIG_KVM_VFIO=y
> > +# CONFIG_KVM_XEN is not set
> > +CONFIG_KVM_XFER_TO_GUEST_WORK=y
>
> Apparently it is genuinely possible to use KVM on some non-amd64 x86
> processors.

Core (1) solo was 32 bit only, but kvm capable. This weird
combination only lasted a short time, but it exists (but I seem
to remember that qemu might have dropped support for kvm on i386
hosts rather recently)…

[…]
> > +CONFIG_PHYS_ADDR_T_64BIT=y
> > +CONFIG_PINCTRL=y
> > +CONFIG_PINCTRL_ALDERLAKE=y
> > +CONFIG_PINCTRL_BAYTRAIL=y
> > +CONFIG_PINCTRL_BROXTON=y
> > +CONFIG_PINCTRL_CANNONLAKE=y
> > +CONFIG_PINCTRL_CHERRYVIEW=y
> > +CONFIG_PINCTRL_DENVERTON=y
> > +CONFIG_PINCTRL_ELKHARTLAKE=y
> > +CONFIG_PINCTRL_EMMITSBURG=y
> > +CONFIG_PINCTRL_GEMINILAKE=y
> > +CONFIG_PINCTRL_INTEL=y
> > +CONFIG_PINCTRL_JASPERLAKE=y
> > +CONFIG_PINCTRL_LAKEFIELD=y
> > +CONFIG_PINCTRL_LEWISBURG=y
> > +CONFIG_PINCTRL_LYNXPOINT=y
> > +CONFIG_PINCTRL_METEORLAKE=y
> > +CONFIG_PINCTRL_SUNRISEPOINT=y
> > +CONFIG_PINCTRL_TIGERLAKE=y
>
> Yes, CONFIG_X86_INTEL_LPSS=y made its way into "generic" and thus it got
> here.  I'm unaware of any of these ever being paired with a non-amd64
> processor.  This seems wrong, but that is what was in "generic".

These are all x86_64.

[…]
> > +CONFIG_VIRTIO=y
> > +CONFIG_VIRTIO_BALLOON=y
> > +CONFIG_VIRTIO_BLK=y
> > +CONFIG_VIRTIO_CONSOLE=y
> > +CONFIG_VIRTIO_DMA_SHARED_BUFFER=y
> > +CONFIG_VIRTIO_INPUT=y
> > +CONFIG_VIRTIO_MMIO=y
> > +CONFIG_VIRTIO_NET=y
> > +CONFIG_VIRTIO_PCI=y
> > +CONFIG_VIRTIO_PCI_LEGACY=y
> > +CONFIG_VIRTIO_PCI_LIB=y
> > +# CONFIG_VIRTIO_PMEM is not set
> > +CONFIG_VIRTUALIZATION=y
>
> Rather less commonly used for "legacy"-class machines, but it was
> genuinely available.

Running an i386 VM on x86_64 hosts is not uncommon, these are for the
emulated hardware in a VM, not (necessarily) the host.

> > +CONFIG_XEN=y
[…]
>
> Xen got started on this class of machine.  At the time 4GB of memory
> would have been a $20K+ computer, but these did exist.  Anything "legacy"
> *can* use Xen, though I'm doubtful very many people will continue to use
> it on this type of hardware.

Some of those are in the same boat as kvm/ virtio drivers, necessary
inside the VM, but I'm not a specialist on XEN (and XEN underwent
massive architectural changes to be accepted mainline, making the
details even more complex).

Regards
	Stefan Lippers-Hollmann



More information about the openwrt-devel mailing list