On 24/12/2014 13:41, Michael S. Tsirkin wrote: >> I don't think these are necessary, and I thought these were just RFC >> when they were posted. I and mst didn't really understand each other, >> and I take the fault for not reviewing the submission; however, Peter, >> please hold these for a little more. >> >> Paolo > > Yes, please do, I'd like Paolo to review at least the memory core > changes.
I don't have any issue with the implementation; I'm just not sure that this is necessary. My point is that until ACPI tables are actually trimmed, migration really won't be broken. So there is no need to apply these patches until/unless we are ready to trim the tables. Worst case, some scenarios can now print the "migration may not work" warning if ACPI tables go from <64k to >64k. But migration actually will work until the tables shoot beyond >128k. The warning sucks, and the workaround we have (round to twice the "expected" maximum size for "reasonable" VMs) is limited and hence also sucks. But it _does_ work as a stopgap until we figure out what migration of ACPI tables really entails. The question then is: when should we trim the tables? Because answering that question also answers whether we should apply your patches. My answer to that question is "not anytime soon", perhaps 2.4 but more likely 2.5. For 2.3, the target should be the two other pending ACPI series that reorganize the tables. In different and complementary ways, both attempt at making the tables more predictable and thus mitigate or resolve the migration problems. My patches add some separation between "mutable" and "constant" tables. Igor's patches make "constant" tables really constant by taking IASL out of the equation. (Note that if useful, the C generation can also be applied to the mutable tables; it's also possible to have a mutable SSDT and a constant one, the only requirement for mutable tables is that their size be bounded). I cannot of course be sure of how the ACPI tables will evolve in the future. But we can give a try to the improvements that I and Igor introduced for a release cycle or two. For those releases we can still keep the 128k ACPI tables, and detect breakage using bios-tables-test. We can improve the test to check table sizes (not contents) for a bunch of configurations. We only need to cover edges, not paths, so it's not hard to do. Paolo