On Mon, 10 Oct 2016 21:09:30 +0800 Xiao Guangrong <guangrong.x...@linux.intel.com> wrote:
> On 10/10/2016 08:51 PM, Igor Mammedov wrote: > > On Sat, 8 Oct 2016 15:17:14 +0800 > > Xiao Guangrong <guangrong.x...@linux.intel.com> wrote: > > > >> On 09/30/2016 09:14 PM, Igor Mammedov wrote: > >>> On Fri, 12 Aug 2016 14:54:05 +0800 > >>> Xiao Guangrong <guangrong.x...@linux.intel.com> wrote: > >>> > >>>> _FIT is required for hotplug support, guest will inquire the updated > >>>> device info from it if a hotplug event is received > >>>> > >>>> As FIT buffer is not completely mapped into guest address space, so a > >>>> new function, Read FIT whose function index is 0xFFFFFFFF, is reserved > >>>> by QEMU to read the piece of FIT buffer. The buffer is concatenated > >>>> before _FIT return > >>> Only issuer of UUID 2F10E7A4-9E91-11E4-89D3-123B93F75CBA can reserve > >>> 0xFFFFFFFF for some purposes. > >>> So spec should be amended first or custom generated UUID should be used. > >> > >> Okay. > >> > >> I will change the changelog to reflect this fact and move the spec update > >> to this patch. > > under spec, I've meant ACPI spec where this UUID is declared > > Er. ACPI spec just said that "0xFFFF is reserved", not sure it will be used > in the future. > > I'd prefer to custom-generated UUID, however, currently the UUID is checked > in OSPM, i.e, QEMU is not able to distinguish other UUIDs, I'd go with custom-generated UUID > so how about > drop the UUID check in ACPI and pass the UUID info to QEMU? It's a bit late to do so as it would be qemu-guest ABI change and one would need to maintain old and new protocol.
