On Thu, Jan 26, 2017 at 06:43:22PM +0100, Laszlo Ersek wrote: > On 01/26/17 16:20, Michael S. Tsirkin wrote: > > On Thu, Jan 26, 2017 at 01:48:37AM +0100, Laszlo Ersek wrote: > > >> But, again, I'd like to keep COMMAND_ALLOCATE_RETURN_ADDR 8-byte wide. > > > > > > What is COMMAND_ALLOCATE_RETURN_ADDR? I'm only familiar with > > COMMAND_ALLOCATE. > > It's a new command being introduced in this series, at my suggestion. It > does the exact same thing as COMMAND_ALLOCATE, except once the > allocation / download is carried out by the firmware, the firmware > writes back the allocation address to the fw_cfg file that is named in > an additional field of the COMMAND_ALLOCATE_RETURN_ADDR structure. (This > is how QEMU learns where the blob in GPA space was placed by the > firmware.) The format for this address-receiving fw_cfg file is supposed > to be 8-byte, little endian.
I see. I really think it's better as a separate command though. E.g. COMMAND_WRITE_PTR? > My request above is simply that we stick with the 8-byte size for this > fw_cfg file, for receiving a guest allocation address. Regardless of the > fact that currently all such allocation addresses fit in 4 bytes. > > > If we want to allow this stuff in high 64 bit, as you > > correctly say we will need a new zone to allocate 64 bit memory. > > As for XP support - might it be reasonable to require that > > these machines have less than 4G RAM at boot? > > Perhaps; I'm not sure. At the moment I have zero concrete use cases in > mind. I just want COMMAND_ALLOCATE_RETURN_ADDR to promise the firmware > that the firmware will be able to return 8 bytes / LE as the allocation > address. How this will interact with any new zones and RAM sizes vs. > guest OSes is TBD in the future. > > >> In the future we might introduce more allocation hints (for the "zone" > >> field) that would enable the firmware to allocate from the full 64-bit > >> address space. > > > > The difficulty with new commands always was compatibility with old > > firmware. I guess now that we have writeable fw cfg we will be > > able to support negotiation cleanly. > > Specifically for the zone field of COMMAND_ALLOCATE (and identically, > COMMAND_ALLOCATE_RETURN_ADDR), I think we might not need full-blown > negotiation; there aren't that many firmwares to check compatibility > with -- OVMF and SeaBIOS. If old versions of those happen to handle a > new zone value gracefully (such as "not fseg", simply), i.e. they'd > behave the same as now, then we shouldn't need negotiation. Otherwise, > we'll need it (once we have a particular use case). > > > Should we start now? > > No, I don't think so. I don't have any use case for 64-bit allocation; > what we have now works perfectly. I just wanted to emphasize that > permitting an 8-byte width for the alloc address to be returned is more > "future proof" than a 4-byte size, for COMMAND_ALLOCATE_RETURN_ADDR; > independently of what size we choose right here for VGIA. > > Thanks, > Laszlo I agree here. -- MST