The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.
--- Begin Message ---
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
--- End Message ---
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
