> > ... > > This approach could be taken one step further, where vmbus_reserve_fb() > > *always* reserves 64 MiB starting at the low end of low MMIO space, > > regardless of the value of "start". The messy code for getting "start" > > could be dropped entirely, and the dependency on CONFIG_SYSFB goes > > away. Or maybe still get the value of "start" and "size", and if non-zero > > just do a sanity check that they are within the fixed 64 MiB reserved area.
My earlier reply yesterday explains why we shouldn't get rid of the screen.lfb_base. I'm trying to make as few assumptions as possible. > > Thoughts? To me tweaking vmbus_reserve_fb() is a more > > straightforward and explicit way to do the reserving, vs. modifying > > the requested range in the Hyper-V PCI driver. > > Agreed. Let me try to make a new patch for review. I just posted a patch here: https://lwn.net/ml/linux-kernel/20260416183529.838321-1-decui%40microsoft.com/ Please review. The new patch changes the vmbus driver. With it, the previous v2 pci-hyperv patch is unnecessary now. Thanks, -- Dexuan
