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. 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