|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] xen/arm64: Default ACPI support enabled
Hi, On 06/02/2023 20:30, Elliott Mitchell wrote: On Mon, Feb 06, 2023 at 05:07:50PM +0000, Julien Grall wrote:On 06/02/2023 16:09, Elliott Mitchell wrote:On Mon, Feb 06, 2023 at 10:38:32AM +0000, Julien Grall wrote:On 06/02/2023 07:29, Jan Beulich wrote:On 22.07.2020 19:43, Elliott Mitchell wrote:Unlike other unsupportted options, ACPI support is required to *boot* for a number of platforms. Users on these platforms are unable to use distribution builds and must rebuild from source to use Xen. Signed-off-by: Elliott Mitchell <ehem+xen@xxxxxxx>A general question first: How come this mail dates back to July 2020? I had almost missed it as "new".I can't even find the Elliott's email in my inbox so reply here. But this sounds like a rehash of [1].The date on Git patches is meant as an indicator for author date. Since this is a cherry-pick of a patch which was written >2 years ago `git format-patch` indicates when it was written. This IS how these systems work.Hmmm... I am a bit surprised to what you say. I have sent several patches in the past with an old author date and they always showed as the date sent in my inbox.Dunno, but it was straight out of `git format-patch`. I'm not using `git send-email` though (that requires a setup distinct from what I'm aiming for). That's probably why. >> Unlike other unsupportted options, ACPI support is required to *boot* >> for a number of platforms. Users on these platforms are unable to use >> distribution builds and must rebuild from source to use Xen. What platforms are you testing on? I know that this is working-ish on RPI4 and QEMU. But this will likely blow up on one of the server we support in OSSTest because we don't have proper support to hide SMMUs in dom0.I've been doing RPI4 w/EDK2. Which works for my purpose, the remaining trouble spot for my purpose is needing a final resolution of the EFIFB situation.I have had no feedback from the relevant person on EFIFB patch and I am not planning to purse the work in the near future.Okay, thanks for the news. Hopefully efifb on Xen support gets into kernels closer to the Linux HEAD. This is quite a bold statement... I can see this ACPI to overtake in server world where ACPI is sort of the de-facto default firmware table. However, in embedded this is probably going to be more mixed because Device-Tree is a lot simpler to use (think of safety certified environment). Might be an abomination, but would it work to find the string "IORT" and change it to "iort", "RTIO" or "IOXN" to prevent Dom0 from finding it?Unfortunately no because there IORT is used to describing mapping for the GICv3 ITS which is currently working when ACPI is enabled in Xen.The original advantage of Xen was paravirtualization. Might this be a case where it is better to have Domain 0 compensate and know the SMMU is unusable with current versions of Xen? I believe it would make more difficult to add support for Stage-1 SMMU in dom0. So this would be a short-sighted decision. This ends up turning into a question of what are the cases and which are more common? Case1: DT-only: Unchanged Case2: Switchable between DT and ACPI, w/o SMMU: Starts working with ACPI Case3: Switchable between DT and ACPI, w/SMMU: Unchanged, ACPI mode still doesn't work, but the failure is different. Case4: Concurrent DT and ACPI support, w/o SMMU: UnchangedSo Xen would start using ACPI rather than DT.I think we should default DT it until we have the ACPI support completed.Isn't this precisely what the proposed change does? Are you suggesting, if both DT and ACPI are present, prevent Dom0 from seeing ACPI? In the current model Xen and dom0 have to be using the same kind of firmware table. IOW if Xen is using the Device-Tree then dom0 has to. We never investigated whether it would be feasible for Dom0 to use ACPI but not Xen. If you're suggesting doing futher masking, perhaps only if SMMU is present? Even if we remove the dependencies on UNSUPPORTED, ACPI will still be in a unsupported state by Xen Project (at least until the missing feature are present). This means, if both Device-Tree and ACPI are present then we should boot using Device-Tree so the user is using a supported configuration. If they wish to use ACPI, then they will need to pass "acpi=on" on the Xen command line. Case5: Concurrent DT and ACPI support, w/SMMU: Breaks if Dom0 tries to use ACPI Case6: ACPI-only, w/o SMMU: Starts working out-of-box Case7: ACPI-only, w/SMMU: Unchanged (still broken)To clarify, this will boot but then start to break in very subtle way.Which suggests a need to provide warnings the situation is known to be broken. Right. If that's the decision, then this would need to be part of this patch (or a new one patch). From my experience warnings tend to be ignore/forgotten. So this could lead to poorer experience when issues are subbtle (think memory corruption).Ultimately this is more a decision for Xen Project management, than the technical side. Are things in shape where they can be rolled out?No. But as I wrote before, I don't believe the gap is very big.Is ACPI support important enough to need rolling out now? I'm unsure about the former, but the latter seems a distinct "yes" since ACPI appears to be the future.ACPI is indeed picking up the pace on Arm Server and platform where Windows on Arm is supported. But that should not only be the reason to remove UNSUPPORTED.Well good news is I'm not proposing removing the unsupported marking. I'm proposing to enable ACPI by default. I think it is reasonable to add more warnings at runtime of the setup not being supported. That's interesting because I haven't encountered that many ACPI-only platform outside of the server world.You are right that enabling ACPI by default will draw more users. But I also expect those users to be less familiar with Xen and therefore not very interested to fix bugs. So removing EXPERT/UNSUPPORTED is probably going to still make them unhappy as I don't think the help (including writing patch) for ACPI on Arm will change very much in the near future (from the community call I was under the impression you could not commit time for it).The average level of technical competence may be lower, but the larger pool of people should yield enough to get additional problems fixed. >So I am not convinced this is really making Xen in a better position right now.Right now the present situation is *actively* pushing people who want to use Xen on ACPI-only ARM boards away. But, honestly, I think you are blaming a bit too much EXPERT/UNSUPPORTED. Such issue would be really a problem with single contributor. For companies they usually care less and will pick whatever suit them (even it is behind a Kconfig). If virtualization is important for them, they are likely to instead opt for KVM, VMWare, Hyper-V, or Bhyve. Suppressing mindshare will destroy the future of Xen on ARM. Another bold statement? Anyway, I will wait for input from Bertand and Stefano. Cheers, -- Julien Grall
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |