| Message ID | 1407670353-14971-3-git-send-email-ghammer@redhat.com |
|---|---|
| State | New |
| Headers | show |
Il 10/08/2014 13:32, Gal Hammer ha scritto: > Based on Microsoft's sepecifications (paper can be dowloaded from > http://go.microsoft.com/fwlink/?LinkId=260709), add a device > description to the SSDT ACPI table. > > The GUID is set using a new "-vmgenid" command line parameter. > > Signed-off-by: Gal Hammer <ghammer@redhat.com> > --- > hw/i386/acpi-build.c | 23 +++++++++++++++++++++++ > hw/i386/ssdt-misc.dsl | 33 +++++++++++++++++++++++++++++++++ > qemu-options.hx | 9 +++++++++ > vl.c | 11 +++++++++++ > 4 files changed, 76 insertions(+) Please make this a new device (like pvpanic), instead of adding a new command-line option. > > + Scope(\_SB) { > + > + Device(VMGI) { > + Name(_HID, "QEMU0002") > + Name(_CID, "VM_Gen_Counter") > + Name(_DDN, "VM_Gen_Counter") > + > + ACPI_EXTRACT_NAME_DWORD_CONST ssdt_acpi_vm_gid_addr > + Name(VGIA, 0x12345678) > + > + ACPI_EXTRACT_NAME_BUFFER16 ssdt_acpi_vm_gid > + Name(VGID, Buffer(16) { > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }) > + > + Method(_STA, 0, NotSerialized) { > + Store(VGIA, Local0) > + If (LEqual(Local0, Zero)) { > + Return (0x00) > + } Else { > + Return (0x0F) > + } > + } > + > + Method(ADDR, 0, Serialized) { > + Store(Package(2) { }, Local0) > + Store(VGIA, Index(Local0, 0)) > + Store(0x0000, Index(Local0, 1)) > + return (Local0) > + } > + } > + } > + Please either put this in the DSDT, or omit the Device altogether if you put it in the SSDT and there is no VMGID device. Thanks, Paolo
Hi, On 10/08/2014 20:22, Paolo Bonzini wrote: > Il 10/08/2014 13:32, Gal Hammer ha scritto: >> Based on Microsoft's sepecifications (paper can be dowloaded from >> http://go.microsoft.com/fwlink/?LinkId=260709), add a device >> description to the SSDT ACPI table. >> >> The GUID is set using a new "-vmgenid" command line parameter. >> >> Signed-off-by: Gal Hammer <ghammer@redhat.com> >> --- >> hw/i386/acpi-build.c | 23 +++++++++++++++++++++++ >> hw/i386/ssdt-misc.dsl | 33 +++++++++++++++++++++++++++++++++ >> qemu-options.hx | 9 +++++++++ >> vl.c | 11 +++++++++++ >> 4 files changed, 76 insertions(+) > > Please make this a new device (like pvpanic), instead of adding a new > command-line option. There is a problem with this request. I don't want to use ISA because it is obsolete, PCI is overkill for such a device and a SYSBUS (like HPET) device doesn't effect the command line options. Did I miss something in SYSBUS and that's was the reason it didn't appear in the "-device ?" list? >> >> + Scope(\_SB) { >> + >> + Device(VMGI) { >> + Name(_HID, "QEMU0002") >> + Name(_CID, "VM_Gen_Counter") >> + Name(_DDN, "VM_Gen_Counter") >> + >> + ACPI_EXTRACT_NAME_DWORD_CONST ssdt_acpi_vm_gid_addr >> + Name(VGIA, 0x12345678) >> + >> + ACPI_EXTRACT_NAME_BUFFER16 ssdt_acpi_vm_gid >> + Name(VGID, Buffer(16) { >> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }) >> + >> + Method(_STA, 0, NotSerialized) { >> + Store(VGIA, Local0) >> + If (LEqual(Local0, Zero)) { >> + Return (0x00) >> + } Else { >> + Return (0x0F) >> + } >> + } >> + >> + Method(ADDR, 0, Serialized) { >> + Store(Package(2) { }, Local0) >> + Store(VGIA, Index(Local0, 0)) >> + Store(0x0000, Index(Local0, 1)) >> + return (Local0) >> + } >> + } >> + } >> + > > Please either put this in the DSDT, or omit the Device altogether if you > put it in the SSDT and there is no VMGID device. I'm not sure I understand this comment. I've put the new device in the SSDT table (like pvpanic) and add a _STA method which disable the device if no GUID's address is set (VGIA). The device doesn't show in the Device Manager if it was not added using the command line. Gal. > Thanks, > > Paolo >
Il 12/08/2014 10:02, Gal Hammer ha scritto: > Hi, > > On 10/08/2014 20:22, Paolo Bonzini wrote: > >> Il 10/08/2014 13:32, Gal Hammer ha scritto: >>> Based on Microsoft's sepecifications (paper can be dowloaded from >>> http://go.microsoft.com/fwlink/?LinkId=260709), add a device >>> description to the SSDT ACPI table. >>> >>> The GUID is set using a new "-vmgenid" command line parameter. >>> >>> Signed-off-by: Gal Hammer <ghammer@redhat.com> >>> --- >>> hw/i386/acpi-build.c | 23 +++++++++++++++++++++++ >>> hw/i386/ssdt-misc.dsl | 33 +++++++++++++++++++++++++++++++++ >>> qemu-options.hx | 9 +++++++++ >>> vl.c | 11 +++++++++++ >>> 4 files changed, 76 insertions(+) >> >> Please make this a new device (like pvpanic), instead of adding a new >> command-line option. > > There is a problem with this request. I don't want to use ISA because it > is obsolete, PCI is overkill for such a device and a SYSBUS (like HPET) > device doesn't effect the command line options. > > Did I miss something in SYSBUS and that's was the reason it didn't > appear in the "-device ?" list? For a sysbus device, you can override the cannot_instantiate_with_device_add_yet field of DeviceClass in your class_init function. >>> >>> + Scope(\_SB) { >>> + >>> + Device(VMGI) { >>> + Name(_HID, "QEMU0002") >>> + Name(_CID, "VM_Gen_Counter") >>> + Name(_DDN, "VM_Gen_Counter") >>> + >>> + ACPI_EXTRACT_NAME_DWORD_CONST ssdt_acpi_vm_gid_addr >>> + Name(VGIA, 0x12345678) >>> + >>> + ACPI_EXTRACT_NAME_BUFFER16 ssdt_acpi_vm_gid >>> + Name(VGID, Buffer(16) { >>> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >>> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }) >>> + >>> + Method(_STA, 0, NotSerialized) { >>> + Store(VGIA, Local0) >>> + If (LEqual(Local0, Zero)) { >>> + Return (0x00) >>> + } Else { >>> + Return (0x0F) >>> + } >>> + } >>> + >>> + Method(ADDR, 0, Serialized) { >>> + Store(Package(2) { }, Local0) >>> + Store(VGIA, Index(Local0, 0)) >>> + Store(0x0000, Index(Local0, 1)) >>> + return (Local0) >>> + } >>> + } >>> + } >>> + >> >> Please either put this in the DSDT, or omit the Device altogether if you >> put it in the SSDT and there is no VMGID device. > > I'm not sure I understand this comment. I've put the new device in the > SSDT table (like pvpanic) and add a _STA method which disable the device > if no GUID's address is set (VGIA). The device doesn't show in the > Device Manager if it was not added using the command line. We are still in the process of defining which devices/methods go in the DSDT and which go in the SSDT. We had bad experiences with ACPI table migration in 2.1, and one plan to fix them is the following: * the DSDT should always be the same size no matter what command line options are there * the SSDT should have the exact same content (byte-for-byte) for different versions of QEMU, with the same command line options (including the machine type). Right now your code obeys the first rule, not the second rule, so it should add the device to the DSDT. BTW, which events would cause the ID to change? How should live cloning (or revert to a disk+RAM snapshot) be implemented by layers above QEMU for the VM gen ID to be patched? Can you add something to docs/ about it? Also, how does this ID compare to the UUID in the DMI info (-uuid)? Paolo
Paolo Bonzini <pbonzini@redhat.com> writes: > Il 12/08/2014 10:02, Gal Hammer ha scritto: >> Hi, >> >> On 10/08/2014 20:22, Paolo Bonzini wrote: >> >>> Il 10/08/2014 13:32, Gal Hammer ha scritto: >>>> Based on Microsoft's sepecifications (paper can be dowloaded from >>>> http://go.microsoft.com/fwlink/?LinkId=260709), add a device >>>> description to the SSDT ACPI table. >>>> >>>> The GUID is set using a new "-vmgenid" command line parameter. >>>> >>>> Signed-off-by: Gal Hammer <ghammer@redhat.com> >>>> --- >>>> hw/i386/acpi-build.c | 23 +++++++++++++++++++++++ >>>> hw/i386/ssdt-misc.dsl | 33 +++++++++++++++++++++++++++++++++ >>>> qemu-options.hx | 9 +++++++++ >>>> vl.c | 11 +++++++++++ >>>> 4 files changed, 76 insertions(+) >>> >>> Please make this a new device (like pvpanic), instead of adding a new >>> command-line option. >> >> There is a problem with this request. I don't want to use ISA because it >> is obsolete, PCI is overkill for such a device and a SYSBUS (like HPET) >> device doesn't effect the command line options. >> >> Did I miss something in SYSBUS and that's was the reason it didn't >> appear in the "-device ?" list? > > For a sysbus device, you can override the > cannot_instantiate_with_device_add_yet field of DeviceClass in your > class_init function. Correct. Sysbus devices are not available with device_add / -device by default, because to actually work, they commonly require code to connect them to other devices. A sysbus device that doesn't need such connections can be made available with device_add / -device in the way Paolo described. [...]
On 17/08/2014 12:49, Paolo Bonzini wrote: > Il 12/08/2014 10:02, Gal Hammer ha scritto: >> Hi, >> >> On 10/08/2014 20:22, Paolo Bonzini wrote: >> >>> Il 10/08/2014 13:32, Gal Hammer ha scritto: >>>> Based on Microsoft's sepecifications (paper can be dowloaded from >>>> http://go.microsoft.com/fwlink/?LinkId=260709), add a device >>>> description to the SSDT ACPI table. >>>> >>>> The GUID is set using a new "-vmgenid" command line parameter. >>>> >>>> Signed-off-by: Gal Hammer <ghammer@redhat.com> >>>> --- >>>> hw/i386/acpi-build.c | 23 +++++++++++++++++++++++ >>>> hw/i386/ssdt-misc.dsl | 33 +++++++++++++++++++++++++++++++++ >>>> qemu-options.hx | 9 +++++++++ >>>> vl.c | 11 +++++++++++ >>>> 4 files changed, 76 insertions(+) >>> >>> Please make this a new device (like pvpanic), instead of adding a new >>> command-line option. >> >> There is a problem with this request. I don't want to use ISA because it >> is obsolete, PCI is overkill for such a device and a SYSBUS (like HPET) >> device doesn't effect the command line options. >> >> Did I miss something in SYSBUS and that's was the reason it didn't >> appear in the "-device ?" list? > > For a sysbus device, you can override the > cannot_instantiate_with_device_add_yet field of DeviceClass in your > class_init function. > >>>> >>>> + Scope(\_SB) { >>>> + >>>> + Device(VMGI) { >>>> + Name(_HID, "QEMU0002") >>>> + Name(_CID, "VM_Gen_Counter") >>>> + Name(_DDN, "VM_Gen_Counter") >>>> + >>>> + ACPI_EXTRACT_NAME_DWORD_CONST ssdt_acpi_vm_gid_addr >>>> + Name(VGIA, 0x12345678) >>>> + >>>> + ACPI_EXTRACT_NAME_BUFFER16 ssdt_acpi_vm_gid >>>> + Name(VGID, Buffer(16) { >>>> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >>>> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }) >>>> + >>>> + Method(_STA, 0, NotSerialized) { >>>> + Store(VGIA, Local0) >>>> + If (LEqual(Local0, Zero)) { >>>> + Return (0x00) >>>> + } Else { >>>> + Return (0x0F) >>>> + } >>>> + } >>>> + >>>> + Method(ADDR, 0, Serialized) { >>>> + Store(Package(2) { }, Local0) >>>> + Store(VGIA, Index(Local0, 0)) >>>> + Store(0x0000, Index(Local0, 1)) >>>> + return (Local0) >>>> + } >>>> + } >>>> + } >>>> + >>> >>> Please either put this in the DSDT, or omit the Device altogether if you >>> put it in the SSDT and there is no VMGID device. >> >> I'm not sure I understand this comment. I've put the new device in the >> SSDT table (like pvpanic) and add a _STA method which disable the device >> if no GUID's address is set (VGIA). The device doesn't show in the >> Device Manager if it was not added using the command line. > > We are still in the process of defining which devices/methods go in the > DSDT and which go in the SSDT. We had bad experiences with ACPI table > migration in 2.1, and one plan to fix them is the following: > > * the DSDT should always be the same size no matter what command line > options are there > > * the SSDT should have the exact same content (byte-for-byte) for > different versions of QEMU, with the same command line options > (including the machine type). > > Right now your code obeys the first rule, not the second rule, so it > should add the device to the DSDT. Are you sure about selecting the DSDT? I don't see anyone else is using the ACPI_EXTRACT_NAME_* macros in the DSDT table (and I keep crashing my guest, but ignore it for now ;-)). > BTW, which events would cause the ID to change? How should live cloning > (or revert to a disk+RAM snapshot) be implemented by layers above QEMU > for the VM gen ID to be patched? Can you add something to docs/ about it? The VGID is expected to change when executing a VM with the -snapshot option, when a VM is restored from a backup or when it is imported, copied or cloned. So I would say it is a management's call. I think that the Microsoft's document describes the requirements better than me :-). > Also, how does this ID compare to the UUID in the DMI info (-uuid)? The -uuid is not expected to change after the VM was created. Unlike the -vmgenid that is designed to give the guest OS a notification that a change has occurred. Microsoft, as an example, writes that is can be use for a safer cryptographic software. > Paolo > Gal.
Il 01/09/2014 09:20, Gal Hammer ha scritto: >> >> We are still in the process of defining which devices/methods go in the >> DSDT and which go in the SSDT. We had bad experiences with ACPI table >> migration in 2.1, and one plan to fix them is the following: >> >> * the DSDT should always be the same size no matter what command line >> options are there >> >> * the SSDT should have the exact same content (byte-for-byte) for >> different versions of QEMU, with the same command line options >> (including the machine type). >> >> Right now your code obeys the first rule, not the second rule, so it >> should add the device to the DSDT. > > Are you sure about selecting the DSDT? I don't see anyone else is using > the ACPI_EXTRACT_NAME_* macros in the DSDT table (and I keep crashing my > guest, but ignore it for now ;-)). There is one user: acpi-dsdt-isa.dsl: ACPI_EXTRACT_NAME_BYTE_CONST DSDT_APPLESMC_STA >> BTW, which events would cause the ID to change? How should live cloning >> (or revert to a disk+RAM snapshot) be implemented by layers above QEMU >> for the VM gen ID to be patched? Can you add something to docs/ about >> it? > > The VGID is expected to change when executing a VM with the -snapshot > option, when a VM is restored from a backup or when it is imported, > copied or cloned. So I would say it is a management's call. Ok, got it. So to support migration (which includes reverting to an earlier disk+RAM snapshot) you just need to ensure the VGID is patched accordingly. Whether VGID _will_ be different or not, that's management's call. > I think that the Microsoft's document describes the requirements better > than me :-). > >> Also, how does this ID compare to the UUID in the DMI info (-uuid)? > > The -uuid is not expected to change after the VM was created. Unlike the > -vmgenid that is designed to give the guest OS a notification that a > change has occurred. Microsoft, as an example, writes that is can be use > for a safer cryptographic software. I would say that cloning should change the UUID (and the VMGID). Paolo
On 01/09/2014 11:57, Paolo Bonzini wrote: > Il 01/09/2014 09:20, Gal Hammer ha scritto: >>> >>> We are still in the process of defining which devices/methods go in the >>> DSDT and which go in the SSDT. We had bad experiences with ACPI table >>> migration in 2.1, and one plan to fix them is the following: >>> >>> * the DSDT should always be the same size no matter what command line >>> options are there >>> >>> * the SSDT should have the exact same content (byte-for-byte) for >>> different versions of QEMU, with the same command line options >>> (including the machine type). >>> >>> Right now your code obeys the first rule, not the second rule, so it >>> should add the device to the DSDT. >> >> Are you sure about selecting the DSDT? I don't see anyone else is using >> the ACPI_EXTRACT_NAME_* macros in the DSDT table (and I keep crashing my >> guest, but ignore it for now ;-)). > > There is one user: > > acpi-dsdt-isa.dsl: ACPI_EXTRACT_NAME_BYTE_CONST DSDT_APPLESMC_STA Found it after I've stopped looking only at the acpi-dsdt.dsl file. >>> BTW, which events would cause the ID to change? How should live cloning >>> (or revert to a disk+RAM snapshot) be implemented by layers above QEMU >>> for the VM gen ID to be patched? Can you add something to docs/ about >>> it? >> >> The VGID is expected to change when executing a VM with the -snapshot >> option, when a VM is restored from a backup or when it is imported, >> copied or cloned. So I would say it is a management's call. > > Ok, got it. > > So to support migration (which includes reverting to an earlier disk+RAM > snapshot) you just need to ensure the VGID is patched accordingly. > Whether VGID _will_ be different or not, that's management's call. > >> I think that the Microsoft's document describes the requirements better >> than me :-). >> >>> Also, how does this ID compare to the UUID in the DMI info (-uuid)? >> >> The -uuid is not expected to change after the VM was created. Unlike the >> -vmgenid that is designed to give the guest OS a notification that a >> change has occurred. Microsoft, as an example, writes that is can be use >> for a safer cryptographic software. > > I would say that cloning should change the UUID (and the VMGID). Again, that's a management call as well. One might choose not to change the BIOS UUID when cloning the machine in order to prevent Windows from trying to re-activate itself (or any other licensed software for that matter). > Paolo > A V2 of the patch was send to the list. Gal.
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c index 816c6d9..838c72c 100644 --- a/hw/i386/acpi-build.c +++ b/hw/i386/acpi-build.c @@ -54,6 +54,9 @@ #include "qapi/qmp/qint.h" #include "qom/qom-qobject.h" +extern uint8_t vm_generation_id[16]; +extern bool vm_generation_id_set; + /* These are used to size the ACPI tables for -M pc-i440fx-1.7 and * -M pc-i440fx-2.0. Even if the actual amount of AML generated grows * a little bit, there should be plenty of free space since the DSDT @@ -1051,6 +1054,7 @@ build_ssdt(GArray *table_data, GArray *linker, unsigned acpi_cpus = guest_info->apic_id_limit; int ssdt_start = table_data->len; uint8_t *ssdt_ptr; + uint32_t vm_gid_physical_address; int i; /* The current AML generator can cover the APIC ID range [0..255], @@ -1076,6 +1080,25 @@ build_ssdt(GArray *table_data, GArray *linker, ACPI_BUILD_SET_LE(ssdt_ptr, sizeof(ssdp_misc_aml), ssdt_isa_pest[0], 16, misc->pvpanic_port); + if (vm_generation_id_set) { + uint8_t *vm_gid_ptr; + + vm_gid_physical_address = ssdt_start + ssdt_acpi_vm_gid[0]; + vm_gid_ptr = acpi_data_get_ptr(ssdt_ptr, sizeof(ssdp_misc_aml), + ssdt_acpi_vm_gid[0], 16); + memcpy(vm_gid_ptr, vm_generation_id, sizeof(vm_generation_id)); + + bios_linker_loader_add_pointer(linker, ACPI_BUILD_TABLE_FILE, + ACPI_BUILD_TABLE_FILE, + table_data, ssdt_ptr + ssdt_acpi_vm_gid_addr[0], + sizeof(uint32_t)); + } else { + vm_gid_physical_address = 0; + } + + ACPI_BUILD_SET_LE(ssdt_ptr, sizeof(ssdp_misc_aml), + ssdt_acpi_vm_gid_addr[0], 32, vm_gid_physical_address); + ACPI_BUILD_SET_LE(ssdt_ptr, sizeof(ssdp_misc_aml), ssdt_mctrl_nr_slots[0], 32, nr_mem); diff --git a/hw/i386/ssdt-misc.dsl b/hw/i386/ssdt-misc.dsl index d329b8b..8a001a7 100644 --- a/hw/i386/ssdt-misc.dsl +++ b/hw/i386/ssdt-misc.dsl @@ -118,6 +118,39 @@ DefinitionBlock ("ssdt-misc.aml", "SSDT", 0x01, "BXPC", "BXSSDTSUSP", 0x1) } } + Scope(\_SB) { + + Device(VMGI) { + Name(_HID, "QEMU0002") + Name(_CID, "VM_Gen_Counter") + Name(_DDN, "VM_Gen_Counter") + + ACPI_EXTRACT_NAME_DWORD_CONST ssdt_acpi_vm_gid_addr + Name(VGIA, 0x12345678) + + ACPI_EXTRACT_NAME_BUFFER16 ssdt_acpi_vm_gid + Name(VGID, Buffer(16) { + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }) + + Method(_STA, 0, NotSerialized) { + Store(VGIA, Local0) + If (LEqual(Local0, Zero)) { + Return (0x00) + } Else { + Return (0x0F) + } + } + + Method(ADDR, 0, Serialized) { + Store(Package(2) { }, Local0) + Store(VGIA, Index(Local0, 0)) + Store(0x0000, Index(Local0, 1)) + return (Local0) + } + } + } + External(MEMORY_SLOT_NOTIFY_METHOD, MethodObj) Scope(\_SB.PCI0) { Device(MEMORY_HOPTLUG_DEVICE) { diff --git a/qemu-options.hx b/qemu-options.hx index 96516c1..a6d475c 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -369,6 +369,15 @@ STEXI Set system UUID. ETEXI +DEF("vmgenid", HAS_ARG, QEMU_OPTION_vmgenid, + "-vmgenid %08x-%04x-%04x-%04x-%012x\n" + " specify the virtual machine generation ID\n", QEMU_ARCH_I386) +STEXI +@item -uuid @var{uuid} +@findex -uuid +Set the virtual machine generation ID. +ETEXI + STEXI @end table ETEXI diff --git a/vl.c b/vl.c index a8029d5..a5ef0d5 100644 --- a/vl.c +++ b/vl.c @@ -203,6 +203,9 @@ NodeInfo numa_info[MAX_NODES]; uint8_t qemu_uuid[16]; bool qemu_uuid_set; +uint8_t vm_generation_id[16]; +bool vm_generation_id_set; + static QEMUBootSetHandler *boot_set_handler; static void *boot_set_opaque; @@ -3784,6 +3787,14 @@ int main(int argc, char **argv, char **envp) } qemu_uuid_set = true; break; + case QEMU_OPTION_vmgenid: + if(qemu_uuid_parse(optarg, vm_generation_id) < 0) { + fprintf(stderr, "Fail to parse UUID string." + " Wrong format.\n"); + exit(1); + } + vm_generation_id_set = true; + break; case QEMU_OPTION_option_rom: if (nb_option_roms >= MAX_OPTION_ROMS) { fprintf(stderr, "Too many option ROMs\n");
Based on Microsoft's sepecifications (paper can be dowloaded from http://go.microsoft.com/fwlink/?LinkId=260709), add a device description to the SSDT ACPI table. The GUID is set using a new "-vmgenid" command line parameter. Signed-off-by: Gal Hammer <ghammer@redhat.com> --- hw/i386/acpi-build.c | 23 +++++++++++++++++++++++ hw/i386/ssdt-misc.dsl | 33 +++++++++++++++++++++++++++++++++ qemu-options.hx | 9 +++++++++ vl.c | 11 +++++++++++ 4 files changed, 76 insertions(+)