On Mon, Jan 06, 2025 at 01:07:25PM -0800, Roman Kisel wrote: > > > On 1/6/2025 11:32 AM, Stanislav Kinsburskii wrote: > > On Mon, Jan 06, 2025 at 10:11:16AM -0800, Roman Kisel wrote: > [...]s > > > From my POV a decision between a unified approach and interim solutions > > in upstream should usually be resolved in favor of the former. > > Given there are different stake holders in VTL code integration, I'd > > suggest we step back a bit and think about how to proceed with the > > overall design. > I don't see any compelling reason for stalling this fix and think for > no one knows how long. What is going to be fixed is clear, and it has > not been demonstrated what is going to be broken when this change is > merged. > > > > > In my opinion, although I undestand why Underhill project decided to > > come up with the original VTL kernels separation during build time, it's > > time to reconsider this approach and to come up with a more generic > > design, supporting booting the same kernel in different VTLs. > "The same kernel" means supporting ACPI/UEFI for VTL0, VTL1, VTL2 as > otherwise VTL0 won't boot. But why would VTL>0 even consider relying on > ACPI or compiling it in? I would fix your broad assertion with adding > one constraint: share as much Hyper-V code as possible, booting is not > expected, rather refuse building. > > > > > The major reason for this is that LVBS project relies on binary > > compatibility of the kernels running in different VTLs. > > The simplest way to provide such a guarantee in both development and > > deployment is to run the same kernel in both VTLs. > > OpenHCL aka Underhill is the only shipping product relying on > the code in question (others might be dom0 and LVBS). What the LVBS > project relies on might change any number of times any day before it > ships. OpenHCL works for customers and slicing and dicing it ought to > be well thought through. > > > Not having this ability will require carefull crafting of both the > > kernels upon build, making kexec servicing of such kernels in production > > complicated and error prone. > > Too vague, imho. I'd respond that "careful crafting" shouldn't lead to > being complicated and error prone as long as it's automatic and, well, > careful. > > It is harder and harder to me to see how enabling the hypercall output > page is related to where the discussion has drifted. My claims are: > > * enabling the hypercall output page poses no harm (doesn't break hyper- > next), > * allows to bring the code to the clear and concise form of getting a VP > register. > > Can you refute any of that? > My point is that the proposed fix looks more like an Underhill-tailored bandage and doesn't take the needs of other stake holders into consideration. What is the urgency in merging of this particular change? Thanks, Stas
