qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] [PATCH 0/8] option rom loading overhaul.
@ 2009-12-18 11:01 Gerd Hoffmann
  2009-12-18 11:01 ` [Qemu-devel] [PATCH 1/8] Support PCI based option rom loading Gerd Hoffmann
                   ` (9 more replies)
  0 siblings, 10 replies; 84+ messages in thread
From: Gerd Hoffmann @ 2009-12-18 11:01 UTC (permalink / raw)
  To: qemu-devel, seabios; +Cc: Anthony Liguori

From: Anthony Liguori <aliguori@us.ibm.com>

  Hi,

Option rom saga continued.  This is the first series I consider ready
for merging.  Changes:

  * pci roms: will be loaded via option pci rom bar.
  * non-pci roms: will be loaded via fw_cfg.

Note that using the old bochs-bios based pc-bios will stop working
with this patch series applied.

The last two patches of this series are *not* intended to be merged,
they are just for testing convinience.  They carry a new seabios
binary and the changes needed and turn on bios debug messages in qemu.

Seabios patches will be posted shortly as separate patch series.

cheers,
  Gerd

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] [PATCH 1/8] Support PCI based option rom loading
  2009-12-18 11:01 [Qemu-devel] [PATCH 0/8] option rom loading overhaul Gerd Hoffmann
@ 2009-12-18 11:01 ` Gerd Hoffmann
  2009-12-19 10:57   ` Blue Swirl
  2009-12-18 11:01 ` [Qemu-devel] [PATCH 2/8] pci romfiles: add property, add default to PCIDeviceInfo Gerd Hoffmann
                   ` (8 subsequent siblings)
  9 siblings, 1 reply; 84+ messages in thread
From: Gerd Hoffmann @ 2009-12-18 11:01 UTC (permalink / raw)
  To: qemu-devel, seabios; +Cc: Anthony Liguori, Gerd Hoffmann

From: Anthony Liguori <aliguori@us.ibm.com>

Currently, we preload option roms into the option rom space in memory.  This
prevents DDIM from functioning correctly which severely limits the number
of roms we can support.

This patch introduces a pci_add_option_rom() which registers the
PCI_ROM_ADDRESS bar which points to our option rom.  It also converts over
the cirrus vga adapter, the rtl8139, virtio, and the e1000 to use this
new mechanism.

The result is that PXE boot functions even with three unique types of cards.

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/cirrus_vga.c |    2 +-
 hw/e1000.c      |    2 +-
 hw/pci.c        |   35 +++++++++++++++++++++++++++++++++++
 hw/pci.h        |    5 +++++
 hw/rtl8139.c    |    2 +-
 hw/virtio-pci.c |    2 +-
 6 files changed, 44 insertions(+), 4 deletions(-)

diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index 24af81c..b08d2ae 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -3211,7 +3211,7 @@ static int pci_cirrus_vga_initfn(PCIDevice *dev)
      }
 
      /* ROM BIOS */
-     rom_add_vga(VGABIOS_CIRRUS_FILENAME);
+     pci_add_option_rom((PCIDevice *)d, VGABIOS_CIRRUS_FILENAME);
      return 0;
 }
 
diff --git a/hw/e1000.c b/hw/e1000.c
index 8566fe3..f795601 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -1125,7 +1125,7 @@ static int pci_e1000_init(PCIDevice *pci_dev)
     if (!pci_dev->qdev.hotplugged) {
         static int loaded = 0;
         if (!loaded) {
-            rom_add_option("pxe-e1000.bin");
+            pci_add_option_rom(&d->dev, "pxe-e1000.bin");
             loaded = 1;
         }
     }
diff --git a/hw/pci.c b/hw/pci.c
index 404eead..dbdfdbf 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -26,6 +26,7 @@
 #include "monitor.h"
 #include "net.h"
 #include "sysemu.h"
+#include "loader.h"
 
 //#define DEBUG_PCI
 #ifdef DEBUG_PCI
@@ -1463,6 +1464,40 @@ static uint8_t pci_find_capability_list(PCIDevice *pdev, uint8_t cap_id,
     return next;
 }
 
+static void pci_map_option_rom(PCIDevice *pdev, int region_num, pcibus_t addr, pcibus_t size, int type)
+{
+    cpu_register_physical_memory(addr, size, pdev->rom_offset);
+}
+
+/* Add an option rom for the device */
+int pci_add_option_rom(PCIDevice *pdev, const char *name)
+{
+    int size;
+    char *path;
+    void *ptr;
+
+    path = qemu_find_file(QEMU_FILE_TYPE_BIOS, name);
+    if (path == NULL) {
+        path = qemu_strdup(name);
+    }
+
+    size = get_image_size(path);
+    if (size & (size - 1)) {
+        size = 1 << qemu_fls(size);
+    }
+
+    pdev->rom_offset = qemu_ram_alloc(size);
+
+    ptr = qemu_get_ram_ptr(pdev->rom_offset);
+    load_image(path, ptr);
+    qemu_free(path);
+
+    pci_register_bar(pdev, PCI_ROM_SLOT, size,
+                     0, pci_map_option_rom);
+
+    return 0;
+}
+
 /* Reserve space and add capability to the linked list in pci config space */
 int pci_add_capability(PCIDevice *pdev, uint8_t cap_id, uint8_t size)
 {
diff --git a/hw/pci.h b/hw/pci.h
index d279e3f..89b3f55 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -243,6 +243,9 @@ struct PCIDevice {
     uint32_t msix_bar_size;
     /* Version id needed for VMState */
     int32_t version_id;
+
+    /* Location of option rom */
+    ram_addr_t rom_offset;
 };
 
 PCIDevice *pci_register_device(PCIBus *bus, const char *name,
@@ -254,6 +257,8 @@ void pci_register_bar(PCIDevice *pci_dev, int region_num,
                             pcibus_t size, int type,
                             PCIMapIORegionFunc *map_func);
 
+int pci_add_option_rom(PCIDevice *pdev, const char *name);
+
 int pci_add_capability(PCIDevice *pci_dev, uint8_t cap_id, uint8_t cap_size);
 
 void pci_del_capability(PCIDevice *pci_dev, uint8_t cap_id, uint8_t cap_size);
diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index 9fd05a8..2cee97b 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
@@ -3357,7 +3357,7 @@ static int pci_rtl8139_init(PCIDevice *dev)
     if (!dev->qdev.hotplugged) {
         static int loaded = 0;
         if (!loaded) {
-            rom_add_option("pxe-rtl8139.bin");
+            pci_add_option_rom(&s->dev, "pxe-rtl8139.bin");
             loaded = 1;
         }
     }
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index 4500130..85f14a2 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -522,7 +522,7 @@ static int virtio_net_init_pci(PCIDevice *pci_dev)
     if (!pci_dev->qdev.hotplugged) {
         static int loaded = 0;
         if (!loaded) {
-            rom_add_option("pxe-virtio.bin");
+            pci_add_option_rom(pci_dev, "pxe-virtio.bin");
             loaded = 1;
         }
     }
-- 
1.6.5.2

^ permalink raw reply related	[flat|nested] 84+ messages in thread
* [Qemu-devel] [PATCH 2/8] pci romfiles: add property, add default to PCIDeviceInfo
  2009-12-18 11:01 [Qemu-devel] [PATCH 0/8] option rom loading overhaul Gerd Hoffmann
  2009-12-18 11:01 ` [Qemu-devel] [PATCH 1/8] Support PCI based option rom loading Gerd Hoffmann
@ 2009-12-18 11:01 ` Gerd Hoffmann
  2010-01-11 21:18   ` [Qemu-devel] [RFC] New naming rules for GPXE romfiles Stefan Weil
  2009-12-18 11:01 ` [Qemu-devel] [PATCH 3/8] fw_cfg: make calls typesafe Gerd Hoffmann
                   ` (7 subsequent siblings)
  9 siblings, 1 reply; 84+ messages in thread
From: Gerd Hoffmann @ 2009-12-18 11:01 UTC (permalink / raw)
  To: qemu-devel, seabios; +Cc: Gerd Hoffmann

This patch adds a romfile property to the pci bus.  It allows to specify
a romfile to load into the rom bar of the pci device.  The default value
comes from a new field in PCIDeviceInfo.  The property allows to change
the file and also to disable the rom loading using an empty string.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/cirrus_vga.c |    4 +---
 hw/e1000.c      |    9 +--------
 hw/pci.c        |   24 +++++++++++++++++++++---
 hw/pci.h        |    6 ++++--
 hw/rtl8139.c    |    9 +--------
 hw/virtio-pci.c |    9 +--------
 6 files changed, 29 insertions(+), 32 deletions(-)

diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index b08d2ae..6fe433d 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -3209,9 +3209,6 @@ static int pci_cirrus_vga_initfn(PCIDevice *dev)
          pci_register_bar((PCIDevice *)d, 1, CIRRUS_PNPMMIO_SIZE,
                           PCI_BASE_ADDRESS_SPACE_MEMORY, cirrus_pci_mmio_map);
      }
-
-     /* ROM BIOS */
-     pci_add_option_rom((PCIDevice *)d, VGABIOS_CIRRUS_FILENAME);
      return 0;
 }
 
@@ -3226,6 +3223,7 @@ static PCIDeviceInfo cirrus_vga_info = {
     .qdev.size    = sizeof(PCICirrusVGAState),
     .qdev.vmsd    = &vmstate_pci_cirrus_vga,
     .init         = pci_cirrus_vga_initfn,
+    .romfile      = VGABIOS_CIRRUS_FILENAME,
     .config_write = pci_cirrus_write_config,
 };
 
diff --git a/hw/e1000.c b/hw/e1000.c
index f795601..33c4bc6 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -1121,14 +1121,6 @@ static int pci_e1000_init(PCIDevice *pci_dev)
                           d->dev.qdev.info->name, d->dev.qdev.id, d);
 
     qemu_format_nic_info_str(&d->nic->nc, macaddr);
-
-    if (!pci_dev->qdev.hotplugged) {
-        static int loaded = 0;
-        if (!loaded) {
-            pci_add_option_rom(&d->dev, "pxe-e1000.bin");
-            loaded = 1;
-        }
-    }
     return 0;
 }
 
@@ -1146,6 +1138,7 @@ static PCIDeviceInfo e1000_info = {
     .qdev.vmsd  = &vmstate_e1000,
     .init       = pci_e1000_init,
     .exit       = pci_e1000_uninit,
+    .romfile    = "pxe-e1000.bin",
     .qdev.props = (Property[]) {
         DEFINE_NIC_PROPERTIES(E1000State, conf),
         DEFINE_PROP_END_OF_LIST(),
diff --git a/hw/pci.c b/hw/pci.c
index dbdfdbf..d54f05e 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -63,12 +63,14 @@ static struct BusInfo pci_bus_info = {
     .print_dev  = pcibus_dev_print,
     .props      = (Property[]) {
         DEFINE_PROP_PCI_DEVFN("addr", PCIDevice, devfn, -1),
+        DEFINE_PROP_STRING("romfile", PCIDevice, romfile),
         DEFINE_PROP_END_OF_LIST()
     }
 };
 
 static void pci_update_mappings(PCIDevice *d);
 static void pci_set_irq(void *opaque, int irq_num, int level);
+static int pci_add_option_rom(PCIDevice *pdev);
 
 target_phys_addr_t pci_mem_base;
 static uint16_t pci_default_sub_vendor_id = PCI_SUBVENDOR_ID_REDHAT_QUMRANET;
@@ -1387,6 +1389,12 @@ static int pci_qdev_init(DeviceState *qdev, DeviceInfo *base)
     rc = info->init(pci_dev);
     if (rc != 0)
         return rc;
+
+    /* rom loading */
+    if (pci_dev->romfile == NULL && info->romfile != NULL)
+        pci_dev->romfile = qemu_strdup(info->romfile);
+    pci_add_option_rom(pci_dev);
+
     if (qdev->hotplugged)
         bus->hotplug(pci_dev, 1);
     return 0;
@@ -1470,18 +1478,28 @@ static void pci_map_option_rom(PCIDevice *pdev, int region_num, pcibus_t addr, p
 }
 
 /* Add an option rom for the device */
-int pci_add_option_rom(PCIDevice *pdev, const char *name)
+static int pci_add_option_rom(PCIDevice *pdev)
 {
     int size;
     char *path;
     void *ptr;
 
-    path = qemu_find_file(QEMU_FILE_TYPE_BIOS, name);
+    if (!pdev->romfile)
+        return 0;
+    if (strlen(pdev->romfile) == 0)
+        return 0;
+
+    path = qemu_find_file(QEMU_FILE_TYPE_BIOS, pdev->romfile);
     if (path == NULL) {
-        path = qemu_strdup(name);
+        path = qemu_strdup(pdev->romfile);
     }
 
     size = get_image_size(path);
+    if (size < 0) {
+        qemu_error("%s: failed to find romfile \"%s\"\n", __FUNCTION__,
+                   pdev->romfile);
+        return -1;
+    }
     if (size & (size - 1)) {
         size = 1 << qemu_fls(size);
     }
diff --git a/hw/pci.h b/hw/pci.h
index 89b3f55..39da7df 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -245,6 +245,7 @@ struct PCIDevice {
     int32_t version_id;
 
     /* Location of option rom */
+    char *romfile;
     ram_addr_t rom_offset;
 };
 
@@ -257,8 +258,6 @@ void pci_register_bar(PCIDevice *pci_dev, int region_num,
                             pcibus_t size, int type,
                             PCIMapIORegionFunc *map_func);
 
-int pci_add_option_rom(PCIDevice *pdev, const char *name);
-
 int pci_add_capability(PCIDevice *pci_dev, uint8_t cap_id, uint8_t cap_size);
 
 void pci_del_capability(PCIDevice *pci_dev, uint8_t cap_id, uint8_t cap_size);
@@ -386,6 +385,9 @@ typedef struct {
 
     /* pcie stuff */
     int is_express;   /* is this device pci express? */
+
+    /* rom bar */
+    const char *romfile;
 } PCIDeviceInfo;
 
 void pci_qdev_register(PCIDeviceInfo *info);
diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index 2cee97b..fcdcd1d 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
@@ -3353,14 +3353,6 @@ static int pci_rtl8139_init(PCIDevice *dev)
     qemu_mod_timer(s->timer,
         rtl8139_get_next_tctr_time(s,qemu_get_clock(vm_clock)));
 #endif /* RTL8139_ONBOARD_TIMER */
-
-    if (!dev->qdev.hotplugged) {
-        static int loaded = 0;
-        if (!loaded) {
-            pci_add_option_rom(&s->dev, "pxe-rtl8139.bin");
-            loaded = 1;
-        }
-    }
     return 0;
 }
 
@@ -3371,6 +3363,7 @@ static PCIDeviceInfo rtl8139_info = {
     .qdev.vmsd  = &vmstate_rtl8139,
     .init       = pci_rtl8139_init,
     .exit       = pci_rtl8139_uninit,
+    .romfile    = "pxe-rtl8139.bin",
     .qdev.props = (Property[]) {
         DEFINE_NIC_PROPERTIES(RTL8139State, conf),
         DEFINE_PROP_END_OF_LIST(),
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index 85f14a2..62b46bd 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -518,14 +518,6 @@ static int virtio_net_init_pci(PCIDevice *pci_dev)
 
     /* make the actual value visible */
     proxy->nvectors = vdev->nvectors;
-
-    if (!pci_dev->qdev.hotplugged) {
-        static int loaded = 0;
-        if (!loaded) {
-            pci_add_option_rom(pci_dev, "pxe-virtio.bin");
-            loaded = 1;
-        }
-    }
     return 0;
 }
 
@@ -569,6 +561,7 @@ static PCIDeviceInfo virtio_info[] = {
         .qdev.size  = sizeof(VirtIOPCIProxy),
         .init       = virtio_net_init_pci,
         .exit       = virtio_net_exit_pci,
+        .romfile    = "pxe-virtio.bin",
         .qdev.props = (Property[]) {
             DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors, 3),
             DEFINE_NIC_PROPERTIES(VirtIOPCIProxy, nic),
-- 
1.6.5.2

^ permalink raw reply related	[flat|nested] 84+ messages in thread
* [Qemu-devel] [PATCH 3/8] fw_cfg: make calls typesafe
  2009-12-18 11:01 [Qemu-devel] [PATCH 0/8] option rom loading overhaul Gerd Hoffmann
  2009-12-18 11:01 ` [Qemu-devel] [PATCH 1/8] Support PCI based option rom loading Gerd Hoffmann
  2009-12-18 11:01 ` [Qemu-devel] [PATCH 2/8] pci romfiles: add property, add default to PCIDeviceInfo Gerd Hoffmann
@ 2009-12-18 11:01 ` Gerd Hoffmann
  2009-12-18 11:01 ` [Qemu-devel] [PATCH 4/8] fw_cfg: add API for file transfer Gerd Hoffmann
                   ` (6 subsequent siblings)
  9 siblings, 0 replies; 84+ messages in thread
From: Gerd Hoffmann @ 2009-12-18 11:01 UTC (permalink / raw)
  To: qemu-devel, seabios; +Cc: Gerd Hoffmann


Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/fw_cfg.c |   26 ++++++++++++--------------
 hw/fw_cfg.h |   16 +++++++++-------
 2 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/hw/fw_cfg.c b/hw/fw_cfg.c
index b25afff..2e3662d 100644
--- a/hw/fw_cfg.c
+++ b/hw/fw_cfg.c
@@ -45,11 +45,11 @@ typedef struct _FWCfgEntry {
     FWCfgCallback callback;
 } FWCfgEntry;
 
-typedef struct _FWCfgState {
+struct _FWCfgState {
     FWCfgEntry entries[2][FW_CFG_MAX_ENTRY];
     uint16_t cur_entry;
     uint32_t cur_offset;
-} FWCfgState;
+};
 
 static void fw_cfg_write(FWCfgState *s, uint8_t value)
 {
@@ -210,9 +210,8 @@ static const VMStateDescription vmstate_fw_cfg = {
     }
 };
 
-int fw_cfg_add_bytes(void *opaque, uint16_t key, uint8_t *data, uint32_t len)
+int fw_cfg_add_bytes(FWCfgState *s, uint16_t key, uint8_t *data, uint32_t len)
 {
-    FWCfgState *s = opaque;
     int arch = !!(key & FW_CFG_ARCH_LOCAL);
 
     key &= FW_CFG_ENTRY_MASK;
@@ -226,37 +225,36 @@ int fw_cfg_add_bytes(void *opaque, uint16_t key, uint8_t *data, uint32_t len)
     return 1;
 }
 
-int fw_cfg_add_i16(void *opaque, uint16_t key, uint16_t value)
+int fw_cfg_add_i16(FWCfgState *s, uint16_t key, uint16_t value)
 {
     uint16_t *copy;
 
     copy = qemu_malloc(sizeof(value));
     *copy = cpu_to_le16(value);
-    return fw_cfg_add_bytes(opaque, key, (uint8_t *)copy, sizeof(value));
+    return fw_cfg_add_bytes(s, key, (uint8_t *)copy, sizeof(value));
 }
 
-int fw_cfg_add_i32(void *opaque, uint16_t key, uint32_t value)
+int fw_cfg_add_i32(FWCfgState *s, uint16_t key, uint32_t value)
 {
     uint32_t *copy;
 
     copy = qemu_malloc(sizeof(value));
     *copy = cpu_to_le32(value);
-    return fw_cfg_add_bytes(opaque, key, (uint8_t *)copy, sizeof(value));
+    return fw_cfg_add_bytes(s, key, (uint8_t *)copy, sizeof(value));
 }
 
-int fw_cfg_add_i64(void *opaque, uint16_t key, uint64_t value)
+int fw_cfg_add_i64(FWCfgState *s, uint16_t key, uint64_t value)
 {
     uint64_t *copy;
 
     copy = qemu_malloc(sizeof(value));
     *copy = cpu_to_le64(value);
-    return fw_cfg_add_bytes(opaque, key, (uint8_t *)copy, sizeof(value));
+    return fw_cfg_add_bytes(s, key, (uint8_t *)copy, sizeof(value));
 }
 
-int fw_cfg_add_callback(void *opaque, uint16_t key, FWCfgCallback callback,
+int fw_cfg_add_callback(FWCfgState *s, uint16_t key, FWCfgCallback callback,
                         void *callback_opaque, uint8_t *data, size_t len)
 {
-    FWCfgState *s = opaque;
     int arch = !!(key & FW_CFG_ARCH_LOCAL);
 
     if (!(key & FW_CFG_WRITE_CHANNEL))
@@ -275,8 +273,8 @@ int fw_cfg_add_callback(void *opaque, uint16_t key, FWCfgCallback callback,
     return 1;
 }
 
-void *fw_cfg_init(uint32_t ctl_port, uint32_t data_port,
-		target_phys_addr_t ctl_addr, target_phys_addr_t data_addr)
+FWCfgState *fw_cfg_init(uint32_t ctl_port, uint32_t data_port,
+                        target_phys_addr_t ctl_addr, target_phys_addr_t data_addr)
 {
     FWCfgState *s;
     int io_ctl_memory, io_data_memory;
diff --git a/hw/fw_cfg.h b/hw/fw_cfg.h
index 7070c94..b06665e 100644
--- a/hw/fw_cfg.h
+++ b/hw/fw_cfg.h
@@ -37,14 +37,16 @@
 #ifndef NO_QEMU_PROTOS
 typedef void (*FWCfgCallback)(void *opaque, uint8_t *data);
 
-int fw_cfg_add_bytes(void *opaque, uint16_t key, uint8_t *data, uint32_t len);
-int fw_cfg_add_i16(void *opaque, uint16_t key, uint16_t value);
-int fw_cfg_add_i32(void *opaque, uint16_t key, uint32_t value);
-int fw_cfg_add_i64(void *opaque, uint16_t key, uint64_t value);
-int fw_cfg_add_callback(void *opaque, uint16_t key, FWCfgCallback callback,
+typedef struct _FWCfgState FWCfgState;
+int fw_cfg_add_bytes(FWCfgState *s, uint16_t key, uint8_t *data, uint32_t len);
+int fw_cfg_add_i16(FWCfgState *s, uint16_t key, uint16_t value);
+int fw_cfg_add_i32(FWCfgState *s, uint16_t key, uint32_t value);
+int fw_cfg_add_i64(FWCfgState *s, uint16_t key, uint64_t value);
+int fw_cfg_add_callback(FWCfgState *s, uint16_t key, FWCfgCallback callback,
                         void *callback_opaque, uint8_t *data, size_t len);
-void *fw_cfg_init(uint32_t ctl_port, uint32_t data_port,
-		target_phys_addr_t crl_addr, target_phys_addr_t data_addr);
+int fw_cfg_add_file(FWCfgState *s, uint8_t type, uint8_t *data, uint32_t len);
+FWCfgState *fw_cfg_init(uint32_t ctl_port, uint32_t data_port,
+                        target_phys_addr_t crl_addr, target_phys_addr_t data_addr);
 
 #endif /* NO_QEMU_PROTOS */
 
-- 
1.6.5.2

^ permalink raw reply related	[flat|nested] 84+ messages in thread
* [Qemu-devel] [PATCH 4/8] fw_cfg: add API for file transfer.
  2009-12-18 11:01 [Qemu-devel] [PATCH 0/8] option rom loading overhaul Gerd Hoffmann
                   ` (2 preceding siblings ...)
  2009-12-18 11:01 ` [Qemu-devel] [PATCH 3/8] fw_cfg: make calls typesafe Gerd Hoffmann
@ 2009-12-18 11:01 ` Gerd Hoffmann
  2009-12-19 12:06   ` Blue Swirl
  2009-12-20  8:42   ` [Qemu-devel] Re: [SeaBIOS] " Gleb Natapov
  2009-12-18 11:01 ` [Qemu-devel] [PATCH 5/8] roms: use new fw_cfg file xfer support Gerd Hoffmann
                   ` (5 subsequent siblings)
  9 siblings, 2 replies; 84+ messages in thread
From: Gerd Hoffmann @ 2009-12-18 11:01 UTC (permalink / raw)
  To: qemu-devel, seabios; +Cc: Gerd Hoffmann

This patch adds a file transfer interface to fw_cfg.  Intended to be
used for passing non-pci option roms and vgabios to seabios.  Namespace
is modeled after the existing cbfs filesystem support in seabios.

Reading the new FW_CFG_FILE_DIR entry returns a file list.
Fields there are in network byte order (aka bigendian).

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/fw_cfg.c |   43 +++++++++++++++++++++++++++++++++++++++++++
 hw/fw_cfg.h |   21 +++++++++++++++++++--
 2 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/hw/fw_cfg.c b/hw/fw_cfg.c
index 2e3662d..0492f5f 100644
--- a/hw/fw_cfg.c
+++ b/hw/fw_cfg.c
@@ -47,6 +47,7 @@ typedef struct _FWCfgEntry {
 
 struct _FWCfgState {
     FWCfgEntry entries[2][FW_CFG_MAX_ENTRY];
+    FWCfgFiles *files;
     uint16_t cur_entry;
     uint32_t cur_offset;
 };
@@ -273,6 +274,48 @@ int fw_cfg_add_callback(FWCfgState *s, uint16_t key, FWCfgCallback callback,
     return 1;
 }
 
+int fw_cfg_add_file(FWCfgState *s,  const char *dir, const char *filename,
+                    uint8_t *data, uint32_t len)
+{
+    const char *basename;
+    int index;
+
+    if (!s->files) {
+        int dsize = sizeof(uint32_t) + sizeof(FWCfgFile) * FW_CFG_FILE_SLOTS;
+        s->files = qemu_mallocz(dsize);
+        fw_cfg_add_bytes(s, FW_CFG_FILE_DIR, (uint8_t*)s->files, dsize);
+    }
+
+    index = be32_to_cpu(s->files->count);
+    if (index == FW_CFG_FILE_SLOTS) {
+        fprintf(stderr, "fw_cfg: out of file slots\n");
+        return 0;
+    }
+
+    fw_cfg_add_bytes(s, FW_CFG_FILE_FIRST + index, data, len);
+
+    basename = strrchr(filename, '/');
+    if (basename) {
+        basename++;
+    } else {
+        basename = filename;
+    }
+    if (dir) {
+        snprintf(s->files->f[index].name, sizeof(s->files->f[index].name),
+                 "%s/%s", dir, basename);
+    } else {
+        snprintf(s->files->f[index].name, sizeof(s->files->f[index].name),
+                 "%s", basename);
+    }
+    s->files->f[index].size   = cpu_to_be32(len);
+    s->files->f[index].select = cpu_to_be16(FW_CFG_FILE_FIRST + index);
+    fprintf(stderr, "%s: #%d: %s (%d bytes)\n", __FUNCTION__,
+            index, s->files->f[index].name, len);
+
+    s->files->count = cpu_to_be32(index+1);
+    return 1;
+}
+
 FWCfgState *fw_cfg_init(uint32_t ctl_port, uint32_t data_port,
                         target_phys_addr_t ctl_addr, target_phys_addr_t data_addr)
 {
diff --git a/hw/fw_cfg.h b/hw/fw_cfg.h
index b06665e..a63f54f 100644
--- a/hw/fw_cfg.h
+++ b/hw/fw_cfg.h
@@ -26,7 +26,11 @@
 #define FW_CFG_SETUP_ADDR       0x16
 #define FW_CFG_SETUP_SIZE       0x17
 #define FW_CFG_SETUP_DATA       0x18
-#define FW_CFG_MAX_ENTRY        0x19
+#define FW_CFG_FILE_DIR         0x19
+
+#define FW_CFG_FILE_FIRST       0x20
+#define FW_CFG_FILE_SLOTS       0x10
+#define FW_CFG_MAX_ENTRY        (FW_CFG_FILE_FIRST+FW_CFG_FILE_SLOTS)
 
 #define FW_CFG_WRITE_CHANNEL    0x4000
 #define FW_CFG_ARCH_LOCAL       0x8000
@@ -34,6 +38,18 @@
 
 #define FW_CFG_INVALID          0xffff
 
+typedef struct FWCfgFile {
+    uint32_t  size;        /* file size */
+    uint16_t  select;      /* write this to 0x510 to read it */
+    uint16_t  reserved;
+    char      name[56];
+} FWCfgFile;
+
+typedef struct FWCfgFiles {
+    uint32_t  count;
+    FWCfgFile f[];
+} FWCfgFiles;
+
 #ifndef NO_QEMU_PROTOS
 typedef void (*FWCfgCallback)(void *opaque, uint8_t *data);
 
@@ -44,7 +60,8 @@ int fw_cfg_add_i32(FWCfgState *s, uint16_t key, uint32_t value);
 int fw_cfg_add_i64(FWCfgState *s, uint16_t key, uint64_t value);
 int fw_cfg_add_callback(FWCfgState *s, uint16_t key, FWCfgCallback callback,
                         void *callback_opaque, uint8_t *data, size_t len);
-int fw_cfg_add_file(FWCfgState *s, uint8_t type, uint8_t *data, uint32_t len);
+int fw_cfg_add_file(FWCfgState *s, const char *dir, const char *filename,
+                    uint8_t *data, uint32_t len);
 FWCfgState *fw_cfg_init(uint32_t ctl_port, uint32_t data_port,
                         target_phys_addr_t crl_addr, target_phys_addr_t data_addr);
 
-- 
1.6.5.2

^ permalink raw reply related	[flat|nested] 84+ messages in thread
* [Qemu-devel] [PATCH 5/8] roms: use new fw_cfg file xfer support.
  2009-12-18 11:01 [Qemu-devel] [PATCH 0/8] option rom loading overhaul Gerd Hoffmann
                   ` (3 preceding siblings ...)
  2009-12-18 11:01 ` [Qemu-devel] [PATCH 4/8] fw_cfg: add API for file transfer Gerd Hoffmann
@ 2009-12-18 11:01 ` Gerd Hoffmann
  2009-12-20  8:45   ` [Qemu-devel] Re: [SeaBIOS] " Gleb Natapov
  2009-12-18 11:01 ` [Qemu-devel] [PATCH 6/8] roms: remove option rom packing logic Gerd Hoffmann
                   ` (4 subsequent siblings)
  9 siblings, 1 reply; 84+ messages in thread
From: Gerd Hoffmann @ 2009-12-18 11:01 UTC (permalink / raw)
  To: qemu-devel, seabios; +Cc: Gerd Hoffmann

roms: use fw_cfg for vgabios and option rom loading, additionally to
deploying them the traditional way (copy to 0xc0000 -> 0xe0000 range).

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/loader.c |   25 ++++++++++++++++++++++---
 hw/loader.h |    5 +++--
 hw/pc.c     |    2 ++
 3 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/hw/loader.c b/hw/loader.c
index 2d7a2c4..ccc0ccc 100644
--- a/hw/loader.c
+++ b/hw/loader.c
@@ -48,6 +48,7 @@
 #include "sysemu.h"
 #include "uboot_image.h"
 #include "loader.h"
+#include "fw_cfg.h"
 
 #include <zlib.h>
 
@@ -528,6 +529,8 @@ struct Rom {
     uint8_t *data;
     int align;
     int isrom;
+    char *fw_dir;
+    char *fw_file;
 
     target_phys_addr_t min;
     target_phys_addr_t max;
@@ -556,7 +559,7 @@ static void rom_insert(Rom *rom)
     QTAILQ_INSERT_TAIL(&roms, rom, next);
 }
 
-int rom_add_file(const char *file,
+int rom_add_file(const char *file, const char *fw_dir, const char *fw_file,
                  target_phys_addr_t min, target_phys_addr_t max, int align)
 {
     Rom *rom;
@@ -576,6 +579,8 @@ int rom_add_file(const char *file,
         goto err;
     }
 
+    rom->fw_dir  = fw_dir  ? qemu_strdup(fw_dir)  : NULL;
+    rom->fw_file = fw_file ? qemu_strdup(fw_file) : NULL;
     rom->align   = align;
     rom->min     = min;
     rom->max     = max;
@@ -623,14 +628,16 @@ int rom_add_vga(const char *file)
 {
     if (!rom_enable_driver_roms)
         return 0;
-    return rom_add_file(file, PC_ROM_MIN_VGA, PC_ROM_MAX, PC_ROM_ALIGN);
+    return rom_add_file(file, "vgaroms", file,
+                        PC_ROM_MIN_VGA, PC_ROM_MAX, PC_ROM_ALIGN);
 }
 
 int rom_add_option(const char *file)
 {
     if (!rom_enable_driver_roms)
         return 0;
-    return rom_add_file(file, PC_ROM_MIN_OPTION, PC_ROM_MAX, PC_ROM_ALIGN);
+    return rom_add_file(file, "genroms", file,
+                        PC_ROM_MIN_OPTION, PC_ROM_MAX, PC_ROM_ALIGN);
 }
 
 static void rom_reset(void *unused)
@@ -692,6 +699,18 @@ int rom_load_all(void)
     return 0;
 }
 
+int rom_load_fw(void *fw_cfg)
+{
+    Rom *rom;
+
+    QTAILQ_FOREACH(rom, &roms, next) {
+        if (!rom->fw_file)
+            continue;
+        fw_cfg_add_file(fw_cfg, rom->fw_dir, rom->fw_file, rom->data, rom->romsize);
+    }
+    return 0;
+}
+
 static Rom *find_rom(target_phys_addr_t addr)
 {
     Rom *rom;
diff --git a/hw/loader.h b/hw/loader.h
index b3311a3..634f7d5 100644
--- a/hw/loader.h
+++ b/hw/loader.h
@@ -19,17 +19,18 @@ void pstrcpy_targphys(const char *name,
                       target_phys_addr_t dest, int buf_size,
                       const char *source);
 
-int rom_add_file(const char *file,
+int rom_add_file(const char *file, const char *fw_dir, const char *fw_file,
                  target_phys_addr_t min, target_phys_addr_t max, int align);
 int rom_add_blob(const char *name, const void *blob, size_t len,
                  target_phys_addr_t min, target_phys_addr_t max, int align);
 int rom_load_all(void);
+int rom_load_fw(void *fw_cfg);
 int rom_copy(uint8_t *dest, target_phys_addr_t addr, size_t size);
 void *rom_ptr(target_phys_addr_t addr);
 void do_info_roms(Monitor *mon);
 
 #define rom_add_file_fixed(_f, _a)              \
-    rom_add_file(_f, _a, 0, 0)
+    rom_add_file(_f, NULL, NULL, _a, 0, 0)
 #define rom_add_blob_fixed(_f, _b, _l, _a)      \
     rom_add_blob(_f, _b, _l, _a, 0, 0)
 
diff --git a/hw/pc.c b/hw/pc.c
index 147a9a7..be70f50 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -1248,6 +1248,8 @@ static void pc_init1(ram_addr_t ram_size,
             }
         }
     }
+
+    rom_load_fw(fw_cfg);
 }
 
 static void pc_init_pci(ram_addr_t ram_size,
-- 
1.6.5.2

^ permalink raw reply related	[flat|nested] 84+ messages in thread
* [Qemu-devel] [PATCH 6/8] roms: remove option rom packing logic
  2009-12-18 11:01 [Qemu-devel] [PATCH 0/8] option rom loading overhaul Gerd Hoffmann
                   ` (4 preceding siblings ...)
  2009-12-18 11:01 ` [Qemu-devel] [PATCH 5/8] roms: use new fw_cfg file xfer support Gerd Hoffmann
@ 2009-12-18 11:01 ` Gerd Hoffmann
  2009-12-18 11:01 ` [Qemu-devel] [PATCH 7/8] updated seabios binary for testing convinience Gerd Hoffmann
                   ` (3 subsequent siblings)
  9 siblings, 0 replies; 84+ messages in thread
From: Gerd Hoffmann @ 2009-12-18 11:01 UTC (permalink / raw)
  To: qemu-devel, seabios; +Cc: Gerd Hoffmann

Now that we load the option roms via fw_cfg, we can stop copying
them to the 0xc000 -> 0xe000.  The patch does just that.

Also the rom loader gets simplified as all remaining users of the
rom loader load the bits at a fixed address so the packing and
aligning logic can go away.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/loader.c |  103 ++++++++++++++++++++++++++---------------------------------
 hw/loader.h |    8 ++--
 2 files changed, 49 insertions(+), 62 deletions(-)

diff --git a/hw/loader.c b/hw/loader.c
index ccc0ccc..49d4839 100644
--- a/hw/loader.c
+++ b/hw/loader.c
@@ -527,13 +527,10 @@ struct Rom {
     char *path;
     size_t romsize;
     uint8_t *data;
-    int align;
     int isrom;
     char *fw_dir;
     char *fw_file;
 
-    target_phys_addr_t min;
-    target_phys_addr_t max;
     target_phys_addr_t addr;
     QTAILQ_ENTRY(Rom) next;
 };
@@ -551,7 +548,7 @@ static void rom_insert(Rom *rom)
 
     /* list is ordered by load address */
     QTAILQ_FOREACH(item, &roms, next) {
-        if (rom->min >= item->min)
+        if (rom->addr >= item->addr)
             continue;
         QTAILQ_INSERT_BEFORE(item, rom, next);
         return;
@@ -560,7 +557,7 @@ static void rom_insert(Rom *rom)
 }
 
 int rom_add_file(const char *file, const char *fw_dir, const char *fw_file,
-                 target_phys_addr_t min, target_phys_addr_t max, int align)
+                 target_phys_addr_t addr)
 {
     Rom *rom;
     int rc, fd = -1;
@@ -581,9 +578,7 @@ int rom_add_file(const char *file, const char *fw_dir, const char *fw_file,
 
     rom->fw_dir  = fw_dir  ? qemu_strdup(fw_dir)  : NULL;
     rom->fw_file = fw_file ? qemu_strdup(fw_file) : NULL;
-    rom->align   = align;
-    rom->min     = min;
-    rom->max     = max;
+    rom->addr    = addr;
     rom->romsize = lseek(fd, 0, SEEK_END);
     rom->data    = qemu_mallocz(rom->romsize);
     lseek(fd, 0, SEEK_SET);
@@ -608,15 +603,13 @@ err:
 }
 
 int rom_add_blob(const char *name, const void *blob, size_t len,
-                 target_phys_addr_t min, target_phys_addr_t max, int align)
+                 target_phys_addr_t addr)
 {
     Rom *rom;
 
     rom = qemu_mallocz(sizeof(*rom));
     rom->name    = qemu_strdup(name);
-    rom->align   = align;
-    rom->min     = min;
-    rom->max     = max;
+    rom->addr    = addr;
     rom->romsize = len;
     rom->data    = qemu_mallocz(rom->romsize);
     memcpy(rom->data, blob, len);
@@ -628,16 +621,14 @@ int rom_add_vga(const char *file)
 {
     if (!rom_enable_driver_roms)
         return 0;
-    return rom_add_file(file, "vgaroms", file,
-                        PC_ROM_MIN_VGA, PC_ROM_MAX, PC_ROM_ALIGN);
+    return rom_add_file(file, "vgaroms", file, 0);
 }
 
 int rom_add_option(const char *file)
 {
     if (!rom_enable_driver_roms)
         return 0;
-    return rom_add_file(file, "genroms", file,
-                        PC_ROM_MIN_OPTION, PC_ROM_MAX, PC_ROM_ALIGN);
+    return rom_add_file(file, "genroms", file, 0);
 }
 
 static void rom_reset(void *unused)
@@ -645,6 +636,8 @@ static void rom_reset(void *unused)
     Rom *rom;
 
     QTAILQ_FOREACH(rom, &roms, next) {
+        if (rom->addr == 0)
+            continue;
         if (rom->data == NULL)
             continue;
         cpu_physical_memory_write_rom(rom->addr, rom->data, rom->romsize);
@@ -663,32 +656,16 @@ int rom_load_all(void)
     Rom *rom;
 
     QTAILQ_FOREACH(rom, &roms, next) {
-        if (addr < rom->min)
-            addr = rom->min;
-        if (rom->max) {
-            /* load address range */
-            if (rom->align) {
-                addr += (rom->align-1);
-                addr &= ~(rom->align-1);
-            }
-            if (addr + rom->romsize > rom->max) {
-                fprintf(stderr, "rom: out of memory (rom %s, "
-                        "addr 0x" TARGET_FMT_plx
-                        ", size 0x%zx, max 0x" TARGET_FMT_plx ")\n",
-                        rom->name, addr, rom->romsize, rom->max);
-                return -1;
-            }
-        } else {
-            /* fixed address requested */
-            if (addr != rom->min) {
-                fprintf(stderr, "rom: requested regions overlap "
-                        "(rom %s. free=0x" TARGET_FMT_plx
-                        ", addr=0x" TARGET_FMT_plx ")\n",
-                        rom->name, addr, rom->min);
-                return -1;
-            }
+        if (rom->addr == 0)
+            continue;
+        if (addr > rom->addr) {
+            fprintf(stderr, "rom: requested regions overlap "
+                    "(rom %s. free=0x" TARGET_FMT_plx
+                    ", addr=0x" TARGET_FMT_plx ")\n",
+                    rom->name, addr, rom->addr);
+            return -1;
         }
-        rom->addr = addr;
+        addr  = rom->addr;
         addr += rom->romsize;
         memtype = cpu_get_physical_page_desc(rom->addr) & (3 << IO_MEM_SHIFT);
         if (memtype == IO_MEM_ROM)
@@ -716,11 +693,11 @@ static Rom *find_rom(target_phys_addr_t addr)
     Rom *rom;
 
     QTAILQ_FOREACH(rom, &roms, next) {
-        if (rom->max)
+        if (rom->addr == 0)
             continue;
-        if (rom->min > addr)
+        if (rom->addr > addr)
             continue;
-        if (rom->min + rom->romsize < addr)
+        if (rom->addr + rom->romsize < addr)
             continue;
         return rom;
     }
@@ -735,25 +712,25 @@ int rom_copy(uint8_t *dest, target_phys_addr_t addr, size_t size)
     Rom *rom;
 
     QTAILQ_FOREACH(rom, &roms, next) {
-        if (rom->max)
+        if (rom->addr == 0)
             continue;
-        if (rom->min > addr)
+        if (rom->addr > addr)
             continue;
-        if (rom->min + rom->romsize < addr)
+        if (rom->addr + rom->romsize < addr)
             continue;
-        if (rom->min > end)
+        if (rom->addr > end)
             break;
         if (!rom->data)
             continue;
 
-        d = dest + (rom->min - addr);
+        d = dest + (rom->addr - addr);
         s = rom->data;
         l = rom->romsize;
 
-        if (rom->min < addr) {
+        if (rom->addr < addr) {
             d = dest;
-            s += (addr - rom->min);
-            l -= (addr - rom->min);
+            s += (addr - rom->addr);
+            l -= (addr - rom->addr);
         }
         if ((d + l) > (dest + size)) {
             l = dest - d;
@@ -772,7 +749,7 @@ void *rom_ptr(target_phys_addr_t addr)
     rom = find_rom(addr);
     if (!rom || !rom->data)
         return NULL;
-    return rom->data + (addr - rom->min);
+    return rom->data + (addr - rom->addr);
 }
 
 void do_info_roms(Monitor *mon)
@@ -780,10 +757,20 @@ void do_info_roms(Monitor *mon)
     Rom *rom;
 
     QTAILQ_FOREACH(rom, &roms, next) {
-        monitor_printf(mon, "addr=" TARGET_FMT_plx
-                       " size=0x%06zx mem=%s name=\"%s\" \n",
-                       rom->addr, rom->romsize,
-                       rom->isrom ? "rom" : "ram",
-                       rom->name);
+        if (rom->addr) {
+            monitor_printf(mon, "addr=" TARGET_FMT_plx
+                           " size=0x%06zx mem=%s name=\"%s\" \n",
+                           rom->addr, rom->romsize,
+                           rom->isrom ? "rom" : "ram",
+                           rom->name);
+        } else {
+            monitor_printf(mon, "fw=%s%s%s"
+                           " size=0x%06zx name=\"%s\" \n",
+                           rom->fw_dir ? rom->fw_dir : "",
+                           rom->fw_dir ? "/" : "",
+                           rom->fw_file,
+                           rom->romsize,
+                           rom->name);
+        }
     }
 }
diff --git a/hw/loader.h b/hw/loader.h
index 634f7d5..77beb0e 100644
--- a/hw/loader.h
+++ b/hw/loader.h
@@ -20,9 +20,9 @@ void pstrcpy_targphys(const char *name,
                       const char *source);
 
 int rom_add_file(const char *file, const char *fw_dir, const char *fw_file,
-                 target_phys_addr_t min, target_phys_addr_t max, int align);
+                 target_phys_addr_t addr);
 int rom_add_blob(const char *name, const void *blob, size_t len,
-                 target_phys_addr_t min, target_phys_addr_t max, int align);
+                 target_phys_addr_t addr);
 int rom_load_all(void);
 int rom_load_fw(void *fw_cfg);
 int rom_copy(uint8_t *dest, target_phys_addr_t addr, size_t size);
@@ -30,9 +30,9 @@ void *rom_ptr(target_phys_addr_t addr);
 void do_info_roms(Monitor *mon);
 
 #define rom_add_file_fixed(_f, _a)              \
-    rom_add_file(_f, NULL, NULL, _a, 0, 0)
+    rom_add_file(_f, NULL, NULL, _a)
 #define rom_add_blob_fixed(_f, _b, _l, _a)      \
-    rom_add_blob(_f, _b, _l, _a, 0, 0)
+    rom_add_blob(_f, _b, _l, _a)
 
 #define PC_ROM_MIN_VGA     0xc0000
 #define PC_ROM_MIN_OPTION  0xc8000
-- 
1.6.5.2

^ permalink raw reply related	[flat|nested] 84+ messages in thread
* [Qemu-devel] [PATCH 7/8] updated seabios binary for testing convinience.
  2009-12-18 11:01 [Qemu-devel] [PATCH 0/8] option rom loading overhaul Gerd Hoffmann
                   ` (5 preceding siblings ...)
  2009-12-18 11:01 ` [Qemu-devel] [PATCH 6/8] roms: remove option rom packing logic Gerd Hoffmann
@ 2009-12-18 11:01 ` Gerd Hoffmann
  2009-12-18 11:01 ` [Qemu-devel] [PATCH 8/8] debug: enable bios messages Gerd Hoffmann
                   ` (2 subsequent siblings)
  9 siblings, 0 replies; 84+ messages in thread
From: Gerd Hoffmann @ 2009-12-18 11:01 UTC (permalink / raw)
  To: qemu-devel, seabios; +Cc: Gerd Hoffmann


Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 pc-bios/bios.bin |  Bin 131072 -> 131072 bytes
 1 files changed, 0 insertions(+), 0 deletions(-)

diff --git a/pc-bios/bios.bin b/pc-bios/bios.bin
index 29495801950660c19630444e410ff30d673e46af..22a555a2b0fe827500c0a859884bc69290a848da 100644
GIT binary patch
literal 131072
zcmeFadwf*YwFiD?<|LU36V3pG1`Rse0Ye2%EVjf1ojeH;bRd9$4@6-)7=)P25LA?m
zC&BED)7pFO^WNJl<$7zattqv6shA-!6Tm8jRuS479^x4WlJGEufSKQS?K25M>+SFJ
z`~3bqe3*0g*?aBR+H0@1_S$Rj2!i%c!+?eX4FehmGz@4M&@iB3K*NBB0SyBh1~d$4
z7|<}FVL-!xh5-!&8U{2BXc*8ipkYA6fQA7L0~!W23}_h8FrZ;T!+?eX4FehmGz@4M
z&@iB3K*NBB0SyBh1~d$47|<}FVL-!xh5-!&8U{2BXc*8ipkYA6fQA7L0~!W23}_h8
zFrZ;T!+?eX4FehmGz@4M&@iB3K*NBB0SyBh1~d$47|<}FVL-!xh5-!&8U{2BXc*8i
zpkYA6fQA7L0~!W23}_h8FrZ;T!+?eX4FehmGz@4M&@iB3K*NBB0SyBh1~d$47|<}F
zVL-!xh5-!&8U{2BXc*8ipkYA6fQA7L0~!W23}_h8FrZ;T!+?eX4FehmGz@4M&@iB3
zK*NBB0SyBh1~d$47|<}FVL-!xh5-!&8U{2BXc*8ipkYA6fQA7L0~!W23}_h8FrZ;T
z!+?eX4FehmGz@4M&@iB3K*NBB0SyBh1~d$47|<}FVL-!xh5-!&8U{2BXc*8ipkYA6
zfQA7L0~!W23}_h8FrZ;T!+?eX4FehmGz@4M&@iB3K*NBB0SyBh1~d$47|<}FVL-!x
zh5-!&8U{2B{Qr*u*V~r|4Z`>94LK`4M%UZ@_=qOD-WFm8!PP7X$-?(t%+MgT{!!?b
zUT@tdoXY9-Cbx<Wr{%7}o~SwJjMvD&I&?kK>-R4%^^bQxB?&F`sO^+$TG8Sxy?>cS
zs(lqfHo?El?0;I!?DL!d^wKg($j&uZh}pUdW05?V;5``~Tf5scy0*=eoRw?zCa|ZB
z(d+yvR9JLER<1}fV$_(GYxX9wr_7nVqbC1sOYLs&vFJI!7~lmusX$AGF;~7w1*(NP
zsjwx+=xtkgS=VMcsjMYpbYhm%Od)f0oZn%oZS#H>O%BYlutSl%W3ku+4=-<DT*}(z
z{-jOT<2P*|L|ok`2SPXXp14VFH%7-D-x8SH&!c(d7P;LmHFf&-psT&i`d>6$4?Nu7
zdi;PS_>;4O9+B;d_W6x0IkF#Rv3;$2Q4qS@Sy0;E85@JT<WpuAV*5e`_EAFML3?sb
zGK$FTyl_U|kx@4eh#5UM+6!RTtAx>*{Q7Y<o!%aKry14A1E#73z(o!6j{5-<c@+?g
zFedUTk?mr8*~j(Q)?iEqbb?SlFv(*im@a$-s&tv1^@)MvebpCDRVihi$<p?=z(W1L
zqG%*%jn`0ApO{lF)oeynHciTTOsa7r)21;wlRQ&%Zj)+%hOfv%JaSe_wSK&#lXJYD
zSvea#o}5al_9;qUhDYlp6u=Z^G@2DLA;O<s8+&SW>ohg`0x)vnQ@LGa0{}XMugGzv
z1oA~D+Wq4Y_xGW=)(kbvPDHeBP{Yj>HX@8tJH5C1P>CQ^C9?i)x@a=%4=R?{1f<SH
ztgt>&-k}dFM!DZ2ABxS92NJ82V)h^Z>|RM=1HqGNsOwD>N8wcYsD#f~;-6Oa^GESd
zi~9L|{L`#{R>nV#>gUS%r>K4|!YA*g`dLJ&7ov}<{gk#-M^Al8asD)WbS}G4{hY4S
zoA1w#j-qi_ln;?Oi$)UT-Yy27(?uuyv-x)dzN3Fsp?*V9QDq3{zo5^^Wjy7bBFOro
zc7L&$U2LpOs2dY=i0z<~%-t^k#yQ_*gRWq=k)5l1usDTX!gDlclGS@G<hWD#!!1!`
zsKA&a%=RQzZ#1UZJZGe)<X|L8KBB8D*0o5$t<?03SMaLaBW>MVkuclam)R*bb~2}t
zCesi#2H8h-JLIEDgL}Mb#ZpsSu*;ZY235B9<Jq%q@KjCP27??-@+V^K-=)ZGvwdTN
zygL?sRBHMpc+AKSrl6K;cCx4SGLl`Vi(PX6m+Mpdf=S*4IcSW2kQ?0#psPxiyEYZe
z{kp0fkdTVp+xmO9T|PZY08JzaAjoXd{+ymAvW_7nVd@xJyOfDmu!VL}dUImiKfv7-
z0|@ybP0P%~I?+DnLAw~$pL<Elyj8Sc4>);1*x0)%LGBmUN93Kx2jcxsWd(MT{WY^q
zo@sv?xbjSFwSXp@b=9$$t7qGoQ*{OQYv^&U%a2f4w4;kaXdChwTgL!2;IUhyPZ5ZP
z9%D}VH`*<M<zGrohilrrH&dK+sxI+VU6C%Ze89yXv|FS`#ATymuQh5qHCMhA^InX8
zM`|jtTeB3;XylCQhN9E(6-b-FtBQ)J>U6nTpLqKT))E~X!z>i-S!jw>`!r@3y0J5r
zlhW|0`pZREFl3B(PpWwy%~!iP0U=ipI~Lez7q^X}vJLrJm%RO%hXbn}Qqy4ccJ{$=
zwTVSp-QIrxe39(~VesLR8b31a%j$nFsTsp0L~qOYTkS|yQrSnr6RD<N_L1)d4P)?x
z(bVfZDj*y@X+)OxivOjCsx+@Q)S?m`AyuWJ0=t>x+AM^Dr)8)hbGIL3>N|EB;ZYCT
z&Fr8`nf^5x+|LXy->%DMcJh?mHAe0q<GHOxunEF@f?yE*)9vS89fEH74m;WHLZUy%
zzMWFfz4`}TH07$~7;5xkpsNKz25uhlZiWOL(@fvRAv{27kV@y#9HVdV642~+nhoqA
zJKNLpC585!VqyN-kiqtJ%b#1k;~=*s0Tsq#ErJ6e;d8IbJ1u;uFwfaXSvx8c5&1vS
z>jU#+x_!Ej*oT>&QDc4DHFas0Irr7ZyyvHM&~znngqp4Xh4$3Uw%Sh5oxsz@!=nWd
zmKd;(!<;Y%O6)e)1&B1|rHio`2v@|1F>7CiA&?gf3Br_vB%ay<XGDV7{Qd?>P*wpH
z;;!COJ)rkYt4bc+Bh_{Y7};^v0|w8=>H$%zMK^@VYk2q_qTH72biW1u94)SQivA@9
z{_<j}vDi3YZcA~peR7x1x$h+S%mVkj08)Mk`Xr=CZ|oZtJUL3<X~mSRx@IPq36j%&
zn1CJ!(6Xh`<p4?!o=kSSBUHY^%Qv<R;-h+lS@0&bTtINX)VTNSm8IN=a&AUBm<rKr
zs4ecvh>C7?PoWeeQkFn65BI%;`o6j!eJ4_62e=@UFC}`C0@nYspsP|-FG$$;0fN=O
zqeOnDkKW@W-pdAh-X&JYPM&7;!8*YF=9juNsit4>Hb4siXIG16ANW&hz^vqpH$Io*
zE+8N;fF6hzmMPZ2yW-y@VM?%Ux7AVBW=)_kHlX|i@*$Q$x!8a4s6QEzfFb1+z-AfQ
z{bqcnv00p&c9;cqMoney>?0&NFu(<vS2hra9pPfU)BPoOyD2EuT%*TGZnWDlhwQpf
z$9%!Sy4V^N&70Xw^<ny<gXm(3U5rF20G>0$?<SQXVsIMA6`N6FDw5OWHfz=g6;hR$
zbzr>-lgJ!-o8U2pP^QsuwP$r#JcHCr>%C||diETP_d37FZb1vIw|ea2^&9O*=0Qt0
z+U?P0>{Ir|t;l;l^0KFm>~S*{iI!Tk*4Wc3?x;#e?=0Ybsp}`lDlCKpbkBAxFav&{
zy1<FAG}L25N~-b<iFC{mly5Ba*v;0!FR6D(Ghe|r0MQl^br>UWpy?<<%vxwSOD`s2
z5Tft-4gOM!uu9L99$A%)+AY%aKSJ1$ZyZ-@rnHK0RV7k<#r3lpN8_y}b~6SQg{88C
z%IM1|X~8g3fN<&(+s?=K_cXRs`X`)Z`9@YsolVa!vv{+07{4(XzkgcdJC{&msybv@
zs7rcrAzC|B12|ZE%#(qRrh^KK2}Lye7&8aPtbn?RZzCZ>-Z_<sHF6(UNqCsZiG9ZP
z)ttbyMpme>18m+we-bPFi+_{Ip55n9X7f7yUL`n~D4#I+3l+KR9#;4_zxc&IOf0|k
zi@)GiKkskS@Ae%y*%!1y-`<zm3FgpBQlqv_s{H{1^0Ue&$R-NK<?wZ1mBWQ+Pt_Hk
zbNLI;h6}rpl?&m*HZGx<_x(sBGW$mXrU$=X{LZ-iP{+CrF6Ql#n)(JiyoRXx)V=Z`
zq;2G{D8OI1Z%T*UZ>SpQ_rC9bfTrUK;BrZX)(Y%{0M<1SijaJR-hR~EBP*hd74}Gt
znb}^2RDi-}kA(#xt7pp>snBXFG&@iwvhURA>go!^R6{Q-Jnk=S&MG|q?DbNk&grg0
zMQqVK%G0PzzEym9xqs0+(PDteZ6aWG;VZRDO@%!M12ceS`wf9|9s7>d=nZFkk5?py
z96Brr{e=f(NSe~&pZAw+-FiLK#R|Lpg<V;NKx{W?9zFBV>&PDEnSwFMY|HG#5J)e#
zNk86kpzFX<lR8Q!b(HvsMD>}SY+qp2d62^H9Y&!v^YHPNuj##FW?S^8<~z_s<>@}G
za(tI8w+MpwnETg+x8Dz-FCDRELuwT?H1<~(3Jx0O6H>6>EO$wuK2iBSQDzv@^WnOK
zCst-2j#`xeKolbGt1p-+oOmQZ8<TY7Nu<ok>_o*n?-X7sv)UCs>IE0c^9}H-kGOYI
z)!$L8UK&j~{zx6l$j>^raVP619dC&9(qij_`s=DMN$aKg?k>vpC4}7r4@Vz_2nm>t
z`E}P}EhgFnrLk<Qy<(Eo_)M%URuXu#WIu>EamEYut{Ck#`kxiEpA#!Yb|88nYp=&V
z<&!|ZjvZ2FKz{hT2`V_KUmd!BPg#1ML5{09SBsj#GqKpf`RJEJZ2DuiD|lLznszv)
zrd>|=MWPPOV&ws}@a@UKx4hE~9W&8yw$BZTHwd+dy%${I%HJ0BE&$$4;cK9*;&q++
zG77!Tj`t<O1(YWTKZ9=dvFRix{AAWOQz*w$E7^UW6F68&gVC#0|BdS4)1B5F7`cyK
zz8Q;N_pYyZ=xf?M>!e03227cqnSD`FZ~abDR;Z%CrqlB<$#!R{`%WtBcR&CL06I-H
zPio4)E+86wGwjZ_PA{#HC8_DdR;W!-k`xiON{#t?6qyi95`;+tvg+E|L<>v`ATk4r
z!N|2k=W2|GRV)>wQD9V2ouhh&;2oH95M$NqKzRWujB`Sw1%?gp1tsYV6y4MYh1SUa
z5qT5o_2$I-g-J%ojQvvWkMW%)+P%@pD+sY*Fp|o41dpbg_Ol&OPf1ffYBcS~iWrKj
zVl)Mtg@dDonWVU_PvH97l!IBps`+4<=C5eMoL9Me0#heMO`IWdT{`MLSG)VUo6ts!
z)4h(c^uh&DFa|fXa|`uW31Egkw1o95^Um{@164O>wnY{LMShMCu;n4u-E%NfjCgrx
z@kqM%TU;{KHOVFKsFrF|!2=@~(L1PT_2a!FG?oELdO?S1sc{c$_eD90Ued2V%t`d;
z@4*U^SH~gci#q9tA0w~Jzu_*wdxqbc;{ww4{&I)QzvOP0-;w76+NGw1(I_|A1-nV`
zs2C`)%yfkv37|arl4(Mxe6(LaIit>Lbg^=?i_Kss>zw*}6jSFM?aKPQS8`=t@Frsx
zyC5s|p2q=Zs#`Lu-fFLNiXn&Lm3pUCXSHV@&g|5uS@Proi}wN&(+|}-rP|%DEmXHR
zCD>(=J7#Vb(XZ$&{A1o$>N_k`4ooF1LM&)t=I;0mjJyP)J2V@)FiRhr3g$^dZ!9*G
ztU=x^nnRN@t?;sA4$bLT=g`eV!0~xA6{TTN^-9qvSSfNtlF_{*IvS$#5z)Uwe5hUC
znNB23E7jnLm1+vDR5LquW;=wr7)?;hX)cUhp`KP(s3*X^po(K9R-VMpV&(nRY*TwR
zmWgBB&l4Tp143^G!J_xbp3n;sd;R$Hc+x8OTD1&|`)34d1t@XmXtJV5ZP5nIW~jgF
zydu@js4iwj)_!FPuP$h?oZ-stp3}6P;mdX`abO8}ZIe`cFVOAVn*j=AY4*2C9rj~E
zeyE25dY2m9c9{%7v7X@s`Ln@*GbRswDZLOu<Fj^2HAnCc)CyP=VIgpjPTIT=5qx2X
zTs=&YJ9OJF_pol4@9ssfOSRjODm4|Q2E;_)3}^oA1yb#QBMNFn%};rfGckA+46j%;
z?a3POCRT5-3Z6058^#M8o|c*%pbC>N6x}8@KCBNOGx=xIEDTt)zc$mecC5c;vHSOg
zzys&7u0Fi<;pimxiSLpCbJqHV7J5zD8;t1By{h~c>Jpgp5p~86w|(1Xrt~0wY;^L~
zanWnI!UYOod>KY6SB)yf!0Ja#?y0a4empD~_MkC!BpCA0ppk;1{_BEaB-2Np>xiOn
zUiA7`=y)Y04EX>0kFMhXn9Vl}y)Ndov7^3$k@8|X;FV%P6K#_TGaV+Q_EwTnG#!Td
zaC{ooJ!rp%f?``zsK9=s9*-MzcwDDzHSLlxjGamV<k5#Yr}HGakD`B3Yi*w=)#aNx
z_^co-dfk)a9z7pJun;11NmPQYZWT7d640g`24V3@7AIs6YX{fAcYE7WD!A|61wHgW
z-ArvO4v9&$VCPb^LZEh(>DXCtU9x(j`U;2lmZ4sxU)75eLC?-ApQAD|*%U_eY7ak`
zJp}r-4pT2TQ;)9$6UFNqXFEHo{Dztuy(2<%ol8g$A7Y@dr0xJWHrE~OuD+D)%@`_p
z@>Ok^!&{s`8l~r@v?j(eSBg?OJnOm&+RmXTjt276hJaa@V(0iOd4S9ZMrL8f;I&3w
z*pZxfUw$!0d~~TT?6Bl5aps2|Y4l=FYuG_7RR}w5^s0B7>K57!#F(K4fHi0Bsptn|
zHxO$!k+u~diZoE|LM$Uou$a2Dgyz@7r{rV3S?8*Z*%OQLT`5AlOJox%4fEsM{yQCC
zfyx;HMQOE%rJ5zgZ@#qROR7DF_H0Q*5b_ApIQ7CI;$yc$&fc`opOQ)mSgmG@_9|mm
zha|rRaH(k~7h9i;QscFNwzB=fBgp}47Q$v)1VJ2`y(T|QSO`RENo}SAzXbt2NdUuV
z2&~51lEMar@hyU78HM#rAQH!Mk(itn_Re7g$SW$7yD{D#yLi7llSnww1CfsMf=aS$
zD?zItqH8NP3k)HZrBII$ZQV*e04wk>qGeg?g@bJWttIGNN7lY7b9SLvfz_801f8DQ
z=@);@cUYFt4ohl<5dxETSZ;$N@$IZ7M(-q6Zj9QPft8Bkd@_B+SfyFr4`QVjHj!_=
z=*b$FHiGexb)WsUMX-Ps)1$cn4N@k8hFCjFE)G;vEW<897vD!wwMrvbqaaQFdQ^BF
zQ=qZBKR-)i@lnzLm>Apd9|h?M6>!rDs6Fk`1g6BS_93}UnkTwz_QN7jH&<k(P$95(
ztJE);zu3tRPJ0ouGuW?R-S*qpUw_@{o=aH$9+1oqHLo@xoJ;eIte;r4w4iwc+tEzq
z5?KZQtcp8J+4%Di^j6=F_mR$lnx|6N@&Lki@rYK+s>V*GSkaCio0=)M_O$mVcNNw9
z-f5&@2jVy%R8ih(CG16B!gn!9C?x8+g)ppNKF_(FJuZgwjJi;sNvxlfj4?~I>#YU{
zHafiL)A!fSO>UT494de%8AI9^E)<;k^PHi=L@``wq}drRG?(T(7X=C}+XJY(g{#pp
zABGF<g3vX%ohB#im43xOZlU0X9e7wgQZNcL^WNFgySsA_oM2}H4^4&n18Om*@BFu|
zfEiv)gc60i#kx?DevCYzn{Ze@rq3SV3p7dp20DhNRjhm102~-uk;tAiMn{K>L?ID;
zp~$F%`A7~~b$hZoUMqgx46#W3Hj(q&P@*neq@P`yYjcH*5^XmBOe!`|WaN87b3z5z
z7)fvM3l$mlY@p7m3pw;-paX(0VNSFS%58j>`6rTP9<4XCAUH<}%Gaso>kM^E6Ig#;
zZerciBp5o(f@hLyHqZ~5@3DRv3nr5o%1zQojq)YE*C0oX*o?@RFIhZEyus1mg>+&l
zS7&gAbJ3$vu83a(eu?-c34vT=DAx#vsndZ|5&)VPasa>q07sJUR@jti+1K~y_uqe?
zb=(TH1^W$wf<!VG+$;wzt|<{0n<v&klq5Bs!8)ofnxJ2pAULvmD=wrTsH5oJ^A~|z
z7~Q`h@_Hmnq-^6ea)^{|M9RN_nxK+$dNZjY%0FmEgByW#lHDQXjhw}j3bF^Z!QVD|
zV_Fd=(-JNt5fqIDsXYMem=j{#?u0l^#XKTYj2RRJ<8oS{GBsonLixH>S2!O%W@lP4
zB7)L^i3?H?p+i~1`Kfv99&=-8#Y!Pic|#~))Bz53Oal6sfDBAcM7yML;t064iJ|-i
zXxRCQg2E!45CC0H(4GVuRm=8cMCGGU4C^`fKWs3RZ#0DRO+uhFd5FCD?79%jPd0|~
z$D*0z#K2r@D-pFanYYj@hVretz})ez<JIO!!_ngbe@!fue{BqOUj)u?XT2D)G;GJ%
z){DTBEs&?f%MMFn+7O~*)9oBp%{0T5lc!W{%^t?q^&x`}*t(u$i?Bf0YS1Y^`)nk>
zt{;Ji%9}>uOD(qS3h-4plS3S5C>65~J5$tzdsNsIT_}{FXn2o!Lezwy@E%5sh6@87
z2eqo8$-2-iOtR9XC~yO!E;Gi_uNK%1)&=aF8!T6NQ7At(5k=8HkqWe%19^B+{dM^h
zsHh248x)>6$o~$51ZL^#@~<P1>xBO=sHQ$Cn=lj5tY<*MX(7RYIcVi`5FrquBLP1?
z2Qd$g_?Zx&jNd5y%=)l{_L2}i20ze=W1J9hTDJ$Vb<jfiVIQCSAGz&%2wywfaVzFS
zHjJa70Xzfqb$Hon(qJ;tI#Y;Xu_q8AAbtS|V=4uj`Ly`tq)HHf1O#lhX`w<v3>E5Z
zXtn4{5Qq)vLxpH?VS)ji9q%MP$0)dVp^+^zhYBr1sBjFl#=^0rI~H2^CE<C^zNAoL
zYHp}-0ys}0x9$|Ck&UPD2F#a28|fGBZcLZQ6P?O2jB}uHvf8sS?<KmoYZ^#=I#WR6
zQ{|nOuTwdiOZ#2a)a(S3j?(69!BqScjbJ$bJI#2qv!+8HquegYAL*h-|HM;(%IuTg
zIA;xZTWL!tA$AW0L8pLSo6*6Oqk%Qc*Jch0P^BTlhw}k-I4u}Xi4P}2d^j;|iHYn`
z@Mtn~0s)RugE2JUg2hNmz)7Ikp+#Ohc)iV1WyH|f#-LmW&DTJlo`#DQZ&4UWuhGJo
z%+mn36eGbp*LRGXnGZpd8X@ezEjX~f4CA|31kXz)hB!3OX?UBdWMxp{Eq+dIF{G1j
zybDbljV6JMK@eE*G&(S5j$}OHwGwiSHigj8ki!D%<fKPk8HYuZbNu!%h`9|BA3G^H
zuM0WS1i5YEKcm82sIi;|zt%RCCMb`pZCk3gZ5&|}O#`(#_3R`JTg)l4Pe{vMm>k1q
zKN?{cfa%e?e~C-DVu1Y9zE&+~vC+>tN}f=wwW8W_?4--LL$HplId}~9UdQW=<BO}=
z02w_3Gr$RkijafS_^?{lVI{uJhc(`mLKmoXG(AKNnMHc>ZfK)lBQhJIWv<%3d)4;Y
z(7sWqLNC|?#Uf{+STK#@2176l8aT)rxh>_N4ZsLCklBX?rage^0v{k72&I%=WGAtF
z{u@L~k#CTE6}-w&eDfx1Nl=wKS!zo*p(P@3$)<pl0^l7(y-rYjO$>e{F+&%&V@E0t
z^l4MI(;ESyYNtOq%ZI_@z6_F5rX9n^Y2@cf4GYUl=Pd_syb+U05B&rLvBXGS4LC=I
z@}RopLA2-T@za4wM`3|ySza)2cF18}?!tx})b0(}V91QjnF{M%TF7yOy?zOdX|Twd
z;}*H}y>&~(`X%F~#_|NY+mg9EqZ2Aki3O{|vruV}I-ax{r~8HlXxopDk~)L!B{GUV
z)b4bDmtvnmtUH%NPpauKDFo)k<cmq`tqa_+><G#dB#`Na?>N_|yg}Tl5&j+WV3PF0
z%jj!v9gi&QD+&CPESoJQh@2e~M+tC1yHI=BQ-MWFXfq{&gF=(h*Oi*X`2}Ebv2Z?_
zQ)7Pduf2Q0<ML-9bRHoW%g<q-wEhm2HNT06(h7R2o=M+2?--YyV!^oSLJ2>_D=9i=
zJxs4WDp!rFVh3Sf<3>hf9kyWEhr<TIW&u`>3zNtQsDp<Jrm7rHVgsk@cHDG`otd%6
zn*iHfbm~<G!C_<GLxhl7N4O1Pc{EA66Ou8yL*~02+!!;`)VMl<DtU>RoFk7+ju*~l
z_EDV>7~kj>10^)Gv$+}=<fTSt06U~?vIG7NBJ1C$pmk+!W`6^%#H6Nf7Kwv%I||gt
zy5AyieSQKPkdNxBv6hI*pZCf=PPywoQ#h~~E-*pX-<^4}`iR9d3d^S=R8ZTtVMG1g
z#OjOFJqgtp?cSRMi*=c8-SzoNfyH{fjDf`lyi9?`B3{XX#R=W@2EgD$r$Xpe2t*Qu
zNDzU=Np&6FsNp!61ZueEH5izhv2c$?N6B4qG1E<Gle;dBSn;Ou4F;p%VTJ*DxTh~s
zPss?L=<+xJfcLu6;x99{kdlR|YyA0zix4fUrwY&(#*WNJ`&g+7Igra5C?e%N6`aM)
zdPr;}y3Rde!0s}I$DTsGbqIxfvDU0@dn(a2rP30;{a!yd%VF5?Ovqza`y@tV(r@%M
zQff2S0I{f<M|u*PVUxq;8o7G6qAwp^-4mC;nwn1=LWz76o9owLW~SMp0w_tCEq&|@
zb_TXW$v+qJw#2S?`7XxbpFt~@m@YKtV;NsY9}pUo))%?Jne^N#jq+IFANjHL#$al&
zCzTg628KcOket>ieVqJfkwvI*w#x@KB?k3@DeP>hz-|)iQ5TYu;U_gJUXC%?qh=(>
zODfnB?6L5YQlMg_k_TXyBzHKFWi+)UQ4Z-FlG)jA2rQF7->ekU$~_3hadfLd%a?=7
zcr=^^8;k%VS2Dg{=LRd^sX9P#>%#ti)ws|~TqN+KJsk<dvVxB@^bNE=##wX(+O{x6
z31*^%kKz;LXPj)vXf+!kQqx|bGnI8Hw{m$c)g>a9^`h}N<_yn~KqcHF(Ks**h&T|B
z@yZ--iO*py9pMNdf^it*lNev{bug0EzelzDD<I2MCCEjfRQI1)jqzf+ds?7U->`_V
zG}qAZIvkU*vw%imALmpKOzY)<t%mo*BB^#2WxF^711r@oMHpq8S&e-v@BxS$1&@Rn
zn<ER+Qq5VK3u^$N49^?RA>uSAw_#GCmWI)wd9k}0#R<xcgRxjcvKoOx1*H>`5-w-#
z;?R6}8&pm#r5363XFAVvju;Egs*!9I${o;Q4XjPv-hhFD6VAzQ7<Nzb+#BY?A1tTA
zGX)$KfWQ>F9Bn+LV(Ngqj9BXV!>~m~ZvuO2c%{4g9X{xK?-+KG?=LnxsCBoYxCZVi
z)y?NJoJyLBuCP=R)4AEE!CD-u5k1rwP~Eve4KD{ct45S7Tw|}nTPGkuFtnUNa07wk
zAC{Ks0Nses)-Cj{LMhY0v1nCJ{w1%d!mnSBLG)E4!tpDLp-t*05^v2!v%{7bSkagJ
z)d7Rm2D2g^ipm>*jm1KICmV*2BE4V?7pa1<hzmlpa8HrDZj}2I;2=;}WUgtGYGz;+
zhV|X=Nf>@e!ti%p@BzLVv4PSg>`O^CSqK9usUy%8!-g)6-3>_k{}oTvkC#<EokDkq
z@RR^Y3c}OxfxtMPdbx`5Ux<j~X-GpD!jpkpkZ6w5C=B5W;)Ciqs8s(2xZ-*P*(#tn
zxIp6HcCj+-g_hWFBL)ezYVO_s0{e6#Z)i&Sd3`nZ578{qWAVRb??uS}j{Q7d@Q8oQ
z{t5z_u)Y?sXNv1f#kzfMie7HZk~^wTlplW*oI^fp2$;tn=$E?;b@|^V5UhN1^is|H
z$eCl1YJ7MPc1X1c@QyQMLA)fax4sucOlvKuxfu%_A<}_I3x!xO`NP5uLrLZ^u9?+B
z)#Uf8kp$0NN7eQ3In<!7%JQB~4O*%a-lMge)b!y{_A5n4SG&j~5^P~HXqa~8zKr#(
zPuL!VbsO6*!4u+pSfQ!)USOffcLC+v-@X5HmmJ%)ehjdc3eRYiz`9!*+UtVeELQzJ
zk_tGACIBS;a3~2y3sAG9rjGe&4}KraUqI3|oj+6YJiQ29WGeKH1@#N<8F7EZmysWX
zlCE3}KI3A~%zzpBE|i^4y4{vkSQF))={P`8^<Y_t*%y2ZYh1@xie?|M52Jb(3KX56
zNwF2zx#Z{0>%HUrPO*N}jO2=B?@|8(F}qZ(Jj5<$4Z;EBOrXfj&MM#gh}PwadVxJG
z!ZNytdH||A3T$we>9tN;@hM#0a~<do{BIiDz{<^7&hVWEa8kPzcoVWbIw6jpy(l5_
zH%KkQNn`*4-%gTLBa{{k33~RSzu4^0y`r?d#-)!c@F8Gf9x1THR#{+Af;%B-%E$&>
z@WVyOgvew{8TCq>OGAp1YN97WngEIQB{q+_9G&xrM0Rqr>)bk?d`fEi^AMvR8wc5N
z3zV!;fknDgEu<qvQ>%{{y-6()#86h?fr3f(qdrvzt5uK~RvlpZ5sMZx5zbL4@5x+w
z4~cM7EVi({u3*%N-K-?&2u2*!*y}q6z!<kbqz1cFk)&56NvnWS!V>JZAkx4iF*A6i
z5vm9xMHHfL-m;@g6WS^BQyQe@`c6FvgDT{qlmm|m7g1efTm8?7=~Z6>&t1r44woG+
z@wF4fm1?k*60V5r<~l55<H|k69SLceAZR8Dfp_e8qwK(2b}PN!usiYMGHF<Pk5Oe(
zvb&RpUBYx|CVUKUU509S5tB&H#I5V>KkYV@L&C+5w@zSh*wYYb!4D%1hW`=QDZPuN
z#v1!V#0I-krN)=-izs;1V%kR^_v1qiE#}ei&jz!i2G+l5pHHus?F;adnx4^T^-DGX
zK;hg!F5bQZ$a6@%J~WUr8Stj6#{QoTeMfC5OkMDtMMJ0YhDx;xMx?&RK1Z!~E?zlz
zc`a@QI8jQ#k(WhkkR=Cx$aKC3oXCRBz&|2LuFAi~+dZljppy=O8<8Gmgt}mE&hU;H
z7$XM8jDfKN#ln)vdSr6CzeBltI%6@u%iqiKv^#jjV(Ng46FCLJp~U2L-$!5_0E?O*
zkGWUTS0k!gvW%Oa12y(^w0L+o7UMG=-xwZ>CSwwUQxT+pG-@*t)(MztRtU8Wd?@E2
z@cI4@NwXfb@DC!GhZUVXiVr}JZ}y?q`sBNep5zwNq$0bKP_tXA`2g=cNAx%!eafVh
zYJW#1nD8+kCA@+U1n+=)N9#fazXPSOmOw_~V|txb`z$`dMemfF?&N!=C&ap++=)0}
z6yq<jUrt8Y<zIfY3mYm4Z@0mU<zm0gpvds%+wdYPDX`z=Vw>;47vy9P`@y#nVo;^g
zy%F7)+YH#sb3y4LB;bTY@R$gE5fb8Ptb@PbamaPf7HZq-t#+yQ@2CMsY^?Q|q_SeG
z+f3pmV|Qd1;#<hnE6?mY0Qn=;{1G2;TCXYzaTrKDb%{=%?Qm~5c;J|@IS0AP<scp$
z3ppJR+Nno(A=ycR83^cw=v=j|YMhC~#IKikBD&tci=O}9jwg<!9lHkz;l(!Y4tD8X
zlLYJnVb_T9!lcF>4g{&V(B|oQ>Tp=j%s1_#3H(qQ>+tO)F2s2}%uVDo`~ZmKE7*&p
zNZARsl-m+PE;R;Fa&$YlJCys!r$LxOY6g$!51hoAra9T;t%#|Z@BVM1T5%uThb99@
z%V5hgY*(En`l1QoEvjBb*3(<KCxMMSG+Ym9hNx>DdGMP!sC@MIc>ZW-*;#YomkY^M
zJlBX8mqVAmFDlkq9JyKjp2Yew7_YM-j4GmWSb!>j;lo&L`4azT$^<P$@3B`UyNab+
zAKDWgjTnRHTQ0e++FKc2;U8~9v$0>6%zab2aYA_>wMQ4j$xyH4b3NaK(*qq;^i&kR
z^nvJIQqy=&z(+-w|9K)%sj;4Dh1~r_-_c%31-N~ox>5f8xVu>9Zsmo)#a$}U*eS!)
znEE|W(6>%e2&0|KAwbDH%P~al%>~O)=``#GUvY|ag{vP%O|%CVS%)EMb`p$<!;EMY
z!GIW^r#JksA_V~DW5?aFEWW*)t1)3jI~W9nB6i3Y?;+XAj~ztegBPUJS*WENhYt8*
ztJ7HrJ>vqoI>@zKIcV+frw-z5*3h}B_*$2YX3gWC1h4r4EtjBvkfQ!8(41;sv{O3Y
z62JW)Je|&8Cc7^KyOGnF@Xa0oC~g=VS$m5EVO8y?%}M1;j0@Y<Y`*~zMS!S1?MZ<N
z&cs1b%viU5A;9Dh$f&o3pAEnsFbuu42OKUGigNQy!-XQ1y8VBEwHAg7>7dLu4@P4g
zx7e~WJIhZG<xj<S+caPf9Ux5P02AtIplz2=L2g6OyDglbLEd7a{OM;x`FHk)^JfSR
zz-hii<gXGVUZMOY*q>Ue59L1qgKYjIG3+tqKN^$5`OdC4DfvOTO_Z-fF)h^bRx}Z=
z2uc%Z0NV&NuzdJ2RJmUNOxifX@kYR`PvEL{Sx-t}kr*hvm6r0#_h85**9pvLBLrG5
z;o+G-W8oQji<;;#;b*tV19xvS<<&VS1ss#3Fw{@l6evs#_9xcmPY&eY5)xq4)j6?8
zz5sjV%jGt>5=0*hIR+jGIWEZ|$K_EW$Cvpb$Dp%sN3Z8v__tgX<%=dL7C}0G8vI^e
zaSXe0j@Tl$Up^vTon%yZ-%+WdVZ`=!Vjc|Rf#QLzfsH?z@=0rHX~9BtzZpwr_TXDH
z<V!mFAF(ae_dw3BgXjsC-X$<m!Wl~ha=h2L7g0}t^gfOFa(=$_J}`q~oMyTZ&Ihe^
z4Tkg6X}SbTr>aQwr;v|8W*Zh*=IG>5LHkrFsO{5?bp`FW;deVWu*}lG1=*irN1_VX
zv}ZW7`n?|oa(0B0u*In}Z=nL}X6eJTz^2;<!?Qr#sNg>H(8+?kzwRP%Ycrkc#d1E$
ztZFl}%z8KkB!_YhLO2)R90K@XE((%^$+UGOyk{GYiMusiX>X;R!&ah@j_0e(HLzSz
zR4yhdvT$FI{Xk%@b9O!uSaoP50-I-`1jUMlHEZW#U@pa7L72OLFBn?%_F=vZr0IUO
zxjLLbRS@<8cNxejv{3%mVrL<ZP1;pOt34$~0q5iw?R5wQ{?q;vUh08A^)Mlpsg%O7
zzkw5FF{vh%*7V$^LpKmSYT&Fv^#Phd#dEIVO>+MbO^iN<g|Xc*jfeod6z0sBdSnoL
z0;lT4Q8=e+^!Cld!R)M_ji*5VcI@Yrb*6Kofr~EOhci&#RAv09yx??r7tlV@RNW4&
zd!|OOac?I)+y|DH*|sdQ2_sP)(hGCIPA&i-J?ya4aL8>L@T(z``5x#C)5KEeH25df
zEzt*-U|Sq}9r?7^LDS4AWF8*!Z)wMIbGU-YZI-;a2TPFXE(G(wLzf<K>O)s;mFTfm
zl19~G#}7}uNJq!ZLWlCh4l8}hZRxFWz`=1v2oA1g;%%c`?2E`fc%ye_f3km>NSl~C
zugMq0!StAXAm*P=dp)A=gE5~n57xo7?{nuVnhi00XW)A}ExrZmh1XD8)^xk{!hchR
zfD@`lBWp(1MtiEXxgL>*5_`tD2kp~ug=OaY2XQ*=kZF(So`2pksC>3L@Y0TV4$Xkm
zSiElxE3hS2^a(3foC@QuIqXO4P+i)T4<>xd&M+_^LH<}b)Mk=e_=jHeZF3paV*Gzs
zagLpB;8r%~G+$LQDz^b`WJphA@X&+t1wk7QJ7LxQ1}Q#8|GWk;ON>hzZ_n4qjD~J#
z%&33SBu4f<du}!i^UwYc!KtmK3vw3{p(*WH;8TDVfbsPc<0H)g*@xK5t?FbGhCGkz
zYV7}picjJF?|8c~%jlbS2%vHTE0~LFlsaQvr|ObU)y>jLO>b~O7|2O<Tqb4<Q#Sf<
z^j^EjeFXCX2^J+gOlJouIyxB)cWQe41aH*a&r05!fy*1LU?bxeVft7A`ask|yQgGs
zu)4@{Tk*rd)IZTsVV~ruR0+BE;ml(?Q=(S)ZItg|2<(TixrQfQAm1J^{|UM1-17`N
zu?jbm1*%+l1qQ}uDv?f^S>jG`=fZj<+roLGbKwHKOsdCeUP`HrEwj|mF=FC+>=wN>
z5nR&hJ(s?}?p`CiGaY(g>0<X{YQ}stL*8lj?R*(!kFb9jo4<!8q_Puc1#F#I+#Uk9
z19(~FKL9D2{Nu^L8`y%9M`t)$uc|YN_LgM;!0AM@z*VYuX?Yfq1qbF8=(ft91zW-T
zS*&ByWh9KkVH0w2?~#uf0zV>`_=e2x=#(p|bn<hLd=zJpci;@N((P*(s<Al<Z*eRz
zyuU`ZORgv=Up82}`3773SSSuBsT$d3vZP=Tq`JSLQnhai#qFZFHpKCTQvA#@ZxK64
zhvk`Q{|!?0QZ4Ux)9K)6M&F;yNjp^HTG3#`oNgRoPKG~cwL#!#qv6y4(YaS!rs0f>
zFG43>w$p=rVulVw`$aq9OAiP92HlB2X11N!cKnYx(>{Qb3{+C`RVB^iB~f|X=|Lq)
zCbgLgP7O39quc74Z?5U4yZ?j6%d-<s<>xVnm0R%GLgT(1g!rIu11A`7sc#0+k9RJ=
z3&c~vKNos)aIRe!3M{ch37X<BvDk53$mq)=1<ivCH^ivbpG%&bR^JTLE4^kv?h`Qu
z%;T~?sM?o#n6G}Ypw>gQs@`PKRBfg1H>gQR+JW?gK}DpKCC4OFJ9NEo<FHtoyMvN<
zAi23WM$3UV!cQ***yN>O@vS#PVqqPjS8o0_ScG~UL^U%tBTHsmODQj4|Ioc8wTKlQ
zGfCg~DlRy>wR~}mYWNBOIgOrdC~vu|_n#(i@SbdKKgt&>@q)*bq-tHo!G|tE8SkLD
zc{ts2<zkfa1r(QibzCvU4f1vj=PjYQtk18?>!i4)SLa<wakr_9rlGcA76`4K+%<o=
zyay?6SLmwp9-+9iC$5THNpWijuZnY1+|pB5#SsR>3CHoIf302E(ZAA5OT#;Kf?q@m
zG>G%AFn8R37B+r<sLAo)uI5KZ5yW|u3K2@6pdri;U{iq&Z;`paZb!qP=*=xfun<{H
zJ3Pj~^GMf4Z)#|WgZv?G*$;M&<#wcG)4l{!4YraPeH{0@EP(H2W~VZD2ey|E$20wn
zzk>~br+4rOEOxy7{WzcaL2&R!EN<8tQ;>1@ES5s<S&!@Hmu9x{1+pTbsK@n>3&4zs
zy%#vEqx@(Pkue^bK#|FC2v9yk<dtRX<9eylLT*=BHQYFV0n!^OlUkCFGLaX7vIUU{
z3l2E0J!oG8L0k^*>VXM)gV6dZCI?7<O}+81Wbee9-5$}A7d@+%;Q&Ju+AdLR9zq#0
zuGhFDG@UBj;ERz!j_CAn$ugY9!8)9H5l)|=+A4{=x<*IyyB7dOBNvU**I(ja;e-sz
zj?ZwybPCbA^#oeRsv$a0KnGdE33QqO22X@$42Q_=o-1$(*5MF&;8UD`Je|CsQ?|p(
z&*MjP{7a1fax<MxH_RC47UeI6s&VoLi_V)O4?+v`U4m~1uDF>aE7qt)sTLn5`WRuo
zIht78`BYm}MDuTo8&9ig-OT&bU`Bt)%U<o>0)MLCVZ<5AX=kv?k-K`g+L0D`i42Bp
zd^*BxJmno8AmB9tc$C{E9JOHln8g;#vbBUBR50cQsE&T&1O-p}7fz@{@91B{m=m@W
zuWU2c?K^Q(L-~m<4I<upymcpT!t)ZoVkfp7Us2aCcU{JrtP?9h<@t~ZdB~B+jjeQ+
z%yN9iYc|gSzC}7mA>xql3g`l6s8W_GR{I1fZmaS8+w`%*+w_2hxo|8neGJ>d&PZ?U
z85N9-V*B6bSGnMj_=R&@$&H1(u&@sLcDe_MWE|TuVW#u?9VZ-rsITidQQk25#FKyY
zqe4DC>5WYxd5<3Ld$Qq0ifst+G{7Eza`{6zQ#XIOo!scUg(|ynB<`B?$9gEjq>rmb
z0{rGH-JIgFn<v2h%uUc6|Gr6eK41Tr2ELgG?(jUXD%eoN-|ZN7sS$ez$?#jisFt<m
z)a|_zcSH)9N9j5!c7Iz0kh{xvC&OwNu#O3sEgVs-<H9kxK3IY$EnC-seT5RriHWto
zI!KFUCHfYo%um5Yxrem!H+;rTp8D3`P&COYWf!8u3FJ&q+>xuRnQg9~mc+#p)`Mg>
zk+x5O9m%W$0R|?~T;IiHq<g!<3AC`Lf8d6nsv*7>mVVV2vPd<!olK}cYLjaEX!SUg
zcwEaMprt$dcIu>>F2vG)@j<+y{jT8!71%K=xhlDaoonILjcYV;vd9oJB+|l2C*=Ds
z(uDP%Bv+6YrygY^H;AfS$_OXy#E?<k)(!;N`1kQtTSq<oYBjid#fZJhcm)Dg-~cZ}
z1&(A?FjQ{K5)?><??Y)6#?=bwZ`mhiCi80kovH~e)v<{b-?9`S#K)x!`I1z1OIf=)
zTutqw_;5Alpnu_N%0>Thn+LK{jutnsX$yVJ{gk&Yo|h8-Mc&oll$R3zMc&81DK91b
zi@asul$R3zMcy^vl$R3zMcyaADK91bi@a;UDK91bi@fW;DK8~_b6ygYT^M5Fo3c~F
zaQ3dRk_Tn4mVWiN9q*a2gI2HSrymd{H6E<{g#9^qIstw$tVh0}JMj5|&*X4S{%ed4
z`c6>2thf4oBRknb2Xv$im44-mQq_%RyUk%A5htZEA1CME5MioB*_?>Q4H_N$rbbhO
z+Gv9OTBB*!Nx!N-q4(O|qrf$kpEMK8A;!TcBzG{U(8H0_cwR~I!wjs$L=*9BUfWB1
zl}7W)trQtfph!dsTY6zItbSj&mEKSp3|)i53slM@6sn<+K%qih8pT7FBD2u&DY0Pi
zHV1Al!TmebmaGoAyG`Wm=1wXc=ilPDj(m%A#Rf^e`m4s?h-zsC--I{q=hHXT{;g#0
z!s^19&HGlF%#DsbmWN_@5`fb^opA7PO?>$pPUy!0ZJ~{td6`03Icy;=xmAF8o(ZMs
zhgHdFH$L$1CG3_pPypD1$&P~T5IFt4+psnXze_lbbmAd3eTrk-zP$)m53Sp_U3Q&j
zL3WU?QX6!gh9lqRYN?hRA!b^h^d!4*UQeo(kp;W8FX2V+AJKdJBX~%SKj>NtZrXuE
zO!AQ=cJjbc<I5t!v0lC&HpOq=VrPfey!D$YM>lK^E4^*lI40oMeUMOa!^DOzmA!3$
zHwM88;Wpp>5TWInMvfL76A8S``=?a=f%;Y(lh|ZnV<ZCJQW0<#2$)Ae1@;Vn<UCRi
zX#!c0K~9=Bsc8>1Qfu&t5ic|ANWt2t8b{Jw20^QA50DZ9k2jMntVR(zNQz%nryhY%
zLn=iQs2Y>%gd4MsJfqT`WDb%VaYM%@YW=%^qSjl<fyF4*{4a{6AZ(`x)SwRguRRF*
zU?<yLjYVAnLaAf0^WsUSkfj`P8L)hqeIGceJ-yUWG9K|Ju@2nKMp3Q2?f8mpL1`_$
z7<d>=V8c=FMGIQaqyJp<=TX@dRSu9=OjDARRwbRHJOqWG5dAi_$7;bK*A@VdT0*-P
zo>9<bQj4V8+Yt#lTvHvdBm$Koa-9m9R>t$u88L#sS<Q5<R0}noGF4Yc$>up7P%v2n
zUDM@QBChJnz_;%RH>A*(aK{kZPh$)m1aj?_xMsQxq-Q%lqc(KFA$RG>UAIp@abE5g
zuK?mCHQly#=*s<D1u#cZ1m(glTxjA9!BdK_88`K^T^Ih|hmg*b;vY}ba63JsHn=b0
zH1B#u(zM%759|q!r|G$!9)Xf?$8HL;(fmxWRXO}e+*ESgESNN>i{yw`%TLPS+@bG7
z(0VmIEf4i<=T|12r5PyiHt;Ak>#VB>2r>J1=MWr60o@cwIv3c;w?M)+IOQ1Rqc;XT
zmO&1H+mz}zJFpMN38I^ZiZ<@NWi*7Gq*ida?O3V`>O~E`aOy;d%_$D5<xo$vu7L=j
zP-0H0R^u9ULqIPL0sY|$&^|RzrMg}!EW<H0JrDd&oq51)h9I$8I4daG*w}=kghjU9
zId5LG8K=`-TR+BUeac68(pg9SOO(vFK<KzDk8hsG0q5b8n&#O&I3L0Klwv&9Jam5z
z^4!Fa$nyA5!cTx?9Jfih4(}VVA(N0c6sR5wJdeQLL)-mgIH4TH*qyT%)TjKA7oCCT
zP@H2X&>?uwQiCX^nIc_V-+?4l_QAfR`~+r1r32e`VB6r)AQObhnn*T7_dCP_TEU4x
z@2SM1Gj~70@633QrfW2r49HS|gavsD!u=_JJtk*JXM5m*bs868;O3Su*N?*OnDD~@
zX!IE{W`lPEuG&B^s&UmuoIA-~2HF*W;>sNyI5fa^(ao7Tx~dt7=2S)Ho_fvbxdjoa
zBMJZ|`i{``Hh~{eQ^6^%kq6KpObBz5cQjLQu_v8~jT9j=H{!sPHjY!M-?-PxlY;GL
z)w&RV8|(>12+e;b1Uv%a?&DWz5K_EYHgE(P%|djx`yT}HQ#j@FTMCxKFi>>Wp8DhP
zsRZ^Og&}e1PJ>PF!h`2QP`ta3GC%w#`PPIJio3W(B>xeRvnmnaQ3b*P1VYYlL6+^A
zef&z&=nAQ+opyvdrsEfp0s+B@5qHAOG+=bRca(i(_U)*H&h28$^v#c!VC(jxfFw_f
z@1g~7uci6@*=RryR@4w_Qk8`+c^XhUU#FUC4?p!EtuI7CGlU7H{MYE>E40Q!*@ChH
zpKy&^eh>1$iTtfkgYTZ2^eNK1w{2*6z57(=?wr@XV?n(}jPeFUC}9KM)<5W4p9a&u
z8uBn8uaO#q@D>s{v_4eLq5r7U?S(P8)P2qUs3#MM+CryNg2zU?CdKYC9dvD_&(@2m
zyFuT5YWYJsdhadU22SB_Hh5fk)3#m284EN)08~Gkuo3TM)e}XZxx4iuT0;4dYuc4u
zH}hO*4(t#BaD~OO{b&%+%W;9L!`g6}R%;|)EwbObjc(-RmD;vNP-(n3RIy_Cr<t$R
z{eNa2s`+gi1=M^vj*)K@MsEE5Fh)$($IlEQq#5iD8wfD9kn;&QwEzheCN=XxymOHo
zQI8;qoudRd-o<Lv8U(Q!oZ!KG0iwbQ<WWOH^@<hEr8<AWIPtE!{@>ON^8?h+Nxgu>
zb|<tSQ^!_v&QarWy%|(K@^Rs_>SgpDjU)F$-nfPge9;*s>~DC_$6cE{a6+o;rnp=4
z?vj9yz*|dD!SMV7G$teWg+g@n7BU>2iLvn%6XNg*{2Us#{8SHc2loJPcu7^25B9b9
zdQ#dHG<P2+*edcTIRtxzN8S5Y79s-1q2$*4VajbzL>0>8{}Xq)<5r*+I_NZHP63yJ
z&z%J#j+=qlc)G2KrO<6fBWLso9rtm}Ar=C2pcy4(o{rdn9h?pber{x!e0%xSj;o+t
zznw|S*5?3~zcffM+y!9P&sicA;P?$jbkG5}FOo+5B?(=q9#$aV+JbF-vJ<3{BK0<D
zSJ6ylwt#)AJ12CV5gfZNBNBUkS0Z5sLm6pOBQ{vec9|1iq%{;yjF-X}_zv)~LU32B
z=pEBSyz4zuz}_asjF(Q#SuK6|ex-O7X-GjEsnW3g`Q@uhzn_Z!_#G5Y+js%oCLC9r
zv;UXSRof@AgV;fVbOr~T;ie9`sYASr@}5{THBtEq3UE_%+|(T2I!gN)r9F+bP{Mjl
z&9>Gb5Jw~AC_nrabg=|(Jo52-viMzDJ?^D6(Hg-L)q9UHmTv)^2pQX&6lBDmfB7mk
zZmG(gbK$^^WyJ{gOyY7_7FLZX0f@WIFrXgXHwOpgMNnVSRWRR0yr9~?r``s8T}O2v
zf&7g;jrv@^Y}{7&-THhzZhN>Lql;UfphfJa+v+CdW(DcCI;qA6+xy5H>n{C<G<Xa4
z>OfGiW}74AtB9#{x9TC@52xQ$#K1*7@T0dd>s1$VSJ+1%)j}{T29H_fy#}^S4Cfg)
zph*!0-FEqluXEu*)kK_QK8cOTPP%D^Uxx$dGcJ6gD+8+BvV}MZ+|Z>L8W4l>%KFWL
zpAtKAY^5Yu_yzi?2JIilepDCkwF3KKd15o&Wb48qk7SBQ9eui9mS>Ev!PRXR|9I};
zK9E$ERd&)G_!G4@kMT%XxK?dD3K~UclI|5-sok#Hn8zeF(OGM&Zh$Su`7}qO3ySIW
zSO#6W$u9*lCUox_>fX!b?UBtdsgs_6ng}nxgr27EgA?ui(^a(m4qrtJQcXG79Z2LZ
zECjKC`-QunM%9hU-@Fq#t#UKsm(ARaa-`Zq6;v7meU(6G0`y(NP-cuvfhB<&djQ~=
zm`3cfn<Kx$@c9=(9faHGZSXRjBh}7BRP+YK7(8QO{FDc5Qf(IEB5ph~`#7t?J%_k`
zc6&2Q25Z2yNAfl*w>L+s!X2J%^_(f^Bvp-;8vAhs#}_6Z3?UQ?h&MRhZ&Tx5p;_6l
zyn&aygCc&2P?5aTEHx(3S<<Y~#y2D9P%2IsT-JMUxZk~(pjHFQpQv~#+dhg|f>3m-
ze=%HT>}%jzX>{bl2g(TF%H*2e-rf+V+d})A1^2r<3HsZBMjhnMFiQ@ZIVEF9+q&`R
z5m-t__JADQzp)30sH}g`jO$lU;-&WB&j`hPKnH@T2hr)cr0APlR$^a++mLz7UP5NB
zC7^jE3s}v|kV=BCJr8rjEbk)WV9rh<x|d#@1$t_xZ2)B=7NA%FdUCQ3ZaQ7t_FSYm
zvor7(H!ws++ylACpZ1figMm4^O=rtG&Bbu3T#RAcLLwG3BQ9)JOpZni9)_?cfco(y
zR_p8NS(n0}FVPd%L_Lb+?3px&o=qtWn-gfpC_jKgv7JJ=fJVx?<Vk|p`qPNZ2a>ZV
z67a@|x(-60NQ0m?5DBfJo1q@p!z(CRn6e{tH{V{n9|OgAX#5jtJ7-F}?-*S~h+V<m
z*v;!yzK8Tu_vbVY3()Q@v|WWuD#p`R7F=A#IT-k2y7V%3XAO9_J8=mh(*gN5T_l{@
z_t27PIzQ=&ZT`O+o-vLqGsh||_b+lTSnR%mU@t>r7s>5boE^>PMQq#`opR+uPRx2t
zBdlCTT;&NjbokpwKEcDclMIyH7X#P8Wp+ZHNjY(-q3y&+2>nG>;_s$vevE2VSB8my
z#dKbZiJs!VpHiMd%2J$mZt74)!jfUB2oe37#XE|1w4VM42%!^xIUUMhwqQZl+JyrG
zDNr@yt3+U!Hq9Y))TJDyD4+g4zUTm5e(jF7*2VpNLs%IL>4ANDx)6=d(d_4&JN&=^
z_FB|4+L&f^THyFf=s|rube_A9Khn3u=AA_D@8AN_M{)){_vZ|Haa_Hcdi0yE=qqh`
z;0E)81%Pn6e@^i~LOe};I)!M&DMT}!LL5HW{Vsv5B@o<u8Z|2qVwoNFH<M9?4#@Dc
z-6A$W;1FN_8fGLsMEq8}*T#BJJfbc^van(UUg0_%O`b{lJO+6$JQ%pUMf_GaGy3>(
zu-}LcD2BbcgIDh4y`sL>SKkCC2u*2}++l-)gAnd;uqQV^0)0sN7Al7$N-a76_%4wl
z*jv;}bF?9*EI|vn>k79jw!Q+|2V>uY!K2s>Pu3;1u0%G((T%5U$A!+|z>PQUgSQjr
zQ>oP0-r9j=WegRwE3*%B=301hH;Ug=<1fYw@}?JM;{^N0&%mLtX+2LIyG_X+s%2E2
z_`Ra+>GqAEu_&57N^SNU2nh&v{qS9jG~&2{j_wxrq^TDg|K`79vEz@>jZj|2eE{RZ
z1vz}<^|)N@byTBF=A}rrxcpGS@dJI%BF`v3z)?U)-2nS7fyFRu2}f_n!Jv<*VB?np
zEEk%~@2Q^$<6w38$n0!*O$qY|?=$R>t2w4uW}{1J^BP{$>mGOyfRyr4gi?fAuw+>j
z8}!XzP)Rqcka^gF*Xzlj#ns$vQA}zq=GM?%tsy?NE0FCxWmCT76^wG1Q=w;GfqNJc
zOPp4w(^eZ<Ql+NH6QxG|q-x{=H%Mi@SVW^S*rp1+L<?xJZhLhzg>X)hjt8?d!N>$I
zjM>2hT~cEQx5S?1f3t;d)UgFhrobot=NBNJQDQpVL4Wn-Xu=2=(?+ajk(5SBHhGW8
zXqVNdo6zYyie_BKJtIPO8eMI2Mrzz2JPJ-MHJ&$}#W5YW-?w|3&?UgCn#SNn_MDl0
za%+h_U3wFuB`|dgTVtOJZ&fQhBL^L-WH-{W!}M9u7Bbj$dvrDXK>k2vPj;zQ_W4fm
zD#2?}<&(!@4x?75;g0Hb+y(8iPleNC8emiTIqnT|cr_xeCc1Y&tvJ{<-V`zovL_X`
z`jijx0yNEh9RD}VK^uz5*!UyAnVcEZg2xhcd&34$kf2t)8wMNdYY-KSY%aNqqKe(}
zkvd<HQpll3iJA7`lDu#}UnQYlyZ>P$dXvVU5wGl2x6my4>QbyyybwaP;9Wbs15P3t
z5_o8r9u<nh#^Ozha*kbC?*PV*^rCFLzX}&D=waLp!=wo#dF+08)-8@bDMHL|CR%#+
zmoSRqCNS#C2jF_Cku3--FMxSOUw}68#E)Sg>5IIGNcF@)1|U`6;&;iu*dE5WaF%Tl
z0}cyr!KWKCo-wQa=M>N%^PR-bi5b@yW_H$|#zp2A4t)!HD<~oWmqI6@z#1sIJ;sXT
z+1e%%;-|sVVP^T{h)6XA@-v_@hx1hAfsFl68^cM010=lM$YzPy>Hw6EY|ot+sA3xt
zH>?-It|WS&HYuQVz7KQYGZv8=Be-+bq?q=xBt8^HBAkRVA=DFsd{x{`LoqB`)J5?u
zWA-c&YZej>W{3uy0T4D$P!9u+z2Ci!P`Uuz3AkMPP}HQ{13nbpo!O^06)S*yt_(FF
zW&U??=+rO2D}Yym#hVe?uCC*hTE}N_89(&zz<aN}bNUF^${etO0}Gt)-PC~n{|UK<
zMUo)B)8^}@+0Jjfqk9;ACtz0;f+sA&W2vTpfD1XQ@yJai(_S9kxl&*+AbkkdKO?N^
z_DQ&N!V&D6V8TIt<p-CzTqK6M7lTrdOKt-B{W&wF7v8}q944f9a4>9w=^TojPUYUo
z%l)ouIh>)EdlznoE3w~-bA$(#nJAD-dzP}}nDDd_Y-Kr_2_b)xUh@#rU6`ZO=;-!c
zAbaeUBKsf|8_Iq+k}-%zIb^DSF2NwxVlD{P&n3djK&I#F=aLX20~`Ak_fq&iClr*$
z%)T(8rhb+#=Q-(xGZ2i_Y<k>D+Jb}X`YvH&sNvxKyLr8v<MqBv!c?z>pvBeSugj~u
zUx(|PA``ffCuZ74_&<iqbn#<}2YfwzG-CSIF+Li+DZ$Szrb~q5cB$rZ6p5*Alp6CA
zhMQyhCryFun2zQgR4(EWG9e*@aso3_(|o;d&y=(BOm2t8o(B>FMJC-xS-q9UdM7S=
z5pksDZ$v1s{Q}Y{(g(7y#x<nZ)fek)c0V;vYII^_!+<51H_0V$5RINBIGgGAMYppL
z-&M)#G_~y}LKUuR0-AK3WUe3zzQ)u#I(xP>-oBSm%W$q_o=YW&E4ku1Zi(l37&+J>
zOy!uM<F{kBLyisKC<^pqg>Bjq{A_~hr2M&L8o(Xz!_w|G!ZYNDby(VwMVBB_u|ow#
z31abV@B}&*GKKhMp%8YW;^DUG=4#ZexDn=V+#)s!!3pT@fxURcJP?`i9s<IF&sAEI
zV-}bMC@Eir*RuS<>idG9kB1})0ylA+80<q|j`J7-PuW-&j&E8ZfP7>EyX*r4g|K=`
z1Rpe;F5u7g1)j3t5Azj5=*VAMvHR$uGK@m>o%kOa0rT|d8T}SE4pzQBddS;$bL85g
zmc^-0?IIWF%{J;fb??XAAl~c%timW9DnkRU%Ci&>*Y<((&{<L#sk6VMH)h|fl)cgz
z*qotuk?k91wYx9uhvc)-<lg~CD>ZhT6i95d%3C{_AujD$jy+HWltW+zN~Boe_tXRo
zkA;01cJyMGsF%6VGe<uwzRcxqn*|3V%vd*Dyq|)o;TtUai}B}^Seg%;Og8TY_KX$x
zS<+IURi;6-$nBQswV<}`KOo+yG|{VHX}~Lb9Xy4vfs0)i4!nS$DF1;-jwI|H(zhSq
zbfIp}2zH9=g+fq~n#%R67drImYV}VDjrapXLC9Fhdfx}cW1v{TU7Z}uPtv}%{6QiW
zPT%01uAXqN6}oaPoNK063t8P->CtR^3iGfM>Lj?0g%hIEI?VYz=4JwdG__!p!+n<K
z?D?ONkN+`5U*)xrdmxE#Tyf$T9KcPf5eFvy?&-J=0rQCF6VwJsUR;`_YSPKjPq{?0
zA|>@|iL{+gN?kaigE<1rs#O16G4P}@oNGkYf<F;D|70$r_+RfKF&I@v)N!|Q8QNKb
zb}oxp0PM%##>usXbJLNJn45*oPh~xrI`^PG-52PujsbzD!Lo4Tv{S(4yGi(lNc@84
zcZfYXJs`$-TM*ZW?Goh5br3~>cFjM<xh)DmSsc!F(!w&FTLPCY5CNw8{w`$-bY)fO
zVT8=&#D(kJ(UTJ2LVu=w0{2XXbr@YC&p{{EHXg?x=vvf_?K$iw{WobonWv-KfgG9=
z=m%^%GZtdv?NfL7ytd#;6TB8dck8hMjuk)({@zev;av;Edh*xN?V{z6dE<Myi1<$A
z4m+G2cNmi4@!(^Do>&yai~PWf5es~x#K<{6N!yVZMd6RM;Mk1R<ksWB08>(IKwAqP
zbikJJdwd&v0Dn^SGD(X>oTwB5!bubB$31)xlju_PtDm4%xGX3sZA83#dYXkF0%?e9
zM#CX&>F%o@_41$Wm(Z}e_<J&e`69CHK|E>}l(8_#ve1ZIr#UVE8Y^QKRw;QB(e*Ah
ze4Lh}G0zz2K-@0bN@V~sDeiP4mx(XK*b`lYEs<;Z!O?Icp$a#1tlrcW+h!TwDq-bf
znC65)aaRtbstRm}o)rqL%!ujyXFZ$x0!$4+fcFa;@cHHjM|WVpk@fck<|mRLC1RU{
zD2aL$c+x@&GB#<0W4Y%^*mVI%#l0qMI*g9I0w{hl4*3PRE`)UgZkXoNiI8yzQk5W-
zzBrOBC~p2(B+&d(UZaFkQQl!8{kx+tsPo+1j8?(eia*G45`W*4=;ynAoPLaP$R7S4
z`+wySN9I6na{TY-(4DoFC?5aT<FCwpAHOB|&BpI8{BFfB4ZoEYtJklxO?pgN;aM?h
z<+MpF@3Kv*wB;_$MbK8fqGIK=g4LB}f-QZL*EVl;-cz1cl~dHOSwmk1tJbf6Y?Y8-
zFm1uQCvGoT%->%t&pDe)oKz{`|Dv^JYu8n+6)IMJfAzYxHmWpZ!=#KE8<K_l)~~8?
ztyx#KYNc(}j5{)HYgSi!Zb}yJU1xh@UBxQf6RYrg%H~>EVOz0s<!TSIuUKQNeB#m7
z>nd%Y6_2i2RjC4Bfg72Ks*;7(Gcu;%Ve_nhV%0jY$A<c=R;>2esw!4{R((@q#i|v^
zh(=VbTla*`gT|~Vx5ZIco-8czu3fu&?e}f#%BevBdcwBCW1EyQeZyV!NERMjv1U!?
zcWqUxJ#O3Twd+@`S-sL$=~?kuS+Y>H&bxNy$ebML(G@FgkGWSpR#xeK;x5~ob&t)Q
zRBl_dYVAzm5K%KHq0rT9(d;KzJ>jJaY1op5av-k4TW*_OP-p`dS9s8>t7EC#HuM{q
zzS3Bfy>i{E%C)z6Y_8Rw+meO6b?Ydr%|%@q(GQBZxmK)RvkF7@*gEf;mA18rA@tZh
z?p3x&DSagfCRr_G7?z+`@MIdJA&^y%u3Uj}U5~+5YuZ4#rM`gxQT|#_#kw_XR#jlw
zI6^nvK52t3eRai?6tQyEdVo&3GAu+C^PCHF^GXUqF&VdI+J^oK^PDPi5Ybc+D(5-#
zzY<fq`sr1`?*BzSKyXIp?f8F3M#lF9-0eQ;jtxS=?0NHS8AKbE<trXr#Yr<xa;wn(
zr_^fDpwfAHv+palm3w#tIIW^3$pWCLhn06F3pU%mi%Lp>I-nE7S6+_XPnBbOqFFSg
zR|XHWb$P|A%2gg)<(d_kz*kb%Ji0<yv!dertAw@d)~*^c4W0SLr86gaZ=bXh|81U%
z6>E`|=yfJ0d<jpa6#NIjs+hKl*asij$5x<Yt38-?eBhG>b;4uR%hy$SDsA%$3uZ5x
zXS?^lg*NAc!qUQf7bXk$V@h!X!kA#7z#nL2SFZA`dd!1KymGboiQ8_w%?3_T=`E*X
zKmwIW12_$YZIU-xn6z?UUK}=_a}}C~o|ms)zPb|KU$OEjG{WPpSc}}$?EHd^j7(i&
ziEZJ13uZ68&sORz%%5E}J3n{f?ECJeAtL%z36QtxYm{DzMty~H^RK3IPN(?=3+|g|
zOMh(LO0*OcoD-qPwrcG<@AutT@u<hjSKBHo|DX2WJwB=;+ZV6h-AOv3lbt67NT9_A
zK><4fglMCkghzM>!b3nMysE<xLQJ|zP=tmgnocC+bzaVynKSq}b3JEfj?tN`fHRta
z1`trx83#o%_=wpwB7y^fVDkH}+Pfb+Br|e8=luS-*C@Mp)n2u#)~c#itEyJ5T2mTq
z1#{66u7%?(*Jx5MtPz!KalIwj5J=G5$D-1;Dz@G}iYhJfY*=Ys16Hd2Zt)x;VtWHG
zFM}i#JnIu=Z6*3P5vsCwBiE{M4N@%JNV2kIvlT#V%ScuWpz=PE2}IynC{vsaoS~(<
z-HIcH`P6^u<f`aBi%LX&qH#e;uD6!0++ZDJT~)SjjcctCO`OCldQXXUT;?jsOLQ8~
z2FUrDo(-rJ2y_v)Zc^Lc$e=*cMWdggz_S+5QU7NPkV^r{i@>M_Szw)0^Z>e744Xf7
z&LV1SXr`-CmW?IF=*5tY8&<9>v92!lSl5+XOR4Xckfc?`KRP77j4U4os7eU<K$i%{
z$FTevGwvRDD?P_!2wCU8-MY4THAIO$vl4AE6EYLmD&1~f<te8z0)38`h~i~d-VW+Y
z)@&?Wv2Kls8DFV&$xsBO)9RHaLUt{lo*gzC#js7Tl^6udZ)FS7&%_{CVnrND=kkrk
z;ADY&Wtr&f1#4Fd2{#f$c)1wY%ST}x2vS&F>b44r5f)dzwrm|5MIc(pJVt7VRj3`R
zP7x|xXn=(*cC9T@OE!D0Yvt<AVWnpI;BUEgT1KWINsLMx)|Pn2qBsR>i%ABlBbAT>
zw<C7=nz7bts>EH+?p4Fs_M>PTSLs(Ri*-3$5E41oRiqGE(d3sw*ygQs6+xbp+Cut4
z(aLg2B`eg54XSV#$`!O6(sa-==tsOx2AIZ2t59Tg9E6MvG;vSKKWyaFAzMnzGp!{n
z*IP$Iy>L@oAmIdFt_Dx3_UOCl_%xD+!{7r%>gr8IQ9wEBMIGYBo^lYW>QLoti@6mH
z2<QaXkuDSgm}$7TS5BCKyj95cYd5djNY&amwA~KqAlyGey>ewZF!cvCBlJk{aiLzZ
zTXBDp6#`?Vdkx7AVu%&W6loH`&=Yno#t{t3Xxn_9YlWwL71XLyQ9J0+!LqHxxQ;$}
zm#TU|7Lew#v1s)=(J^&cMQr&-?ygt~?Ui~xG%w&HIYp^Fp;Xvrj_KF0Xl2Qo;<YO>
zvY@vI-mx;qATh?+$BrL6ZVZ%<tc=WzNh>lkGBU^AHs*nfwd+<DV>~U|xMA(s^<^t7
z*A|c6Smt7k_MVgRj}BDQQ9_!RO@ZJfPe0N^x-AOx-McA<Cd_caJ$K>k8>MJ#eA+#1
zxpzv=^c7OSDUC6v<=gvFz=+3eYy8ajRutr{SiWP{+YmT*^NPF~Q!LrXVvOb$*;5uU
z^NK|?rby-$`3n{%&MNmN_A~W^q5AB(v!*chUBY`dOSDjYi~)h1K){GVE=!CxVQmD(
zQQ@=@r2=4_`c0$*Xdp-_fnUI4+N#28AxaqlH87D9pduxLloF*8uvi~eVYLvY41gNd
zlmHbe5u}tTk$}ZCPKDJ%8jS+fq^1lM9>H)rBXo2|uy8sf)Rck3BN$F+q>j!=kum@p
zsizaca5}N95=Li~NEx6rN>3+(;dElrH;hiRNEu*>Sx+Z|;dH_-2q^=cj@Ho`t)~;g
za5|xkB4vQnF*-V9^mHN^PG>(Io&9ul_S4geU^tyvN(rOWqNCHIrxU?&I&nrNjLujc
zow0g45e%mjc2{9^#_8yc)6<DyIGxzEM@rPaXninARm(0~pRA`7!EidU;HAQfl<_(`
z<MnhR7*1z`j?M%foe6q65e%mjo<G9qOw`etsHYRba5|H8bSCNOOw!YdU^tyv9}c54
zSx0BGo=ybA=}ghlnWCdJMNcP!;dJ)b(b-=|XMa7N2!_)+Ku6~Q9i0R8bRrl|XR3})
z9B=^Df&Q7QrxU?&ItS|L9H^snpq@?y!|5EPqjQjs&Ov%Q5e%nuu#V2bIywjI=|nJ`
zPMF(<)n}TH&NMxp2!_*%!-FbMM2k<?(V4EN6TxsgF=irVKn@Mj(K$p<CxYR04%N{)
zR7dAfJ)H=ubT0Si=N2rK`mz6vF)!a9Pk~$vw~MTJOtCKa7EGOq!P)$uVsNHFZjOEG
zOzZL;!wWK2tPn#ngqXyV<rPzB+NIJM1ATu6!*ju+xzh3-BMLG@V1^KwDGV&eKyc$i
zaK;dvIULSNaN|R8rVw0wIGl;#CWPQ3LU7h_xCnx~Ed&=Cf^&w$MH1Y^5L{FU&KnLF
zwS31-1(QN>W|kbUvIT=eIG~vTvqFH;VSwQbjEN?|4118#F=2o@7RCs`j38jYFhCs-
z`w76zAfP1-P{%}z02~(tj12?SaWPf^jt>IHg#qf=7$*QH1OcHm2HB(Iqr7~_sDg~!
zf`IWXIZ@@KXlvn|j2EC2gP;lFpavEWnjk<Y1wj+TK}|Z)L;;!=1WgJDHS0i=2sATP
zL&@Qw@jB3C0UD~KlyFe14m3r8hH9yQIH*$x+FyW%>S;hYs8<I%K!Ap7Dm5Hb-$GLb
zXsE6R>OggEbf5qY)z%;#sIHX`5}={l8mt4=wbQ`@G*nw@I#69pO%tG@+Dg}fTEp8w
zI)RQ0)z%Ols52aNhyV@M)=(X&Hym`Rc}4Dmf`pu?n3CF9W<VpwUpGCZ=~9QK!y=gx
zFIk}YV}lc)J1oI4j8zeN;SmhR>UXjN?(T+8DgF#he4$wr{k3*?ze)zA_-h)nnJwQj
z)kJ<B1Ct{OlOs%vSaS4=f`!@anHX6u+0d9YLKCZ@Io8!}Jf@<-jAAp3pL5GtnrqQK
zYx$0wu`&~E`4HI<<r!1hGvXyP@G_2GmhZ^95w~{+fhEl5^2ghA4KalnFLsPsurL?j
z)OlM!3<<=f)R>g%QYoD6#2bbYd&(GYT#h7CrkG~sObNmpjUghEM^RE{UWm(5RRo2s
zkV#0rhONQxFawBqhQ2P}F>cPhML{HTQW%nfVMxp|5yMz~Fwu0=v?;m4DJH~wkblXe
z)l@l)rr8q)$D~e|&Ku7gnQ6Lo$#}`gq+w2Wvx#yi0L)b*X6G*qW{>e{q^O9}`|i7M
zZ2sLD<EAVq$S!=akXneha98Ay3c<xEO{k~j8^ZF5kBOZwRT?XeX7ey_2zhp7?z}k}
z0ft6k@=H_TUb4v5vM~RXEIN!GMrIxsAIc(!vdHX_MU3Ge<nhnQ=rDBPCXr$0P#(?*
z;)JR?fP>U#GRC3J+!JG4zI`0M8;MO;JaXufOOL7am`0E3^vI*f40_D8#?Q(W3kBP4
zw;HJhQ;VclDCIAhZ#UzSL61y&jKjb?rynV10TM0fA%TU2f`tAtNxnE1ZNzLDy%3K5
z@NY9q9;8-cOuxciu@A<03Gd3%nCQZ13X>C7Oqo%@9-=7qL-JIUT9f$;7T6QwV*2?a
zS+qnQZ!@mQMqEq;HPli{QMjw$PYPqarG*spWK=1m-)9IYdBBQ-1qD)Fkp@j4D8=#}
zbE)__J&GS=poNg@D1XMa<<Ai1&$y2AXIyvrGqm#O_AEc-)^(LX^V;%fit=Y(NBJ|a
zyZo72`KR<Ozv(*5KknM{j}zq|cOB&)cirVjuY;bQ7-^ygiTCmJj;2ZP69Vt?Gk&vT
zdj3>FVk~Wn*zNY)NczvV+u1Wx^6X#YErabE{@^{g8Uw=y%^6}0?BTE|njlEKM)ZK1
z(hF3Ku@__}Ju*xqdP8<CRIkX)dSsYu^oHzOs9ur9>ycqX(i^gCp?XDT)g!~Kr8i{P
zLiLKwsYiyXO>fAqh3XZVSC0(ypWcvN3k767D}52>KYDDKB}uz(>e)7W1M3}KkEVvX
zRIli+1?wGMk7k4!SFh-<1?wGMkA{?y(L1_p!Fos6qbX%%_Kxmau-?&G^;MBEu6K0T
zg7uEh*#q79-qBqP);l_H4|EfHM|Uk4(2eZTpcaYwVh@D30pX|~fKz%0>;om1{`G=x
zVjn1b0qg@Mq_7_4q&`sg0@w#iETZdCX7z!x7r;JHVjWk967$~PdD#nKA1JLoQBq&&
zt$KO^>;t8<Crausy`k&{un&~po+zo$^oFt*z&=p+l!%$sZ+b)73t(R;dx*PC>N~xn
zycV!8ls!aVW?#JrhL8HDaodW%Q1%denSJ#h*r4lCPV5t957C#|SMOoh0`^r(YmdzP
z>OJgQz`jsA^(e6p(MR=M3)mM*Zx57x^&WODV2lyU9BFl#q}9>OxWLQ!z{`Zd%WZ*|
ziGi0%ftRen3l<zyJUM}v+`tP~3)D|j125C?vgQ3a_W4)j2;lp_?>X?_#{s_A31kiX
zM!4!zu$jkPzWg-4KRg!WQy_Lv;bGWD?=@gx9qX!-a3VM2EYJ2|P@~|K9x3-M{AV!m
zbbPMS+P16B$}^fSA2sk_@?}@9BIy#om>2Mj6FlQ$L(2#kuebc_G1#B0@0-m$tE0@K
z2D0cqhUfCC&Ir%DejA)<xQCLHjX_A>u%FW25BL^Oj0pJVoBi{7#-WC0`Vve2u>t4L
zqKpLaW)sgk0AR}1H{ay9Y0;MOXp28qjh+!tPCNGT<@`RrB3SM{D%y)Y;~lk-197*T
zd%F652O%0yZ07al@svx37O<$l1t#9!iKE6GX6(M>y!|VB$7NmpTzu!Oc>jNJoM;bb
zxJY9a4qtQMVOJg8kGOCfqY=pS%t%lMG)H;!m+@SF={+vJ0e5)ud^h>F<5_=|YktRE
z-aFcG+7qD3KbeN;#>lo9o`F;yZ5B9y2G)bTx!p`Jh~YRMAAtwOM8GFOKkjR9+fH7K
zTwH!}q0J~teCP*2@7u?Bdnq5dQ<%p0lH;5+6uJGACW;k@6ZrNk6!45djqtsH2MB+~
ziHI{UTyjI~s?E;f*&ME!JZHcHj?>f{<@fS^CKjX}<=Q_MBs)!^=2{nfCorK@=kV_k
zm!JN+Jb@To_tVD^@BIX~tv<|LEhbx(3#YJfn_Mf}E~RLXq2lj$;=Q2>@F@b1I7-HS
zU-Ngr;L%r5G7;U-ggQpxr#}WXIzoX3nZ1J-%U>^|@l*QR*n07e<J<v0B>(l2_y9OG
z!P>{DFe+)5V5O?9-?yLp-UCsLJMk>AjCIvN;6OE^F}%YsU2@eX1fpk7Li8aK{Waon
ze2YHTMrsJdIfYBeTU>R{M7sHQm{egw#~py%aBI?x{_(g0vO3z}h>&aIjLJ#_FfB%=
z95=HPQGAaRMWudIyMw4jw^7a$&@>BgFB9!`Kl+_qGX#-1I~s@QLR&1JxL1(pqtWp8
zVK`MKQV`loldA=cZ*$cxw8;Q7{RCJUkM5xQFt~6^KbGE%u3DUTqhK5bBPda%C|o?@
zj_;<}D2g=?re`#AK=u-E{v;Y~d58Z12Q!iP+gGVesYQHHa>0?5)Z`h!)w6+t>K3^w
zml=QAin1sLl1AU-IN2Xad?zA<^ijc4P>sGEu%Rb?uM>U5hHL4Q|2ygX8mDvvMf?R*
z>2s%1w*)tN74A*MscSy)1h4uuomcHQ`YU>&T}JIbLbZ#NiW=!Z3-Zk~wNJulfImUP
z(F<|xGtd)7^#bjWjRNnh%ynQI1`_2(re$zjFax>fN#?4HM7-MY9#C7z98R}B2HFLx
z*r-*%Xc!1b6pKc2Q526V-k?@Ij#r`LkK-J$${0^B)vsi0`iFcO65xwA9xA81)FN}?
zfq^7k)oby=&RP(VZNr<uH$Iu3?ny8Fz0rL3g>TOAuvpL6{AD5IgnwD?`vCIr4IPC0
zbbxCkT)TwW!9~_1Tu;#}#z`wO-OocJ-^^ci;tP#k2QX^iH%R=Hq-FU%NhEg7uBtqn
zQ~5pX{N~D4{|Oh|aT)l_l%!!l8pca*n*s7|h^rR&00-g`aUX=?$?6ksvkOOHqt3aL
z#c!)8g2vV;8e^jTMv~a_i<e0v!ZR?BzU=blrBS9)uBt-Ys~Ay(60|<WOIbn|KDh%g
zF1WZtW881Z+Fyq8;@uFSFCFG8@Z9v8S>x`#I&v`t?T742cS!D~WoD9E|HAxbuKEJp
zKW~s9*%=htRQuq^mP9kI#M|cgoO#v>NBWGo!|T@-XPtGUWt^SsHg`UD;W2RLV_tPG
z55uaYoJ8qzli|#<!WpOuAVbOP-OLPMa5X!a9|094y$8q?Mk8*%L_+W}=Bk=yla!wd
zx_SMCVxqh*H;wzQoCVYp11kS@%JVE2=l7roB-?oVOJeA3=fk@Qp4TVa1hf>W=|f5e
z$+yLn`~ZezKD-lvdK~2fM+cCbf*2M{XNX8wZEm`&YPGFPH<a#&t_6QRjdkRx5Vr~V
z9>Z7$?WpM_jtpm@WRR_R;!rAo8DliY_JjP=r-(7xL^Ne1KyV(>;^MgK!NqYF)%1tD
z;4Keus1S|^2?z-ANIOcT9VpV`5Uqu6Ik+v_MOUJm*`_~}x<k#4Mt|ycC~RZB>IYK2
zfWmvKP_F)%MtZmtvbrq*y?k^gRLP}Ru6jQ~&F>F33^eYPT_AuQ*Zp3rnUr4=Mcc0&
z17-3fHCk-!6M{~<CYw~JL!|E2B{b~kRd1j})+VT$0pap~BDq%u^Z<dKzSXDD1WhP(
zPY%Pj0qQKTTLgWv6y|yG0a_0Y3LLL(re9*}@K=$j?S6kE-+uaSl!q{JpD3ZGCWC(M
zEnE;-(HKNcq>>;U!XAAm)T!#zsU+0*p`&4}f`)=YG2_sq?{VMf4JR7j<$o$fR=oY!
z4rF+;0nuk%-fhXOG9l2uA%U`i!!L(~#8YlWKzZors-2D&HP0sbV_YrM)6wi*qIHq1
zBAr;@g?kh<{=Zbvi+B9b7j!gwCuB{s<KqfD9Qh^%_}TbEfEfw8C}M}JWor5h%5SJ8
z21h@%gjmrMpf}YyOI&d8Y8#=l&eX8aUo5JGMm%)>nb1b#g}(d^Dl^$eb$R0g*Q4;Y
z!}l)uiYjrTZ3J)sIq1J~m4xz*3^E>?%*~Q}qRaab>MT^y=dUd&MFk4_ysK&sDs8fw
zY(Rh*bRJO{wDFv5e@buBZlV+QyjIln=&*V&;J#*1ndXR;tJg~vLmdWpQAI3T$<(fc
za!sM6ES5;e%$MXxAi38&`pMNJq>3a5T)jIadB;xXh#|Lu%2y1R#aEA#9Jv1^RdU3^
zRfwb*C09#!Iz7@1cqHWG5kJRuARE_eD&L}uZ-1RQlpT+#G<FV8^SN&N%+C33S{y%+
z9lwvjL^LXcU<6dMNMSnH4VQ#8S}MN<g`4Byk>n{13E8Q1qw<a9E_x#FRQ@6K!{aUJ
zGkck@yBkWq5i~w{mgi#r`*Lf~539t7D|}CT_?OU>`5XVYL=RC0Wws@Ipcju+Dmt7I
z;E9E1{}4o_d(|J61(*&3UZn&@U1{s`N4TnHK=0M-2-={T=7^T7|5en9TwTK|%v2*o
zjQ$BU5%`Fq3TonwO19*%U|wLTkWmxWzm-r!HJ1&_UnNJZTs_@DHF4UYltTTY>nKT#
z`9495@kekcy|tfMjwtv{JLhW2O_N*)a^vGkRWsRm9%hUfd{U7zHyPWWR^=!7BEM9g
z%HigQ-g1+9bPK&ah_ObGek@{}p#+*a47iz>3oozmf{6<mc-A>j6gk>l#pj_fWkYpA
zISQy8zGf=QYyPz&A0Vw?Puc4Ven$v1*sRBl67#Hf4`%om-6lTQALa7RidRmO_OE4g
zW?3+smq2m)!^+!|3)4Iy%CDlRYI!ODf_SK<P?L@Y3eR!tAux%14>8@%O;xI|CoPz#
zrv1|8L)tu)3M@2nag)S9$d-5p;esS7-#I&|EvezfJ*&KrKJneigswzsgT?(y`4z^(
z?^IM&SZ*rH`;~t^roJhEf--`H??A_Na}|ZFzT7~o1oe{uFf)=@DOL*l%vo=hV@8;p
z?(=7h@0BW;)AZ<3jMNy;!M!poUb-JW-tf_dXBv(JK~4-<8BfX3pP(YqfR>xSUFdPW
zs7n?S&;4j%pKXibFUL@I)5QD&ui9sahJeNgx2`k%r)ga*Qe77lD`lRuz($k(@DUvI
z@@CS7!&cPfYQ^9fF4ufS%)1{I3^z4cZli3Pu&9GtOtV4uU{*X^%%3+O<GxOBXLLm(
zU*8nN<yVNxDduB*n*TU}k(m1wFg49aLx)`K>BpxbeI!jnWf4^>SO0=-8!g^f%hj@B
zTZ(ue?w%li$I8{Q24$8(1lG8RD^B&*<IWaQmF^AVw_L8a7?c|gjl-3LG>z<siNof|
z#xZC4rT3xuQ~yAL;0J}bKQ9&zzV;7BSsx@l5}iW*@-y`dXhJMtmG`7Z``N}y=)=Sa
zbXV}c9*bho6HUyMhx=H_D6m52zPD5m$S3AcK#;?qlo~}QN_@L89^6DpfyjWbW)9~-
z2;zEDXxD@g!_>dBZJ0h&z#vy2V)76F9T`#(*KWPX{K;w{(tX#KrRr;xJC%BVb9)-5
z+R+tgk4<*J3C|^G)p+!TR=JOF$^YP6{6F|+`3K)XR-gHyTz!1&C7vqntbazZjzG`X
zs2Kkgw4Z4ZxnDcVJ(H+5{6@5PwUyIse6B<({ps`xpcwN!(P{(u+Ha<Qak_Chew5g6
zHRWE@7?Bh;j#SiW+y9CMf-4v$!)CtLkiv`BKZKMHh=dn64s_M6NOjfCOQB8?gK2D4
z+g&cWlrgy@Yn!_cZALSbU!0zf<(i_eX*6!nF2eI}zD!fwT<9ignEO20`Yz(L_IYj%
zXh7jAef<RThECf2lasWU`V<G={4(T7+3h4uNF*(A@a9hq@GWMfYt?zQpK>p@#bjM5
z@0ayDL{t{$Kbs0knBn?9J|Dkdf=KwK<^`dGjygaEeF7&2!6eMZNi`3tdD69N9!05Y
z-t=@yc>}Fh#gB=sz%4(wU*sgU<L4bNKerG3o+6>;gL=&0(7mugL)}Y$X*#+`EBdAU
z(vo;C9TOnQ(Au?C1aM`7I=yiBoL>Bu`#u%Z32l1ew1Z_IH6Z#!RO~`qnyYq6T416f
zR((lS2PPVScA@|cuWOY27bhC^sp>k1(~N0UeW`dBfk5&xgeM$ZQ8O8WS2#|h8ShLq
zXsmbUVQsu@K}7`5db4a+s3Ptc6(Ms}#8STex+~&2th!J+@*w}zb@=8_uu_JFTj>o^
zgk<_&51C4h@V_)O`fzM$X4DWRYK?jkd|_f#oC#t5-#V?MEgG!I)Z0Ns3w5cd1cT15
z0fW$`_-<P5sp=~944{(a8e9!fQ1+4$9ZC~VqZmyQY4Jh$jWu9_3A*GcE?o8S_TMc9
zo?O1YGyW!Q5uD^je-!9{Na&Z+sz8q+)J%(fKD4hE-rNPz*Cung<0UZ%?g~NjIF_Gj
z*#s`2HeqFA4ek6S^Y#ZR8gXl}I+)Jd3VE)J!;z?I%Vz{I9iuvVwe?I;3kGDgP!osJ
zfwg$e!Qz1^;`_YlZBfKCt5L+|V&Nj;vqFro=|o7@g)M)i6`Q`6w^BnZ>~$%yI~Qy1
zb?G=Y23__fExgyI|C9pqix?8&TNT5?7m^!`xvkqUsHDr)b|V&dyTlT`fK-MW9lw&R
zkFbg?$8B=;FL9}=17J@v$IWuJm!|Jal`P3|yL)v-H2g!>jFFVR%rRB2Zf6eMS~Wyc
zzGjZS?)-{G$BS<6*iBC79RDHLL`eRbjuyH4BtyE_<(j`UrI|Te<?6pM$0@m{jVT{8
zUi78lMe8b*cp0>PUUlBdtKM`fEAZO(s&Y4e-Y_Wh@$<>I%1jDLN-l-E6bFS&G_#F2
zxTAR0VUscnQEy7hFaqcdefhLgkrCC_rI;y=m<?-b%*x*}{Jd#U&f@2jOJQj)DJKxs
z_O0?40<fZFR^<@Ie5~xF7%=vHyz&yoe5Ewv=deLA_1DCH<qe9ElqWEn$+eG5jsnj}
z?t2?bF522<i)T_`#NfMe6)T$h(`8g??HgQ-Iqu#x5Y^X2oh9lZ#Wt_R^Im?p;+F8C
zgRk$VRhl0jJc?-f#nW(aMT(9)3ZqGOB*u?RuagR>hE4t@8c_or(>5hJ3My#$d4$qp
z?(%%Ae=@K7+~^*JkvH31easyb`05`@=nQ_yJoSq}Z}6J~0JY6PfWg`hU-+YW(VZwN
zX^9Y*G%Q1AV#_CrO1^?tgUz(WFLr1w>N2HRh92WZL0u$d)u34VMKD<n(n>FV?Jt6p
z(?oC!EeszpxbA?n*|JD<FEnxr^mpIFwGn|tNinTk*Un*~4pTc-q8joEJm>`91}Xt?
zYF~oNe4YZ-ooHFDR_#l0r7NV6x==;(Y;rf-G!f)GPGMVe_bGsb*2Q>Med?_}j!vB}
zYOwvnB8oda)elu0HQN3uh2e9XFIPTT6sD@=lRA;tijP<quKo>Hy!T-f7DFlxI;8bi
zogx7R8I6k1$I8#nJotvAg-3$9$7TxxSm~QZ-Or_O#aI^#BpyxQI>OW0gWtxJRBZlI
zO@c=H3FQX|f0Q4D=G(kkp>MNolY-wI&{{D}?GKg$U00K%Q(O)3S&h0Wrcs60Pi4?}
zu|^6W!0{(ql(+U{v~=jqZ!rS30cMKLN}!bEGN64wn4`G?^nZ$7CtiOGiZB|$J9AJb
z%=Q%%eQOop%zXRjn4UAahSOxIEdJ4Bn8#sr2e-*18434hB?UXh+fQ{zQMI&z#GPAg
zd5?b7a2(USkGSs`!6Ff;r`#|YsVml_Z2~tl@$Kk0Ui4S)yG4{6nV$nBylYdOL0K(P
z^hiYAV;fC4`cc@9mtxy^3O^+1g=PVIX=A@Wl>kUDUTAYrIFtK6;-jz~|1Fiem?mWH
zSULGQztklPNQ%}@lO!l28wa_%LgY!@hDtyv%pi0i7Y>s7yPso12gWOujZ?r(AsCEH
zU`aBzIH22|=TeKxt@G6Eh&5swD7bUH;RBld(w3IW9opN%v|um!`UEN;YE0<h@^i1d
zxDiNEK-ed!ZHDScaMMSXQV?iLYBUl;G7yd!X#8lkA5iuU`>47BJtd->z8R_L#Ibt>
z$9(-T;-ZIR%Q6o;_Q%VUAd#vEpF2Wb3)*Y@GTJL7TMx76xcvmi>$I7U)fI!O^${dv
zs6z~ET9+IhfR6P11<+x5Q-XLcUKKO$bPr&DPZ><}k^C^hpzXOmYn7{i7q*)aTHD<<
zg5-)Aqi@1n^$FScIKuoDG)Km7AXA3LBl$E?AH}myJ`~HH1pE}G^8Y}jOBtzQ*folh
z_*ztKH;Y&(MjAB5^7=8u2!?j$(Fx!W9{)~s@<j{g7yN*^y6?fv8cPh=*^==gV4ZTW
zk~2R<(r0TZ9sC?(fvae>7>g#*s@YP$|Fc4T!eYWfC9*qcVu1yU1F%OR{Wv|iFBI7S
zp$2s66zWs-DaaP8($EGEe3L>ARWE%2YFvaRxo0C6(Iz6$h$NnM#WMyAZJtPcZ}OMm
z3Wznh0%8z!!=lZia8J-$8%+<zRS^E!Y7t=`Q;2l}+FZItWJ32q;QAT1C2bq#-yLjI
zGB0{uAXq{ORHaN-_x+U8ZZ0l_0JB2-x#8QZ5P-p%$u3gKaC;Xzh_D!mqUlOq%Fje)
z{S8D!O*-a=G{ACD6yN(LW>BQzwm(n90+h@C*!Tlbhbv~GO(d;-jFMt)EuGd{P3m&_
zQelyC2QAJ%F8Q+@5$=1ja9i`Rq?}-mM7cUs!qO~O#S<k*f?TsvQm{O}QLbJlIUW}a
z>@y|o>?l`|wJ--kwX`2Oh08^zN}&N!5P}uQH04%^8u`TsAztJc%Lj&bd!F>7WHi04
zA48+Ic#BmB?AbPh2&RYuo9~=y$WqENrX56%t~+39;2s$msnM^{JTIf=$27c-H3GcM
zlxRx#G^KrB;#FTuuG(2?%Cp!x$xX8>yCAs0y$HVdyg}n$`9i@xY(--&8C_*76?Gw;
zo?<ao?avWdQ>Aq~|7tF7+QS3`*cD^98dM-!cRPs)bRbo&cGVW7siA-_uuG`bRjo8O
zULbtfCG{uK>Yvwdad{t1GkaimlA8|YM7K3f6CmuHVw|LI5!x;dc8gaSZfqmwTx$Cc
zoda?*imU>#-=ubf0<mctz=kYD6US(R?lp>{v1f`QLo9%88L|x=5%&t9$uB>IeB0M7
z!BcJWfvxUe2ito1>Z1)Lpnz~$jVH7_WaSj5KTgvzED{8U_WH*j#Ud>2LPbJ;Ha1WI
zwY;82iCpCF!$SWaR2^bbR0|Dkm+}3eKnfr%EST{X<8uopxo+DaN)2QpYf^uvs%sEd
zK~pkw4+kRP6k`)!$3qvQkzH6gfen!(To*R_hv|VF0Qw>v$aP_Z3&4ZU01l%lZ=XUd
zi`W{7bd6dc@4tu7!3VM2gyk5kdo0fp<uUW&K2g>VvnNg@1zWJSt*q>(bdVgFHsa2!
z;r}iOMkORO4@rlQfg1(}yRjUJyGUQNg=B7+RtU{c<v7^Z2d@QtiPwO@swjNT@>lwa
zyx{FWme0ld^91k`Lh}MG2iMNFB>`$yybCpGz+xz?NCSJnCSyLSg(pBnAu1a8DWhES
zre!c`uo;@qV$}Yc(n4Km;l96d`FCB|lKBed6VWMTg9fd?KM#Qp;8jPV11KU(vSPsM
z7M4_DhC=#`?>sGx$3n897z85BwxDzb&_jj6f~$%ieJ2o&4U(@A6uBm#7{^eI)2Tuo
zsXFMS=|>_J8B)E)(1@kI^Jmdugk@EIE~X==9pHu7^6{kLc6e|CRVu6zlZEY8b0b3M
z#X{`0IzI_$41-mo*Ni2ZbGLu<qsPELOx387VqPkKjr7x9j&9Oj4zY>5pXiasi|R$v
z3kB4;Uqkyv5}TIPs{Ib5-<`Q5R1|1T-R0=K-Q{Lp)FM*<A1yT+OnB$CijntSUIZ-&
z(`pCI2YHe72A=IzY6@sq9lSjgl>j-UEnV*S3=avuC&d;tBw+mnv0zDWv0}lJ=7i<6
zRyoVzs+*qXs#}tR{(d^^@8x6~Xr{iOb#T+T>t5{oJ!AkTFRDF41kk)AIu)o6t}a4Z
zpheq0ml%U$`#W1Od^8wx{(snl0Yyf^QE@&j{p@j~N}%OY%ZI-FRD<ZAXnB|oFH84!
zCd<{UjTLLWoe^^NEU99Yx6?plcZCf7u=+XHby%+XL!8pYyq(yEHAvo06ZV_qFsOSw
zu@5`QSdrlE#OC<T2tx~~jZ+R9yqy^S+whYhS6{|YtXxwXr#uns?VN(?f~n#bZ)dh#
zonoS-DRT9Bfb_@xd~wP?qqj3huFf%eJ9Fh4N1T$4x9M_qR3w37(I*#StojU#Q$C3B
zcFw?hkwxAS9qH|yE7!!vDTh#Z^)N~xAqp|~T3SG^DV~oIiS;s!lvtX!sM>5cSmBRR
z-^F4yN9Q#`3r>geO-&~ZA~Cr)32PDMe5^WbV4G|YOi^g~=ryBnzu<dl`NMy*FNgzI
zDMxipn#SaGTE}<stTdZvDCukUlf}wC-qe+QiW(z2!azWqu%A|6Nz3<6nzbcU@COcb
z+7%d=)LNaHTz#l=C1$y?zXxW@VzQQn!{$j+Rl*6-K&Zv@w?Fa60m1=1bxVY0FhWGN
zZwcgvKzJa>z|Qf#t?1OjZzlgl@8ypx280x{x>%23%gz;D{=tFh7bIv@DH?B4C(30>
z&3`=duYSipMh)TCj{s^Esv?<ZocCVwdf#T=%Z5!bjXhuePNm^_5|~s!Ez{Dl)N|j!
zW<QjjPcdEo{4UzJsJ#!;4tHy#{;(yu71f*)C<c~CsT`udlX^sIg(H%Kwn47idC3Z+
z#zfu7TM1mW3gA1hWEts~^u$<7s5oiV>$M^L4wE^-NLtWVBCuo@Y=6q7=&(>_9HFGH
zDascsG74iGwq3}wLN%b!($&qvUR<-+dwInsGiiO2vH+V`(C@U0w%9!O0G(()K|`<l
z*ubt(eR_{=A&eJLUeKE6QscUh<n3ZI<;La<_Il*!-o@`BJ_B!Wt8;5=9-^VlOGRTz
zChi%P!$fC*X`2T&G>5f-7AH(&VC^X>|AtQY0yHDFN|1u2QA<vGr1Cgb@;wMamtOQA
zc&0|d{Ga;lci<9Pm=LS%%9I$jw<_;SYImg-QPD4zW=tqV4s`{|-YXx=4;PVoL+z^W
zzBF$qHclU7WiccLYd(yI1wx38VuS)L5shX#FPU#wTG0rEqW<%_Xv0_o@7nJf4_3gk
zL~LZlHSBxgj{!pcI6a|;!lX^hwDdnJKaA$n8k$5asNGJOkd0dJX_B%>Oxm>(MlC9`
zpBv1c%>MotC8~Z0=Fg&ch~}RhDEbSH!4f3u<MfTcQ5eZ7QPF&61CZ8gNKqE5QTZp>
zz@)yQoF>)(jQ}RJFJZn%N$O^lR3FmHF8?GO@S9O}GL}@rdSGlYsAW&}jYh1RG$^%H
zAH8-d!~1*>tyT2({i)CJg=$CLSDJ^VoqCCOs$eZUu)?X<NQf&!Hi<qL;!3!@(i$b&
z>`b)Tud!EEZy_-mO&TNii(sXIPO{udc8d@_YVRqz6LDK}T-f_aq#k+S6nf6hL+muM
zYlaDhXzmSY>GDfuu#cu$E7pbYB)fzGM$a0T`e~+_zf26mr=?g56yVFSXmUubO3eb5
zS`-#re6!5@pe2L^7eb<46426kdfuOm%V#NXln~FqlVTQ_`|)*G=vEZ|3O!L!Ool?=
zq$@~GYZqB>mrbfbEnx%7yotyoP6g@7K>2)I10^N`2^r<Q)#Seo(A3u&BB=zM@R8<X
zY67*HHHfm60zH*5RZZ734{Soyhmru*Wg2**01psfCf4@u6I9P7`9@u;fff{AnqekI
zeGoFfKh;I^qICJ;yCP^lfSH40@Lq=f->ne=<q7RbSV-!Mfx38Qh+6n@Va)f<N(+Yg
zD|ez>B9n5eb&{@V5GGooZ^g0#n0w5Rp47?Le@rK5{y;NV{Qf8~t3m^+t9lHPG=X`!
z5P69vV(^Rs9${Eha2pmQF^;D3m+8tm?-j|NfLB0zapzVfUL#5QLkT8ONobCl2-_dA
zRpd)?QWP4U8D}ou!MegZUUfR2plefd@Ch>dFumuBcg&kGL`_lSMK_tM#;ZMhng|g1
zbTzu_F!+wkl0rbfl$j#%LIQ!!RzK{ea)AiQ4g--X`Nd`>UDoXJ^Ghc%8fF{<d^*L5
zn#z_Rj-XMOq(%c?V7P{!^3f~Z)b5sHr(8%YwHf7`|6oJnWmcCOzT2z{qJkU3BG8n4
z>xW@mODre+`p3lZs?Kh?dKVVUwbsaA%?DG_Re)_8DVX|3oE!Q`>jC<YGeRHHJhhM9
zcS-F5K)CoOO=4AG{`Ubb(_!t1wkx`EjH?-j<yD^!g_Q<O^FE;Vz1U9Ax#MxKvyNC0
z_i8AwTq<RVN6YaMGck>XTq>phV|M5xl~Vo4eIHXPm!l)q76eMU1XHe;E>aoFL`i0j
z*A*kr{6aRs=a1BwmuLRNLWGx&3Wn+H&B2gbBlEGLA$XlfdCecK3ysl*#_B@1YN31*
z0k{@S^m&{%qgKOxGoc#GFWn6}fkuX<J{+&8n=)t!P3fht(bB4}+~_$2xGmI}G;0J{
zfT0L8v(@q9dXz|#gHU78PFLBwlvnkdM#VsAv3f109Ie}T-oHlUH=V|yfiP03rli!0
z>K3P=C%aQBOkHpI&A4#Sy})}VQm#3{6dd1BC9n5^>(q618YO0OTJ}QCx*l?=fKXpR
zE(f{Cs650+q4-=69?~wL90E@v@YL$)`tHNEMiqu@SQz_r!-@LtNHmgwWG>8<!)B0V
z1A_Y7;=LlvkGv-4PLR%zKZhBX_ezxf$n)xSYW+L2`SyLY-^Mu&80SG<O7C9*-9UaN
zFI_vD_3o#9`=@tFh0ODSI<p9JN>!DqAEIsp+Eqw@_9O3)H(_|%XGI|@veDY<6zAh_
zp$M>ouiEFO=$ix4uc{@hpw0Yuc&J=tn;L-);5WZgv;VHV32N_R=|?^OS#<{c>iNmE
z_-1s~<)xEi6y?1<ORm9UzP9jyu~Rj_3RpVjK@ueiVM9k$6GHP*QXp&RYZFA85~>lx
zE*5jx5s0AybepLGHZ)g`ohE1_-eF+^3BK7(m;iUPmXhNpM2f1PJXVYGZ5C&y>nGFo
zgM=KHBdQRY!H76DLQIn=8_FbJjiWiZ$eQ9rx$7s3NmKwX5gbipp4f&Kb<B#TSuPE*
z#_O4jhI+!YVb%j-I(CXSdEP`M)TN8b^Q3!hM$bHAkGh<IOr!ckH&Zi*)Cn~%%tCsd
zmHBTMgHK@hK>7WbBK5}=ajr~Y_jY<+Ui^}f7N@AIf{>qGMNbKwha+1l>`4{ni8a7D
zu?Dz}bjoGex1-ITv3@#-DZf~N<=o?Fh`+fSw&v`B4ghhykhY|;Mw|wrO?x?*+0Mo>
zc=a`%UTK-~4D_gTYTSf8IwhZVt}KCP9j{PNsXt9{>ai@bkd1Taw1_&N=4(LcB!uEM
zg<gSh84!MYPK}%35C|`nCGxCyD`G{YFP#7h;|Uy=M+b)jjzXsL?cdTR33AQT*xFLd
z`(&CxNplb6HQSbtK}7&#QQ;O^;lJUaR`65-h;6Cl3T(TcldEvFajz5ogTB{Krd3gl
zV1I)~U;=_<8`+}N#Ud6%`CEZwpxC!-{sdERFwTliaGE{gHJ)dk7yANOIv1J8`x8+b
zGLjL6aPb>y3uHL$E8{!tAo#j&vB@kQKp4l|$PT&N%;bj;X{X+)Cp;;7FReQ_w<6Ch
zlTEJqcTy~bsRPiAY-mC@SbGfEkf=OB$-pfP(^y`mB{GI3$qce?7aROoW_HuA4xT1n
zG*Gmg>61Yvc8NuyEkGX=V$IW3iiUlHyCcz+g@R7UOj}eEQO8eHC5SL?c}CcmLd*_S
zQN72kR>2%-T?Ydk!3c)B`k3F)p?-V_z7{&D5gbG#pqA*HYNl4SjMNF*!MsQcGuGvP
zBAh>n_evN>bi(<A2uz~)7@=xJc#iqkBe9zk8+kn}Te3dzEEOe0Ga}@9X8#N|8>9MD
z4toTEx^0u_b2*BPkOn+U^Tr@tM9}A1@oJ)Ua_$f~kmv|3f(my8p{-+VkAxdWjuRaJ
z>mA@Y42`O~un_XRR2D}Tf>m8u4C#`THqsQ<qtVyrMj|)b-NPP2%(K{h;xE(nApBLj
zFvO1|m~>GHf0cR#ulZ80QBaMo&|`5zDFaWVdnLyirP*SumDf)<)0Qi*Ut;2;j-kmB
zDz_ak0^5!1$6O5vTTBGhDS-Ong@ELm6&S5Mtn$Mh$f@0`<ZGyxXsM<n75qA=sIkE$
zP<vqLe#HtKT3qFc<>J#;RH#~M$V^lo4v>sG7|0CCL}rw%LnLdWWbIa-bxf{0i5_rF
zISxys&rP6tYw5ElcM_NXbd<k>QGoGx+jv!%42%0$ut^+Z$2h@`WSq6U3;smJ;fICj
z0KN|YP5Llw%;}Ignx04Z0TT63_~2hbhN;WI#aRa0)UUeS?Vc^9)|0BIk9Yhxh{jQm
zX+qXv500Q}l9j=Kh!C+(93yJ-eBe)^3O4ZecU~6x$v<g=v<Al4LXIu=qX-4H`+)<;
zLSx%LXl!bG4{v_~;01gtnkpJoZ59ZHl`VD(+=UebvBlt?P!Wk!+oSv|yqz)bvEI&p
zo<;r%-p(%A9%M8%9OHk2A17=bol29L^6Sa|Nxc32JH@$j^1q_)wj9R}5>A^1LNZP}
zvbX$ky6|Bt#66-A3y*<{P^+g+O}^WLDuBRuL&wX*iN;7_{_qWL3Q8l1dTjFT!;PAn
zEg>8>AQBb?<QW7h;oSlU%YXL<cK;N(G7&CC)K9d-C_Z7QP!Xnxs7mpv8)T`U$UI75
zj-Vv~bfo%OV&a*t-^bpqtp+?RRs&G7IG7-aO-np6T;YkMb$BLV1sEHT;yq~>uX<f<
zJ)S-b`mps#JNxbTTamlE@wh?TGK9rEZMmxUX$`2|Hu?ETq3>MS$bF~Jpl2W8?SK9l
z%o7PK$3H8%<A8GsPHFF<{aODo?<up#%=cjLvKtEM9(eU4;VK6CT==s_LfX*8;Ubhl
zx1kA|^Fec6BF$|URK(G`#Xv6($m1lVKMAuO+Ihl7;;=Ab{uRn+FGI@&EbMG)S!0&J
zAKwFtC^N{KJ$8ECD>_;GWLT2;Z&bmJZVPZw8iQwm9|fg-8~-xi{w3|ULJZIL=O|}K
zLTO8kueceq?3Fw$1gf1CM+Oh^OZ)y84iI`qK5x9ZZ=~l2?<Xd=QQ4E`I^d*6Doi=3
zDAbrp*d8J}!*@lY;J~QlU18d`Cz(nKb2r}?81YW1CT*>}{cEt2P5@wKhSp0K!LIkU
z<e<df?`z&|MZ$*T4d@*Wtqtw`wDYx8hG?QX6pdJ!jbySFHQCxF4{JI-?=^OAtSk+w
zJdBQogg|f{9ZV}?eq7PhuerKQA;P;$F))*-6FPo?2c15sznfO~q1odo04xMy@86J0
zOLxw+w|+@`!_Xlj5%%RF_R-Ww-)?xHFQs7GQn*;KxgJFV?jw{wLg^C+8VIE?KN$i6
z=dFvreGSu`A!s@3+bwwG?W^%rp3OQMfB0z9VZIP;@H75PI9tlcxswHvLnt4#KvJLD
z$H8=gmUc-ifH?s)ilI?L#k`yUir<68*r@x52u{7FA<(4*b%Fe#$1Z{xS%Q3zk^SMP
zqBwBD)Be(aYTO?p;R=|0-HX~H-S%z>$X^}Cnf^Fl^cT2IfT59@caOI9g%5~IfT$-H
z7fydBwYaK^k=%vkBzAvw_{vpTO7|YdNGGK<;YZwrEUKTX_Sm1`cAcI6Plt>?i2T5<
zu+mfQsHI262^(Ip3r-$dc{jFlt|8+sUi9p4R1Q|3ivBmmozgmy7agp@%ir)a6@pB8
z6ECF?;^p;;n$$-2NR|Mpt>~hTP}F-9al>E9npK-wfv3C_Hwm(WB9D6w-QSCg(BP%C
z2=}_tov*iBxu;~cxB-_gBphumU5RVXaOEd1N27~&Ic_~GajnHoir+OIZq^G+hzs+^
z<KDKw<DcOfYn`2gs|>>s;3nLXQtRrK#l==!keZ=hqWfRH3>Z%FZ^wOaZhICk`lCDB
z%5Jx2&z@|@J(0mLMc|G2G;-AKR*!n=u@zVGm57@|=_XF~;^WLpx?Yl!1wW3kt}I`@
zZk+(6tK%M6TecAw&e8RKbpP!tkX3>URdIzUE|Ki>;=liEF7^Aax8DYC(6w5vD{(g_
z?pd_1(tdI4p9td~K>A&Ss{qlItZTL3a`l%k;VoaMfoQ+0O4V?=_Pbh3vW~()VddgC
zhLyWLtLP?QT=b~B*SGI`j!QRe=+Pi?Q>k_*Y4Cc+HMps8QOUXurNwJ;i>0_KSL=av
zi8O9`#4Uy52GE|@8UFut^<mg0hI2z#8(znSh!_k>fUL+EXNSRA;NHXWG)QW9AWjU6
zhhxlOynyc})j<9G5SO6^|HLWWU%Z8DI}r6F^;iA{G(Zv7et+>pE&M|^k<~&t>;I&9
z3ZD~^&l!dr5(jq|UzE-Bn3w~rum+6X(Toi@uzZH};uqlo6vhD^@oQs8{w4tqTGmbU
zi|;p4Itr^;7_;S<<j3C-2x+-$1wsjW7EJ||yl@lG*u&nj$g0Pmxv=Bp%8rw(I!><c
zz`h8J4+ii7s#2=@MTNo+loepXBw*^uU;rOLusu9|1WRW(vq@}uYkKQ#Y*Onzt%2N!
zFgqK|tf2h{HjLfK1~3~N&PK3ImcdflKui*n7_Mz${n@Q7fsJ7)Y&0`4+}^<=SR{)A
zIk*E5mptHNFBS)~vzUd&vO#Pxy9HU?1g?!@<JfpMf!)sTU=B8!-O27^PL|DbST38w
zmax0o#MWsn{nUci>8&$b3tH#3&TpO5I;%CmHLrClo6tIu&17>~TI)R2(0n$F&1Q4h
zbe6|vum!9jKn8vXOY|R#!7>atfI+O1u}q`Wh{A4WY@F#vY6TB4Ha@}@fj11Q6C#IW
z(~fOn?6#=;qJ~6~eeOi_2-FbUiW@njZ$`zlZH#5bjEupX7fkIpsvq9AGd9Mu!ZOst
zb}%+M_7++sszTMqnd7$6G7^i1`ar*o-5)<cJ|UjPJ6T1-l7s;XEWydvCQeO^NMwml
zR+h9NDKUv9Ihi|oVRAAqK60|nDN9oZrmz$z^YmZTKczqG?_}!+%oq?ofDLf6jj8ie
z<y4mHWTgZ12gVO%1D$O7pa%yHroC-;@8E|9rw^vL*tFQR7&5I6`&&6Adx$iI4RNya
zp#?*ehO(hfhRb`cCM&Z#aV}xn4Uspn8=TBFZ2GXMVQiR_72TM3qxnX5qm%u>Hq#bk
zV>TySKYZ5ke#6;tCo3K?dxT{K8{uSk+;qFvGj19=Y^0iH;i#>n!ZH`H_uR7OmNaS@
z?19nCMh_azMmt&Mn7hZMj$vb*Z1vdOvBt4%tdniJb@8qJZ)LYS*(!UE-C$>SCo9RA
zn-Q16GMsEf=A6vfOqS_nqsKYMsd<bYf9H7h?bZo*kpR;D-8}K;iMj{`tXb-Ry7)WT
zLUtc3LY#vwVk_7>yiI0{St0uY-tI(mUCGwt?JhLiRje3qPPUY-W*hL9&6eRRof5p|
zu;pwm+laSZb`RsEGNP&9%UtY!y!G}sed2Uhfif|cHz|(*@HQiB2CJsGF*C=^q&WP|
z8b6Dbi?6dM%%%t{V{>ks!(hH(Ww*?|WiG|xZ(hbc<`G}>GxI6J%GmsI^Vufxw!pqX
ziz^sgpuN#gkH32sZ^2PF@mIqhVLn!m_lH?6t7DH+Y)tY<NB)|F0^s|{_Z;}11K)Gt
zdk%chf$ur+JqNz$!1o;Zo&(==;Cl{y&w>BPIG{Wvhi!w~#WuJTJRlnZ^<)cnh5D-&
z17vE4%{uZVQkR=Z+tjeR#a9?<JW1wt*m%WO(m4Ek5Z=Ll*G2vb4O}|M6X=KlHka@e
zmPq2@wKx{<x@a`Y)o{uQ<DbzIu*)w2Avtd25#-xhq{D8cy1RD*+ql@FmEl!@GNNs2
z*pJXYx6$MpNf$1_(f~hje!7*mm{kizEpF87K#LuF6oigtJO}_`nk06)jqv3PLyi{8
zGk6FaV6aTWzNgPk_DRAT7#p(vL$*m|a)YDQIA(!N$l6gVz;-6~_;ApNSAkX_`_{OX
z)9K>o4sp<9H1ZZF&S6&-pvwrl5WUbg8unTSLL#W#g`MHku=|D`-RDMR0Pj0QfRt-)
zI*oe*V802^1zaMBbUb0U%}NFyHD9`a@ZFf%Kzs49?6{)`Gms@6<7qwxe}`Yl{1s6R
z;bfCXK$nDb<YZ6snmx2Dt=U>MHNxax94HO=`##$LFfW>oMNH+lgM+P2^~h04MlHIN
z`cIIB1KNR~nAX1FRkg}%KgY4`X%VU`3JI10d?1dfe}M+@RX!TQJRS|(w4DW!XKG<P
z-Eo#@T=t%dcf()<I2y3YP7JN3I~wLjdM}T6M|dyWJaE0SvjDbvO=p1`R^B@c4D^P|
z+*x3xH!vGMW9SVAZ95Ah@CL&Sq@gI(u$BP3+FAlMKrI0_xkUmzqiPRge;?(DRLfC0
z7&a4Tz8mIs-EebK1?Rxxehb>8?+oK+(RKwK+dN3A{-mc+!Ui;%Q^I*<I=Q7@B2~bN
zquW(BlAIU)l)*D{&2t9jFe7)?7vZ0}LUKgGv9-bRyj=5BgW@v;stR4VK802W1Bdr~
zvv6#$AelORT?#D)sy-*cB-AN|m8l>X_Fb@YX+>MdF$;J<hHqdez6pb&rwLsHj&=o7
zh(laT988Di?b7;hqM^}C{^Q}UBBgPM_LkaMEqu!FL+n7+Q9d|=6EV5T$^nVDC#b32
zW69fp<A}EVpRdO?KjejeAN``Ez}V{z0}PJtSKaG3?xe4j6XaD2Vv!Sh1jZY3!rQ<Q
z4qSkPvy&<Y<XXt1_bGpX@eIzN@%EqnS}XT5snHiKZLRi}()ft>mfZM)_BIfuPE!V<
z)XUYh?u_dzH9Uz^R$6h9l|}-x!do&(KvsGZYT=>ilWoL`+GEO(nZ`j}nsXo*YwK_T
zRPzhaa`;~bE!WM(?ZF~ci8tb6O`r&rmnw}{z%tN^djPCGD#v#WTwT$2zj~q%eoRzH
z#c-|wV_$xs68VhktyuU~L@WFA$7XhwNp5OZ@KgfZ&*H;)D<aEbA;ZnQ{jMZ>htY}f
z8Kj(j1+e-*UbLzM$P6C`rH;653L@e?!L6vSH#|4;JhWo6T7{Et3wBNdey(5WB7Y_@
z<!gp)s7J?#X(Ru02S9Mf&0^aEe-4Mb{SP8Byn^8v4k)3$6)y?xulU}p0Q{2YRdsy3
zNxs+|g=1G$&1U~=a2?wuKzn2b_H08*APFi)itnjF^+Jc{D||S^)*_E!Vg$a!WZOzc
zG%(B}3#u^tyQ8UsNh5ZF=-88bqW1?!!&3B<wlGV4?Y@@QZRp~6f&zH4!7zA6IBz)T
zfTTr%VY%`-gzf8AQOyS}Ji7gCLv!PBByl21=)Rb$CNI2tRDEHBJHb8l30eVJP1fZ&
z;g-RszTQcWV#L)hp9#7(>0zhy*g1ES&6K!O%a3ye<d&D`x^BnKU}azTf^pP$!`S2>
zqme}e1n#ToMA6RHf`121VYl6ArH6-39bd%_Hn3j*47H$qk=&E9ba4RGm=9S+JZ=N1
z#@$PGxe4+k&oci&+(}g(0}1?@kj3jr4%cinD97P~(JegLuQK>=3rXY9ne1IRkVb{h
z1O|Oeg7qm8Ay|W=D-VYGMG8wrJ6m8bjQ?`eBa|57@<>Ak_bycjMMMbIH-ySAIU>>M
zV9hz!Rp*_8Q!1p}(O3qi^Su}10b>y~IgIMTaszxz>R{Rlrk!!$Da{4aZj>I<W<x(b
zNn`sML$Ar^UxicK2}U?YLh+2s`Y;-VvI$*GJvT_+#UPT!WhJ#KM3g|?ZNQ6$Ix&E{
zTA+r&jTd($;Uz&~YH=lZwtC&pRp!qT7!*?QGz`bEQA!%n6e?PHdiY_cd%S4ic?s<o
zt+5Ry@JEZ+FQ_mYh6WV_9S$doOv=w88-&jlZE%E^6dV~<t9@apuTk_KkAB^ANA)|K
z??8v#Ccf0@svSoCwQ5YD-UB%&BWE%*e$(4<09_KzgP24pxKFrPQw43v8$8Y~;T)O1
zSwo(_wigxm$@^g~I$1T7j3E0<lUy~+fP<vT%54TZ&s04bKe&Ewq(SjR|EVt(CaPO|
z*Wqwx)k{{YaL6b$-^9i^ane+~@`tzApf($0)Hph$qPd~sZ=V7Yfg=GBlO%9Mj@bN>
zst+{zTF+^1n&-5Wr~_4fO!_~X`j`pQzd+yIsd~P+)(_ks+EAw{!FTcohraP(WMd=L
zQB}3OMQaGPZve-YGmb|0m|n{FrdGZdUbOBI_)h)~p|dvbI*X1MN!LQvi{ecP77t?^
zctNMDwep=q`BcwCIM5-cB}q7tL1>~#g~P2}&pJKRC~wSjw6t)!B_Ib1NE~a%Jw<~<
z_Y}c>km_{nE9z1A`2!BOUTDN=Xq*f_>(4{w^zBs(XUw87Sdcw)6Y7fZ{ttRqU2%Gn
z;6y~ViWU7OaP%O|kTvL}4^0T?rQRezPB6j6#a=X<B2#4}-~AT|7kGpFji^e`BwTCM
zzC#P#f*OO{WB7DeEp+K5k+D$#R?2+x6_iB&v1+J}u{AhU?mwC$2Fk@dPzwWODAPEz
z2E$}=QYy%NI>`XuV=ns~Tnx06<N$t{GGBrVc^p87D-WXuFiAKS>o;6@OwOQV0RwSV
z7he3%X?5L>Z0Qixe#XMge0b4|RmghXdt{nB920?G!#Ecvn!A695|a+;V4kFKBT6#j
zRGx_w^K%sj3U=H5yPdH1h3K5@{PkAjZs)IsF|X>j+;?2rcnl_*4<n!PF!Xqf1ibgi
zyvs*Z)XPfg`ll$0RL1=V#p6X!cLDUhzwTz|VA%S~Yt(h?hg5$|H-OTN8D`$~)1Y_M
zFE-0|__DI_S^iJ?x$ekw@504B%Kbm`7bcmkXk=o_^N3viqM>4xqd>0y5rd28d2;m`
zlVgFq$bmCQADR4<9aVHyjN@Us<}H)*isXR%+Lw%QAzh1ToHuDI#W4NIA5F?WlVhJ;
z{kl=!@mr&#U9Nf3q`YQ?s*;A;R8pA*w*aNnT&m9Gw|(}wl570zaT-F~9v8=Xm2D=3
z-$n(~Bqb-!uec86#2c9(9rPG)fA(jvT3(5>x;beW>!Zmr;*ApB9avu$kNYqU@U)Mq
z7TQ?-%w%$WmK-`7xoa0#NoeI7nS9BrPE&ojzpeHO@u~R>oCAO9B99g>v$?PF2_$G}
zM%|?0c-5z3UgieI=nFI+Jn>8M73aq8j-$hYyuNmrP$Y3ThY0%`DU7Qw<eJ|a|4^@9
zeTKWej?=8_khAune{D!bsf(o|cuzr?ZZ*<?jT6<iB911FA-|&hNiCDRyTz#)U%JQy
z2YjX*gOh{(V&;ZkrQIK<+=Attob-o<a}8J5%rrOxr}dqoVB1Wvi;k?-Kal+BUwdU%
z9eALftMP$ym06G?ZW|8Df3C3%YAZ1%#Ik$9DDVsn#liZ{>tmS5)*HJp|FIAmRmvg*
zX}NS_awv0uqs%dU_BiQHNm?^Pp72popF_7k9>kK1iH^wabY$?1FX4ZZ```!SnZr0V
zatbvnXcwNz=!73U5m&u+tM}-SsJvUn>Gru6)W)l1gUJ6()`;SZm7XQGN8d&chwz=Q
z6#2qL_~mE51!goP%BY=hKSU|LM+CyTI6B9D(?%21N66AbGaVU#ojIK&I4IFMf}ee3
zC2RAB<GWL_R+w=yqx-_Yg&i|^@teRg1G16_(Qt^Kgz@cFtYx)+tNiIIB<+)D-bGO-
zqcNE_MWgGav8&2xiI0IfA&yJ6<4&8LG-WXEViJy~cK;nZ7^32p?GTerq@w1gEm7te
zl=BeI=yfZ<L9g>eBNTnu?7*z|2=mX;WhZUw52UHgL3uGrJt~ls42SyRd8Yyf3pQ#u
z%}K*Ax+${vi6J^2F61$KZ+{>;KYLDrXC0}1WjI-R@}c{%^7lY$(x%0a;-VY*CENts
zfcjm35srCUOdo<`apnVSh~oAh0?CQzvv5Au)6c~rKu{!x3$b{24k{g7A^h}`io)O!
zU8sA|tyyp=fbqo|wrUhQ(}bGENuIxvXKiq%xx)<B!@DHu1!@GGh6ZmK&~ubntIis5
zgOr)3%5TK`BgL<khUPezca1IXDm7(tiHr!oyHJeMBWSrp91W6dq9mNCBbD7#h|!bp
zMf*Y};a=0oju6l*Y|k#4237iy_iXS(?Z06bV&r?)P$KQ~DDin8zw{1ozA}{GK<-Yl
zes{?K04Z+d`F9T)cnMTbT_RMklMhKK6gT)6g3~W1-w_7k6%cgQmgjap9dmkkDcJHp
z68Nor&o?9xwQOJb-+@w9Cb()%cWA)oEja$62=Zl>d@$F73l@f{ODvGH7MmOA!^DI$
z<fxbK6;%DN{sWa`-Tud@1TQ;t#L-l`oCyk2#zm+cxCMzP;W%tS<v7j<p6{V@(4}Ll
z+Hs$f2z87XS!wn4%FzptVI}r9dOv&g=s>(*J%{&Cjs{0rZBbEjKU5~uVq%+EOk6H0
zx8u?+x;)e<KQbqH6d8>dEv0@uqYFkSOUgK@aRB+M1XC7EjVAw~+U6!Dg70RLD8suQ
z^a=jy#aE#>SG5i$6`CR<=qfQ>x3hC`q_Pls(bcHP>lE}!C+ZZU3r@$7mnD&gsc)Ea
zfL18bz_BWU<+`elLQgEF-8jJV22h{#-xNp(Nmf6#IO_l$oB9sS3*MZ%PozBPrCc#{
z)iSIo3nbIB8=pv|{et<Iik0Pq$V`HhZr^z-Zkm6HdJ5HfE&gK|Ie~muI%)YT=PH6e
z9W=gKSj{2NQZX^}uLtQ{(O9nFwE00V7MMYb{9-#6lf0j_%GJN=QeNnyZV6Wg#oz~^
z=i`Lxm&)ZHv5O;AFUHDTY$*UHz}ESZqQqj^EhH`g0%xN@It6NO`-mT-p+iws|F&-b
zx9xxa`Sz__yH9lQ|Dt<qaaUK@mPs%Vp0q{$PTDewBDTb<5nEvP?Qme#s=ND({ebU=
ze9g(>4%WT@=YRh5&-ZuBQSw7ajvT3UaLyg6TT|~EcbDB>daiZb>TRo6yV{z5zRdB(
z7mj5=_qKL)b+me!A@0tuJL3$%x-~U*t0NW3IER7iwi72F96We1yL0uV;^Ik1Dyg(v
zw{8`10P7a;sW3anAHpb>rOSdJW-sh2v=ekwQxjBOX5-!5hF>HQmiyh^0-PY|&t6$+
zhcPcJE+&RE{C45LVrJjcRB7n|qLw46cHY7!6;Imq;gL<Ou&_zMrP>P%3+<^4|5EXe
zmhb3xaD1}cuL7a^XQvNX;SBuYL!<@JO<uO8<;{~9+qN)!sU3e;S>+MSq{1WWuLb0$
zIf{>TS%$EyO&t~rPbzHc09)DBBR~K=l?YH6k1dweQpz{{Um@i}<rCSX1bC;MDW6oL
zcT3C3lP8-hLI05>SC1TFS2^Fp`BhXW_=fuIC`LULcd)KiMU_RXy42sobK?7({7!~C
zMzSLe+{0fb8)88*QJywlTv^Q9*g3Fg74Kp#XS=%IYiVIEZ5L0ziQh@ZEiEm@lSF=n
zz=!OQd<f4Ols~1bJkna4Ms)sB#f#7QyGr>1y`3TTdtGON4@iKE;!%W3*46T8Y9{il
zM81WEm5hkDL>gEnHIURwv}XW^{<`ggHxyB6*@Aj)Ei4567`ah`Cgh)HK{Vnid=-3}
zR9py>&LO;sINs4(SiFg&ymnS9=(jMH0gzH)K%0oAaxr#<7=YgnqCnsyJ~8$oC?<pg
z-w=d1ae-enJQi=?Vz-Z{`lDo24*Y<AG|2b5x~Q#!0fHpNqdchRC+uskvNXHB)oxFt
zej)x*08wlckw$;Sh?Xu4773qWP&j%(Ju;{su;k*@Bm~85auWd^BA$*3-h*R`;*jH8
z7}JXG#Q?7yqTxS$Ci~gr7R;Db1rpExIHwp?Bl+o5U354xbZ$|cX7wEm3L#Ojk*h~p
zGwt?F>l~bVD_gmKZNWzFwib-d9&24vw$ANdTVh?c**a_OrgbIO*()pD8%wMstnQ+<
z)|`#2i^{F;wJSG_#R|fH=q7<JNgQYFZbNauXyJRE$fN-)th?w1bG3AyN5QAmAiNl8
z>*2%S!uPWwc>W|Yn>+dB=WzUFQ;NV*Dx#2DykLtoh@Oj`G2Z?!{{ksXH$A7R^Kfl(
cx!tA~&&v0oUf#;i*>AfwbKI?2Sr8KcACHdS^8f$<

literal 131072
zcmeFaeS8!}wm050)00fXgr2~lL4yoBXpk2ZjJpX0on(>_5O5&8ih_}3oDfK2GDARd
zP3#2I8RxFMi+lIQ^@{B7^}61>S#~dZK{1oSOu)AY>LREFaB)KO5=9}r&hLAwCoiDx
zKA+F;dH!oYq`SK6RMn|dr%s(Zb*hHr)PE`kR0^mRP${5NK&6060hIzO1yl;C6i_Lk
zQb47EN&%GuDg{&us1#5spi)4kfJy<C0xAVm3aAuNDWFn7rGQESl>#aSR0^mRP${5N
zK&6060hIzO1yl;C6i_LkQb47EN&%GuDg{&us1#5spi)4kfJy<C0xAVm3aAuNDWFn7
zrGQESl>#aSR0^mRP${5NK&6060hIzO1yl;C6i_LkQb47EN&%GuDg{&us1#5spi)4k
zfJy<C0xAVm3aAuNDWFn7rGQESl>#aSR0^mRP${5NK&6060hIzO1yl;C6i_LkQb47E
zN&%GuDg{&us1#5spi)4kfJy<C0xAVm3aAuNDWFn7rGQESl>#aSR0^mRP${5NK&606
z0hIzO1yl;C6i_LkQb47EN&%GuDg{&us1#5spi)4kfJy<C0xAVm3aAuNDWFn7rGQES
zl>#aSR0^mRP${5NK&6060hIzO1yl;C6i_LkQb47EN&%GuDg{&us1#5spi)4kfJy<C
z0xAVm3aAuNDWFn7rGQESl>#aSR0^mRP${5NK&6060hIzO1yl;C6i_LkQb47EN&%Gu
zDg{&us1#5spi)4kfJ%Y?yA*KlxO`Q|J=UPhD0CZ~JNob;M>%(JVIAje=D1kyF{h+!
z<XZpAofcke-Nv2F==H?5@{Om&?yF~HW5!n=1N-XKoDp7Iv}AF<cTD+ufoq{h-65g&
zO`z+&J3ZjdHwkrr#D^5`EirnZ<Wu%}jW4{qOyH(x8Y=kdnhHafcv0^;A&;or;~rjj
z&K;YcY4GT!4F-Ai7Aj31onFo(Vm&V#(#wsWXlcDMWuF}5wVCSLJjdj-US270DV3Kn
zP~PymHk7rL%5n`UYbllGqOz7!SuSHrn|womS#iGmP163J>EUo#><lkovGU;#sjF4X
zbKL2U#rfh%qZE+30@>DKoNtabc1JAQm9p>rS+PC2J|4*M(%bT|S@KC?XP49)zQNw0
zt8MdqE$%WdU(q4?eObxk#h7(EU)B-==nTiBOcc1kZjWbT&Bbt-<Eo;huD@vHSgFe&
zGPUSY{0zi$>!L)z)*mv6eJ1gfurD(#_C-}ihplzb&lNc7p#Mao)EoLOkfv~gcvQgW
zbCFN8^7&Nc)1-WsMm~+o=gP>ZLHTq<K6&Lc6QANSK{_b)E??1eH@>LD#gjace_t|N
zy=H5Jwzf^EP1bN6nwBwMs2h!-cak+HWlzJyoX_5s5mOac@<FVyv%@z>+m$2tR9{--
z;d78!eW~32<kJ(XFRc=4{~e8edSvyb@$QuBOH+ip_we2GZ+KK+DirG45Rh-HzT|Pw
zsJ^t`{c!cAN}=vg1oBfnTF2u-WS5`zj;%YiVOZ<rNW}R=Vvr~7LupsTVfhi?O5S@T
zzV4*2+gg(&V6E#TfffS-{XokABpsF~;#=5>TqwU+nq;khN>k~X?j0)|uIua|pMzxC
z;vLI+UyrKg)BP~AJb-1GxAt_P?4^v$z)lA5LMz|ghLI8a9pXW!NYon?)qtpr-^f?k
zP}^uVH$-PV<j%>s%bh88&)~|zBWcp^ntyP;;c(5BUC7~1+PM+U*g?!I^-2d%vsOtb
znptt;6|{<C8!e|%QG#?)iN6iiFog1@js>pQ!Cs*T^!Ku*b%#80t|t0^0^bkHb60ah
zlU?f&nsknEr8!)g5Uw<ZD-&IB5zJ!Zm|Ye?SOH<T(BoEz&we{#jp0f@TxoD!B*4iE
z;PMVIl;n2?ZMSm0PRU{EZ&a-7o_PT41zJ*PXyg%&19lzYy*c&!*|@AfaJu?ZtY@lk
zq4j=Ww)J*2W_&=)%}(Fz>2n6Nt+P2T#;bie9$9g%Gx`Ley)X1{s1`ZK13Eku+RC8E
z46lF4n%EC4b%$0mEaxomQ20Jc>VA_*tkB(bE!{n-RPF7YmR?q_w|O?|bV}LQTd!+V
zBH9FuwW0iO43)W@6mq?CcsRF6dW82D@DF#0yOR2QqLpg%YSRz6d8u7K=haDC=|E@`
zL`J^LLG(F}?p*pHqoR1yEp_-dTIV&N3{zu!QAZ`(Iyb;^dFfpWRVr9JOEl8gQeUVB
zh@8u|R@gif2oCT`pvxUY=`x4YN?(VT0#MkVZOxHq*B$za9l&=`0|2ZU3XHac+G95n
z0dC?rdfnjYXkC3#q5TMyBFa;H3W=zlU=ufWX+)rONFS%SR~V$=+22b+c`QVo&#dz$
zMoI6doRbX={N45Z)Oioog+1R$f1mKa)VGZCD!q~j8XF{xA<1anvIY|ezKvqYEOz%!
z*Sqjt5j7n#>v#x!{Z<ALgv?Iyj(UWE7g~){S3mee1kR^-MSvLqfQ8z*5NkCXt%g(p
z2z75@fO*GcAnaXZO+Npbv<4&T;6$@^+zD@78luzpRv6L`3Y&fbK%wcL;TVhl<Gipv
zO4{xJM=Zcins3wJ#k}#E93!1T#@iNJ6Kalfm%;7}t>)r37TT}rsJRpl8@P4zgeLt+
zDx^C$J>ao<=U7eX!ULh5plSYM*DB(Lg8-Ed_(QSItqfG=ozfVpS(?l+&9+*$5^k85
zAaM-d*(7+9&mWXJC-T;D?P!T%`XU~!-;37oljFQZR)?W(pC?&9(?8d)r@1z5V6IKa
zTzgMl*qxHT-r$*p@{GtK-zMECJ;0+tUMe%77^5`P$fk5@rb(K?=5}q$K2UvEB5`^<
z&-KqMyjA+h#hEy+g&yMGaC0Fr4vj=Jr4H1!)K^UjlAV{jcMc9kgA}MaP9o47CF!JF
z@?B36LH1yrfJz}y%itP$jE2~wymu8J{=hp7BMs#HHR%0t$BLD*UJ8ZH*5z#6kw9wT
zGPLfARk2q)g*uEMPL9vexu4A7g*xa+T+gf2|Czklmg#W)997AA4fA>LvTX0;dBXNg
zgTt2@=RotiHIA+m!uEX&T)!oJOoYz?>1*Nju3`QY!^B-?@gi4s!wjYX2o6^Z0m&C=
zM9V7y6ze|`>u?3B{1BC&Y1r{8KB_kuIgftFM+oK%+uN?Itli;~shq7SN8FVl-$1yy
z_y<tPR#!A$A&F{$VnUKPD81*)f>sf|&b+`SQ0iu+rtHCV--b56{LX%``}PAVd&Eo8
z!n6O4DBCL(S8`~M&%5RWfoq<FxV!+b;V`7m*X<E%>k%Ps;HBPrkpP^*Of9FapKlCi
zW@F%ogPD2s^70><-ofb0Ohd?wkW<RcXc+S@%C5d7ROJfWJEXleC#VGfMQ!oEoA;I^
z)j$6}l6`i~D+G46(-ZF$<4j<1O+f!syrN|x5|ODyR7stKVuG*Fw(6vhgr<$w1R+I&
zz>)gSkALTLfzx!vf9%^3EnPfW?{5ImxK8OrT9-#JZ1>9(gp>&fMt_Zt+IZvBda;jN
zXL8*}bXwELq}ao9bm%ZhCi_=LSh-(ALLGi-f3cowcplQ@EnAjAO5^#IeHwrKep!3=
zd6eBb`XH5kRw?_W(Da^*dy16H=4#L}L>kzGL)svH++br3=?bCiy@|VDMd?D*C6-CL
z(4Q?9*&wy*iBB6A>#GZ`I!*OPJVv)cD*9ZF;?W0UKJw*9p~X_@bjrKpKTPgnm=f+|
z8P``f%!@kb=iRsZ@--=KryFvkefe6v48D9FUNOFW9<NwmzW#JW6kzb7Q6RJmgie9r
z3Bs2jUEg^cg&)Nzu4`L=!>by1bTdX?SRN*JL$_sET_TD8@PJ6~U~-u>A)C=_<CW%`
zS#zC8GC95c?$^+EnqWr=O(iC;-GHFEMT;hr<ofmb3;5<S2PGhe^DPQXW~;c-YUJD_
zAP{)3+iHfqGTrVxTP6!E2HF+HIM1$i;yprak3xSy(q7Xef5wbk*R~<bIibWP=gtLS
zLb}=Nwq^mVgz*xp68j9ESVBPqeB|c{uo)viEGLZrFG?mHJUX%aFyxuO8N7pW%H-fc
z<AJvX?b>EU3qSy+^+Q`c9L4kAWbb+&^YG1>k4^oPeEr+?bF4Q4E8e@><gB?8=Bh>s
zO}oK!z3~@G+(bj%goSm}rH~T~3yg^bsDl?FZ4$78z~^YG56_#Fw424Zd8kA;N?+9+
zK{hVsko2B(7?XTFv=)GkkiM>8XdNlMe%0VVW5AF{i~Bz)WmNx1uh=b!oi?Q3;PgIZ
z9WHi6HO4{<1?urcs!$@xD)}KpMmSqItrx9F3qz+_Y@-2?Qs=c)N+8-uAJ@MPz)8df
zQE0TmyTC}4Tfj59>&^Ix#)s2u{D^o3cn_yX96bcCVWBk&ID(ZBaQaUe@DY!c5tKag
zWnXdBUt;Sa3JA$KFK-R4r`efsT+k&8+uxQh67NVSz$EWq!y?boL=3p~cY@Q0`Icx-
zwt(})^35%1PWV-W8w@+g8ifThwLG@JjVD+e6NZWrBQ!cJI;AgtZs@C|$Mt&p0=zW|
zt81w%(t**y+W^(D9r^>uL3j(V?@jRcBp_O=M55y;(&X<kAyR?F@{&aw{5{lg5-NHZ
zhXqiJ5v52MF+2VOSVLJL@q?)X0yAX~Xf^Lg{WaeoSHJN7;hEwEv**iz{T{CQ4&;;#
zfoxqIm*<YI-l&VSxW5vbqWqy~%!T!KO^W~sp=tZec-8NfdiVFes_{h4o>jZY(<^Lm
zm+S`2ON;YU4*ANXrLRxcwr!Xd(@}jX?1^`!kkCE<bvWEi3uE~XA!VZ80^Q)|QC8Av
zhRWxe1o{p@X(=zqhVJ_Y#BYSWMB)94Mu+rwsa@=j#w>CRW<a5-&EIW^L({8U`|v!o
z?J8<tuM<0>y+3~QGGfxtZq$o!hh>;Y9<pkMrnmh^3{qztaEauQPB>5HImNy!>*CIJ
zM0@mNhe6(JmxBPhrdYB2={(51s#|LIKr&Tt>ytXqY`c7FJcoAaIZPDky+6@P(b9nx
zOdwu6od|!vhvt*FLOS$O@4uQ&XiB24^DFb6@aH(n3|a7Y{Kv9BbjMjpf`RF+SDAu(
zB1Eb=`Fn`c$uxfaeOin!v#-|rQ$+bTTkUxD3movU8L5d7v=(qTt*-14g?!JxDDV;h
zNg5}TG~Q1$79SDeSZg>*ukHdAh>sEyLOM1-2=$v02dQ&M^(D>dbK>z{@wCIc(V8R%
zqexVpzJ6kTGcvJ$`_Cp;AdwJy1w)Od#k)}fE9zu@2PA(Ij4X|dq`jw=T6B%Cp%!T`
z&5ckApb%7FSR~Y4g;gfwHKFbt-coN`hfsGCA;^wIX|pvC4aEd|2j?cW*<wp?7ixRZ
z_6Dpc>klZiSBBE`$iyYKMUm9HvvD}dpF2-CqcAQs93*Irjl>Y~LNgE}G@Vf<_@4d=
ze!_V+m2Rj$rg6_xdbgSMhCzh})M{*`c7#H!72r8&O-7@8{9u=Vu5|g|T@TZU`OO(9
z!}9IEB~gtppRRtxnvMFko*N=Hx7vVBGd)7Dp97Kx1xe~$G{fSn9pDNqws_AuL~KO?
zz89^}(`z&1oj_zMibN`1s<pm|mor#veHm{JhX6ri5KwS4g7gm}FdLx1!e`4Cd}HZw
zAk+o@3w>GlXGBEQ)GqNNl+>3H5m8dVp5uFIsFJEvl+;7+r@XbS%dn0Bzh<Mjn<29U
zn+RCv41&K6LA#=^+L^k_R=;BRSg}tpY;LQ!8_DXm2ZOL7?mbdjF9^c3t@wn>SR*r~
z^^&%DzoN9BA*D4_^9lj>yZ|8dcaqp14FMz6zKU-~Venz%5E|!wtFUT4(wjN7obZI6
ztz}L4e?;7q{lu+g93#}lqV{WudjXh4h<k93Z^uyLMk~Y(3$-5tsGq<y6$1B#TA}C!
z*opuKl9^Z%IKA1{T&FbCMuFJ~+>5sZ@2qpRRvDP^ZWBr|f*HJ<v0jGIkHI%By}<x8
zv!x|@)eHfxXI#Sre0^tINGrCbi=EZS%fEOWvPL|j`{2m_KCxRTPjz}%-s@e0svgL4
z)?DQHs^L!YlBvp&(&iK|+_w%BatF*q!k^n`Xh3Y?#Wq|0%pWx@;W0B#a(b8COFAbj
z0B@ACB#R=lyeqT459DQNh1&hVDnlpKig?qS@i5-v1+L0abBW_GaqC9!<gh?_^FBoH
zp!ut{3L~!P075MkCmnz&|4Q;>@y?Q+Gpf0&+jdkV2{VeVDq)9B30kV+c3704sY?4-
zlhAZl>O|giQh*i7YLKg(P%`g@{e2}7FB=%o2%lM}Zw_OGvzd-(6EUkZu!H90o_hi5
z{NVHl$3T~-*Nt*w@t!5$MY`I((3EYhPXb?O%~eqD6D4gdOJiXMP}2{vPS4s3r4z=#
z4*Ufi3xuX@>jDJ(pGzIUDvzy?*I4J!;F{xbZ6YBwN)Cse(#kZaR5i^hm1THGrEMUS
zMH0q#)$)>dqp$u$%=f-5%~nc)-CZl~_vL?6bCIGeZgPrGexvn_^j7c<(P>c?v7RH|
zTz>jYzVegwx824GpZM%X>0s#DQ>Z1V({j?2e9&%qgK!6LT?HkW6!)0N7aWESKGTLF
zy}1p{1YJHcj6dLQwn4%r3cj(l>>D{qqBl`W&jE<*nq4$?4xPO}_8&)AwZ#O2yp^Pz
zbTp+c^f(5Y<bR9Q4cRI*`AGpG1f+{+T1n$LmEP+f3Be&94dpV>x;+~Xh<jiU9as_8
zoO}ox8>XnJ3<#h<fyIDoLp4d942Z(tC=n%Xb6~36O@mda-9&M0`P*DSa_EGC2^?iH
zQ9Tm@$!r~*DB_igBG$Ew+L(_P_-d{BfFglDows_<<9jT=eQ#Ke^xAA47D*+`qx8Bp
z0iPu26Y<ti?u7_IsGA84!Wggd$VKnf21Nz!3ypx{26cO}u>CpfQl$8gBnaDUt;;Cb
zZHn>J$8vlqp$A#CA;#bEA}hUNvvm=ogzbN`E~a-=jyByd)P93D_H<K2|Nl1OM=15$
zCg{+VIfxz6-;@#kO_>Q@i>9kr!5<B^)+_)4KRaF-(_mmfNW4Ef1jCH{6S6XqY4++~
zp>6}-7|RCO97_>&T_L#6FG+8cppZ8wd#>w35|`Z4o=gDGca3+@v<_%kxbA>yup8vt
z=RazS>5{$@wtwJ1YKXypQ;frvNq~<7P&Td(yOz+`bNE`e95lKcIQpKmTIjWzb#nhK
zj&7ZVSoA6-#-m~c6(&+TI~mdF>}(hSYpqH6fGOV!LeNZ!*+Qt(W1O^tA!*bZ(Z+9y
zv*uXink#`qL;N(8JGPbdqMlEYP`gj4J%V?pP5z=4g|SQ;><%HWHAeZ4Lm`d$MtOHa
zXM0%*PK4U_0znN^peEG|bq)B2v1c*{PxPRLwtiCz;(c`-_f=ThbSuJ6@BOzru~DaQ
zX^X~}^ly_WGPvnZyojl?ty7)SrYZRHF0`gfzq}nGD1=0jA=D7tbkL%mAOq1vX!^u|
zjF(<yGy#bTI5Z3kmR1aVMi`oj(S~TwGXh9Pi6Kk<rl}~orvnMCBqqce+=r0dLajdn
zs;gQOU@(|6m{ly33edVo(@W>Ri(VSf(?C591;HE`6A6x>=KKh84hp0qpylKxkwhye
zA5n^}zN+`2s~Uc>3lI(7-Sqrz2cBf;ybm;B#cto@KdN<NC93nyiPwN!RIsr9kliW0
zL`4TS(O#hj_GM!$0-UUGrOi~St7aF8GA1;A4_V1Vo&Q}j_S5PxOuen>4x&|UFSL4j
zCl-xg6uzqUkd=R2^HijT{Gh14=8_4^QqM8h&xotHf5BFT*fAMg2%4=@&>uF4UkXyd
zf7K`+7ear=LPpvR(eq&af#ZcKhvX5V7ZHVs`@Pun<Zn9uh#d>U6WE(bW%X)2w<&eb
z9a86)uK%Grvy?iQ%fc6rAU8HLa?`JF?36-7EnWs`xAb>qP)nVITKpG<!uHN{evNz9
z7mw7pOP&6Z9<ye8$a4p_LSUe5mseC@yy#w7eetTtJm0mK>f3h=i)5P09$Y5d<^#sz
zIz#cTh!=Mm2c`OeL38AMB>$F@JFx;VhKBzG6s>K(h%#0%vu6J;4Yqyj_rq*;6Z9e-
zG*Vsjhp@(n8X;|@c2H-MEQBiiKgNP~k4P6-H)GS)Of+pzX{*~OywrC7z_@m)i|p-@
zjxfO#{jp@UVgtO-0Amr>6uk72|B6xkhk(5gwt>>kH#|QMOoRP~==v_P(<JNZWx)_0
zUR`J%ei>K^z-oB&BZSpWga|ebgt|}A5J*%A8_%*9S~|Cq4hD<lc*2Q+yn=|9mocEA
zTlR%q{aNc95bx!!^$9J72(iTbSp(1S^Isf`T@$1^G~kdz2^Ng5mQJPMcL)X(YRWlK
zD^a!sOxSKt?oa;jNco;Ax#_1j9t9iS-0}@t#>$t;AOxh=$5Y{n$+^?rR(|7QsA2{*
zPEZ;*gDqv<TFe3m#9byfZfIv-;YN3&!i{f1;rrqdJ5*gy$Tb1I-19Z?!}!ul2b*6*
zg`sa@(;^aeBOa1Qo3Y3}3_1j+1VGDc0rn>XdoKdk5&^4ii-467ST2^O|AUm!e@4K5
zj*pamjjx7&8HuPtg!D-(bwOwt8V_E1oK^Q4jA2yWuZaZ{U}VJJ$C8vit>01!ZK1=g
znVuY2<g~QksBP_~uI*H!rwnpNpqe<N06A%XN6tSeAj4b%DtTu&N?zJO>dmbqAIGw4
zQ#Fcu5Q|yH0`*6bvGvCz`V%rK0aiSrp88a1lKuZM)V#YCa+z6(q!3wcqz*FaYK6Mr
zGnhRR%*FmftI1G<KsjK&*;doGKA4jlXP<87s$;oUu3CrPEeq%Yjz9Z{mdOW)b2U92
zo;&Fw{T(}?A;kz)^EMT}?Xq;>Orz%bUsKwSZ~Nk}@GQBAl5|v3>@_9LWhGI0JLy3s
z2{EiB!h&#!JuU7sGhQL_H>9x(*>ZD($@M8w>-oc&`+J_FCdGIsCquCon)>`-8l<Z=
z<d{(nE--RC9z@Vr!`Wc5+FfN$e|O#e(t+`p5g8LuDAapKIw&61IcwT48yizj%M<(4
zdzI!5NsT{U<L9b5&R%nY<|fa7*1SJRX^`(qqv<rmo0-FsT)G87v*+`0nE7&qreGXz
z$-{c!K@7LWHS2lD!UY!3+?uon`PmjvjyKN)AESF~(($>_^CRhP-7?zY9PiEknU%(8
zO<HcI-Qh8NZS;8q`^@(Y_bxTc!?Jt;O7E!J52Iu@_PrNk&pTqps5|7g<h#s-$_k)D
zd#^n7Qh3b7bihb>C$z3aS288vhvep72puc}X!7obY`A^-b$$UnfKY`tG`$VeJ97ev
z2*(Wg+hA9im`iBNib7^6awBSvf?%|N4JROY4Ph9Sv|)L)`7oA6bF9hL%@o4g^b!V!
z^p(G7^bQ0#>G1w9r3=D#VpR)eOu&SK5^3``!M8C!EcGc{Cq~In&PPY|t4#y@uwD!!
zX}8a25j%M)hqf{%Ve@7@ioFaqtvXT4;jz8B{i6TNXwoou#{`LM`r;;Y-JFy|Tft^2
z$2bx5yYT0StQOrv*nN1&nu@ATXh)jQV`DgCDU!r-1`ak6V<zzA<szw<s?6>FZk4%T
zpjgXvl<DCSN(DrsX7nEM$a>LVjFOXLF6Q~WN5!<q?3EUW0Ffr;o~&^zHP``Q(R88x
zX<~p1;WxhEKc@FB9K!{*M6T=W<E1QKsR27__4*?Ksd*n_Bpefzo-hQnNP#1~lf4@Z
zQW+mn(@C}uPU_wVcueV@WrH*EOl5s#lin7O^#Y}2?`+;TU+X-Dj^B%?pH|UWBEpM?
z&tKx2NjxPV!e(l=H3O`VX+5Fmcc>$@@H5QZ|AA;L;n5=@Zndc;8R3CG3=*sE4pREp
zK-4Vd@xDBhl*f8UY>P$*MH+~H?F&x^w;H7!69{KQd;;gurnE_!yl;_3ns0!`)P#vC
z!IwQYEM*SKXyA~s4;d}NES~D}<s?g40|cTbf?UxgJ>VlC&BT5&v5|&$1NWT&pymi?
zK??MNv%>cM{-Y6gYWJTW-HbMYpZ9lz;b|4vJ`4)njX)yVYv+SD1E!e%1@3iZpJ{+0
zz@0ou_FELP-?+q8NfiC{K}OL@MA2nX*FsUBf|{NE)KsuldUOjJ(wQnjMidyHv4sqa
z`bX%K!Q%TZ>M+6X{}@}|=oN8S#(?-0PukGE`xiJ|4OIKhsJ$5~FekjxR&$!huK%jG
z_~Spl_S$P~M49}@5@KlYExQ_zoG5ay$>lWk%HyE9!-!^}#nS}e8f&({dvr{nbRzTy
z%$m^oXol}aH(<-l>dWfONE4ntf=}p%!W+H*<D+A)qR2EVH=UI`P4QyNP|CeGhRVH5
zIsq-N1O-xQuTXaEVx<g`4r@U!j3finYo9?n8TL|~h`AShW?<PTMY69#GI+-z24kw9
z*6W12S%|29Itt6V`&cL%p?eS-D%yTUM5%sK^Aq9On~+2((<2>vuw7%Lilz}6`mu%@
zu!mLJgxy!d`5(~y8nq$$IF{hZfc+>Y7MX&&|0tHm!W;W)j-v-OjI|6gff||h18lh+
zN<T1;3;2(Ymd?iP7ixcj5;0s2!uBlv06H<>g9)aMG+=WeG%<q9vi_V+Sz1lkgg$Y`
z!fsm5)!C5XTN2|lMyKzsjBd!%Wbhu7>vzN<7ygcwe9u?_WavF(gzc-fQV3gQBT+lH
zlXYUB&J*nvpWqGdXkoin(=NXm;io>rZ5)wm7!hcihOx^aov^z|*pWk#7e+0j746&%
z<cejv6lNIA70IzIlH*zAkUj_f!kor0V>;@<bfhQxO=d*w(-yZ~L&Pt^c2WqseoSC!
zFF#Mvm<<vJCNNqI_s>+&_2J|yY==669YSGyASMU_2c3`!IP%U49sdMu*n!w;U_@e%
z#dc9FWElA<lQn^u^h3NE3ox0&Bnmujg=gPDJi65+<@1=o#P^HY1QJZylX8lQ!3!hZ
zaOSm0TCAysYbU@gUJ7C4Wf^=~CMnC9DYjd%Kk7ErK%q5oavSBxHm6icE8GNcmceV1
zMnVzVtCdW!P4*;x7bReAMr$lX+o<htqYdx_Z9I7ZZ48z`s3XHb?8g+lo7(+16j28Q
z{p<8b`+twO^rXS}EUn4Or|SD;Fo@jl?`FjQSTb8<x`4Qu8IfW-C0)?YW<06Kx5VUo
zmaqZ3d@!q*<4nEM>~Ew6eQ2`Tm#qm)S(kM{O>8$!$Nr$_kU{|7YfHegC-HfBgIhf3
zr4n<{o?vE(B}$c`iAlZ@eEIVa(1^Z}mtLVzEnf0y=xU?3(y&1dhEO@;SU<|c*!Ls&
zPH7W&*@g(*Nm4KXm8hv)>pu>6g*fm{^$s$?N(axhkj+)v3qN<#&S*-id5=U9dCQ(*
zv+!>5UD|=fR|wx{NT>xfX;~Zg&cw`Pq>zgP30mku^tTZ|F2=A$i3vmal*Qkx#3!;@
z)opBMnV`II81H|j@gDOb7A-v^!Nqw*tH|ch*+x?ys!ojfT%8SSI2#auzyKt?<*8m5
z4{u-^i!PpGY`n4*{1$5~%w2G>1M$71X#SGA24*m7aWffW&KJUOg}25N5H-qxmT(9G
zAW3W^7aI$3v3Rv0K6Vl(^46OHO55)tWimbD+C#X{-H*-0o(ah9ooN8NNm8bT6$r(S
z6-X_T90|;`<UZ8<F_XO2G4GZ5qb8pO;dhXI2ea#0n&bn7LV2psxaY62Y{TQM<cCWN
zGEzdG4NtFwuX&gJ$RiDR@ZP0)L7M~OoPdJ1IdG0(N_xTv-J#>qWNVHwGr&VuD@OJ?
z`6i#)2WU>Wg!g9gaNU5m!h=J&+|227tk#X)IHNGX8S;+{y^7o^hf+?-KlY{mj`B#o
zI)(w+!k8c)<3AB29@T(l<Jm@~CstR*2XlE1dPcL`4o%a#v7_#kCyk-zh)|i@aFlf(
zuxFhIR!#`L@E+4162)DUh?#rp@Er+9RtPX31u$(j*|gY2Kqtppz_~4qv-h6a!8rTi
zDJdv^dD$sF#d}k&1H8Q#i!|pcnzEvtBD_){1f;!ZXzGqa!kHSQwGBmi!8d!)G;==%
z1rghfR=`ID0jT|4Xz5|#Hy4&S-+bOlW97^cdBu2r0a#fIT<h7%64EK*J0koxiX{<F
z<R2JFafn49#KZm*hqYHss|BgBB*eLTh~*A;L2Z*uW(W8iI5@4I4@MDHgSm#{r@O=3
zOo%tJc&VHZ(pckI+(-r14i83D)v1O5=)(rsR1o6-J&X1VVKw>&t@F({Hrh`6=3_l`
z#y39-JBMey5A)4_WFwN$0TNQxgT6|5MIq4PJddI2iGhd9@SZ;cif!W(acI*%M)~?0
zBxJVA#n8%8T*@9_rAg{U0cU*qBaldAGL%k<IZRDQ6++X2a~&G@t<AuUbDr_b2Jx5%
zryN3|KeAQ4$KYMWL&^d_$}@t{`r$kkL-U|Uc#{wM;aR{Iv@$bd5r(}|aYi=Q*qnPz
zs|o$ytf|H>+L>+f<RftlJ+LQ;P|7)>Db%wS$hE`+j2tPz#Pk?V4;@=C*smyFAN*Sc
zgLzcPdB&fVf&`IBk1@Xdi?qp_K#NsBcHB&!F|r9R3}LJXAu{=}=WE$U_V+|28r>s>
zrh~0imaI8>zX+G13-YayI|iYt-IuD_!BW7{C+jtt>0fz(B5;z2<)(it)GdPCrkTPr
zq~*zIxe-1>D8WnKFNu&>M*qbq*fW5X2_+lFBljWM4FA>MD$GIVkG{dH0WrdVckMrM
z&ToO!epkvqEU%e{Nm|wGU^3utd|Ige4+Q@yMW+xIumhWIodTWB3UZS50I2XiW0BYU
zW7b*%nn;gHC+pksnoJociXk11=!sYNx^EDgI{WD|OS}NO^n8k<0F^hP7b;_w$rYy2
z^WwWCuxTG#`qnp(R|pnO1k2%a;Hv&@q+mFeqhMkC4Vc7@U@P|s*!3cGSIWmRoV$E5
z1VlG1*1#frGboogp<VK)AAAZ*Ym~z^DIfJsLVe<0{PGpD11@yv6**4q;5DB~ldNx2
zanp@f&vELdiMnVhIslAs#HOzV%@!Vy=?5yJ0$Ca^98Fyu)_9{Q(6Tvux^|sb(qf<1
zig;@}I7O)2e^n8l)1%!}sCQD@Qud*9Xj}J%_Wj-aj{?*b!@o<N7-N2yI+6949C1-k
zCa!2VL|oLdQHwPIn+M5|Q%$Uqvgb{*g`t<Qd^5r`l3BrkPa-zj&|eX27gSxH?^lW}
zJ}Gv`i+%C#smv1i7A74IyXc0qe?Y%P;2ZCT*CU)EEwoPBNf2lMfFokUbr3l<RBbi*
z>dGUYT9~=wVH||U5WoW~1&GIQP_m`wJ+h~<&1Uj^I@5B6X*+O$VxNu4aDS>kX7a=X
z7Xg+?OqDI1jYFN{F6+R!z<_wyJL>n)9mI=ce-h`qpL+7qw`tolr=-_Bp}l0U+4qw5
zQ-QOUw3+o3z;63!Ojlt&<&t)?sQ*bq0@^|Dwh5#S=Ns{rDA}1EyWJR}H7$?-j)a8(
zTM9yw>XL-;LwH-zYf0Gmtu<jP0*n>$N#x@SxJgJ)R?uvw`ch8yoZ-ONFb;VQ-laT7
zZ5qr@8M-{f$fZoQ;mattnbQvo&+Y;w&ThO1e;$OUZ?t9z&(J}%s#uue(}YdWAdLDf
zkYcIR?IzDnsCW{PNuG!$-pzBY8K~Tf8j|Ey(pS=@iKy#l)P*dmu(3!>jXB7WoQ}a$
zF|8^V87F~F4eO>*c{oW0xMTpNPJs9s4M7ujD}RVf18@eUJlkLaE)sAn`8GmtUycS8
z_p$c&kd;0s{UhPI7!Y3G@6~zpc?mN(G&NM5EIdQgQB`a@NF_Y;8)^_w^y77Q!^nJc
zI!*v+B7s(nt%@SBiW_H1anyqodP??~nRlrD9hAKQ_>$!?S=z*U_Lq^KO+Z}YM5IAG
zOpf$0xNv%<$un7l-hzIa^qmsF0wc-8y{w+}cZKK30SnU75_V5PH5TCY5Q?Rtodo<A
zg2+qp9U)6Z(eGIVyMH7MMpDehv{f#>kC^~Av<`>sQR3RyJDIihZdgZXUty?SmsYzt
z%S0RIu(y63(~jD1Wp2?oP|_`nUc1h6I~!$TYkTc$7=?=6mQG0~!8^GF<^IrFDY!VY
z^7yuBthC3{*{NGJc-*9Eed{Qh-1mhJqu_Hu1`hMCCxEqVhW?Y_teJ5YzJ7~dbH};<
zNNs5f(g+mblibQ}WV;_ck&aM-`=@xa+&d}*6E{Sc&sc}<=Jub!0Z+KSPS>X*zTyGb
z9xA3B#WdfJ<Oi`sq}xg7wq!kg&J?#fYWf}QgqMY#@VXg3Gl;qo-j_`uV}*7%aAmpW
z4@!ECzL(rs`*`m+z@q(t%-5T2nIJ`ZdY3z@A-;B>=QJcbB{^K5Q`O%Fpt~*gZlX-^
zc+$G9Rk6-I_(1?08NOP5I`?f(v8~!uDHnK0*?=^*d1INJZmtGQ$O|biFQ$`;p<^&Z
zVReE7HD6QFzd_O1RGKC<jbgiqM|r3B8QR1bwl~n0y43DJ3ay*0^W(W*R5uKEM4^ce
z;->5g?EpIg@p-^?0{A2;Fyx5gTu$3MFRb*`J)oVqs~iMxEnG&}h5m|quc`AvR0b>6
zGxSDR^gIfbTbC-pn;3BaHm5UKO+eI>JsE(K{K|5kY0S}ka7MKM6fR7kH%Rly?ro~i
zH3V~GvmUVLIfJ>w^DV(#Q`S<4J(!zFFKMwkn43U_26HX+YFH6NGoj3D%~7`W&WgUI
z{q-wiuq7Qija75<SAZI_QI-PRChds}^@lOdK{qFrgmm*cw8(v&h5!Ty=9^g8?F+Hf
zcqgEm-GB+r05d|Hx3$<JIaoXHQ*!Xl)>{BGnqb<Y)svB#=b#@GFx2=Fu6ZaebY&Om
zXb&_02U`B}gUes+-Q))|d4k{h4#?ReVdaR;uRk=p2bdQG;w8IP%1;W|Cusuq$>@RI
z<Zy-MT))Tn<&!Y`IVJm)pgnmT3Jcg%zk*wPZ_u8`HG*z-8_!;I40r|XOZk9(nKocw
z&ck8!k+6X0qhTRvcXa=mk{^O&S$PqPS*>XyDzwrT6NX6^_2&VQDg&f^p$%0cZ1zqz
z!kdGRYv4ey{!Mz7d=}?>lK0sshOU4Ir2r^9!c{`F_^N|wv9jk4Km}|u_=9Oae6P=O
z`_r+$nVS0C@luy;3fRU!?XySu`=aV|Z};Wi5#Uw^Y#K+vrd<%Q=~jwuvDmd<6|h}g
z9<W^!1GdY<0=6smfbFW|Tt~0_Mw}?Wh;@AoR`u=4vQBLOalIof^8s6U5$)Rv*Cv_j
zmugTlD%CXxY&=lX<1Z@8F1E$_@-C*!8-F?BtJRv;d~CqMicGuL5@~F39p9V*o4<IF
zoqOCuRPZJ4K7f{iRy=FCk58yO2S4PesqNpkQ`=Yc&~oj5$dEjoPd*>a1uu4A4d#;d
zjPtFS1il^{(4iMJhWdPMeZDTGZTct!$`*d!20IsA^RuRpqPi+R3FyEM8sip9t+#7~
zcAn$fuEHr0C2_tdjs0t$Y-P=(9a!_!T7L-$Y=qy*7HN4n_FyD+>s%mO8<?qy4b0SW
z!I^N_CA%qk)QLewVC}FBr`FYfK&Kzv)<|w%@t=)ku3w^)mVmKl!X*&-U>h@e-kETI
zwFdqanT}a@(C`9G>7e05M8g*u4G)E($C#VbP-AEhrFO6|C?vREB;qyuiFnK9y9dTa
z&~DYdvZ*>~pTu!pXmv93630>*t$B`|h3JLnsi*_cLQ&BhtfIqV=pJT;AfyFjvHCab
za|rlev~I?Wt^4FCTKPrgrho1^=Y5VPW5!N}0|*WYPJn8PQJkuaqh9bI(GA%~xE(_s
zV<H)}jCQpEZ@CB>Y^v@a0!4e1Q}(b$qdX$z6glYg6LZ8X2G2K{=+^YFHl6@mrHbv^
zl6^^xo&4Q6BxR!YTw>_2u)ZTO3Dbj7YS%$WfnZ3KZ*YZ(Jil%u@?hf|eU?Xp9vGYl
zmXm^+R$?q^FNQ+O9{E0`VfA6EpG|AoWUsD1OY6&u0sn*NHAupcgo7V=F0P;FuxZ#~
zK<^}DU7k6eHM*iDpw*z5B;RZ;TgszTlv9*}EG-wzN~9`-<S0llXzTPc(G4BJEV7Ss
zzKSHwzhGBWWa$9_Sm{_c*!$_-lZz*MF4-%1SJJ9EP2-8dPCJguiu-9piU+X_n$Gxx
zpo#@*j&%zUB4g3Yd=8&|9c4iM<ArBmK?spnMQyYQn|_7}Tmtc#CK&$_^ueBq(8;0x
zTBUbmK5}OTqBMbAG;PH|(-b8FJ|Ag$^|@NiN`xO1%QSDX=1Gf9(mb;mNWuaxDS`;d
zPpY<cf`9aWs!j}Y;zt^=p9P1gtxEe@yP2V~zuLtE)hhn-BG}1recfv?C6v;xr$Nd!
zO7l$8ivGG$e;VS+(rE=@co2rpN~b|1P8EEwld6%|U)A+34CJEoaud-wGCe6TrSo#p
zc@)VyFVad`k8)G9u$E4G>c3ZOsI{&63o;j?_T<owupA;ls|yUh=h)EuB#c31PC3;t
zmTp%@A$OfvI$2+9C0nS|`#KX-Dd&_SQ$_<ukzD;CLeq;31S5Sjb2FBBD;R%FzH8Vb
z42s$}nfi1OGJ4^>rp=PfRv9Pr6Vel{o)hRAxFx)pVJFEWUNXZLH=T0LL#`EaRIW4q
zbj5QdI(&(5lD>dS?xISdN4TSX<^<`0Y<4ZA9Er%Wyr&j014GaE6zTeA{}C-Vs4~v}
z9@6iVR&wFMBIpvlbDF8dYfR%oEjfI^Y)k$h!K@fX8_J5yw@9l^4YLh6a)-@otyyOi
z`^=uRNgveTZ;-~2<H(|X*G59)g*Ql#GuG@P?Pp-!E1t}N!h;Q*L1Sd~TTGNBf>g1t
z-ymzxzeDW+Lz3vEcPhQneRMn~S$~;y60j6>$TaAa$qp!#X%47~KDeTjX(*aTDlQZ7
zJ)988!MvWMNpJ>pAc@dsjBzfs`Xn^bR2}Lw1#=Rz%2v6caqyL#&vQ#4hsRbX^OQx2
znFN>^1wbJfrNHG9+={3`jvj|Ea-whs{1fIu3+R!6MrZJv4%xJ`3GHYhCt2w*ypS#h
zatyja4t9SR#j>45NGN4I1#)5yfgBu^%o)k~=9*iHr9*q*x{pfvK#p1Cn>(s?6e3Z<
zwt?tTfWILe$hk3$xf#c}X_!gv6G08|f9g6KW~oH1ei~uzYhh$!+d83D3{#=*u82(Y
zRoxtj)?li=nH?x03J{?hHKF@hmF_rAATX2HFqaZJ3PC!*s*p)3@kRyC01cpir5?)7
zOg;7kTcc2l0&wmGBaQ+PMF3F*Ksyr(z(+#?q6r|H^TD5?hmlu-`3r;b7_n~?$ksEH
z%(=kKgeVj=dZ3`^h88rM3K~r{-82ADG8Et@0=S6_L~*`c4d(Y~2wMcn^7Vg6QOv(w
zC|>EB5|TCnPKU|M><nTSLx`zxQ0byDrA6b<fWH{T$Kr1o{*2n7ji!D?$KwyIU;`^S
zC_k8i@W5=5I;zS*BjE<X`Lf82nv4SwB>3T@klgbz0t0=FPPgHb8pi4ySX+fU(!vQh
zWHbag=$;yjm$y3g9GkYBQkFK5#bXZD>jGJraI&J6UJ+g)lbJNrAT2QlW}3Lb%y?44
z;Ms>Ku)`A=p$jrWWjIjGyopYO%uHm@TQL5E7ECbw&U#!_(?WfH_V*3ERcs@}3}2tc
zDi_=DV8rg42>f7xCiW#0511Jj{CJI4Ws(;*-He6JmLysWkD7$1v_Gc9Z4lcyai2zx
zj!bf7pAcR@YxbWu)BO;7+Sd~IaX6Gc+<#&?%C&xXNYG>wa`dnvw^->wXx|zvL(qW;
zfi5=C#TJFF0sqlh$q|hdxL$%ZR;RQ+&gURdSo8b)3a6o{ugHx*(pM>`eD?5oLIx-p
zd&plD6<PCka5nP!^XMT=jrQ-NMn#1FH^fj|ub>tW)JFMUphE(<<p)9t3}(X9U_)=%
zV)2A!EMOZBB?{-XZ6+Yk*ou(GDHY%PQ9Ij7HYvR!o!}fd1#F3&*fxgs!vB#FK{;IL
z76q-v=*r}Pb|myK0p9*dB5smGI3fWDFX<Eikyu~00bAAvC+S|MK-O@LFAEgI9S+||
zF|mzt_jhT*B;$YKECnQEiBhQ<m5#)Qc@0OrIHX$tF;tpBl_HH%D$D4Ewl>l!%^n`e
z0#UL+l&lfxpOL@>NcZ=hS?N2HxDiZprb9gvo|^+*<-15(h!SQ6shLU#S<pdn4gv32
ze0e+*f!HvMXPaXf_0&t47krL5M(^+8dbmeIy`*u?hBWMxi=_*2zc~>4({bj8Pg`!D
zW0c4enx7^leu^|uCRIV=X&`|`50H4;=b!+jL4OnVN)t&oN7xgboQ8!#GPp1mv-4P_
z445O1Heq%qk93o34^8Vk{{}6l=LLWSxs~~Iu@csg#n{k7xM4$Msezj4%NxeFGY9l=
zsM{;E=gtabnO91^&WV`H(OWk_B}tTKCpe`i5(8PcSQ{S1zGuoFtx*e|!sI!h^mhG&
ze8YpI$R)^E-b-n+UYi|j!nRYz`J|5e2S<Shi3?mZ;dMLkg1T|7TNp3xm)>KylZlt2
zNKN`34R*x^mz)i`>YAgM@rwDovcubltyy+PT{>|}q7Rt#Pn=nt@6s(s6&-)2Dija#
zh&dF-P^rT&!^#!0h~7YezX2eo+kavabwVuOLPoz4Br0*2gYx2W*;P02Vw=b$ZD2JG
zu&s~luf7_GDqtvm5FHUQlq$zCj9!ydyr^~K{+9M?q3!{&N)P#@U_ZPej!vDh1GZ_1
z5w`b8U6a`fTXHC3Cv58u?^jOP5~O%VBm8tYAf4XX)4W+YNC=l&Z&n7qdG8Z8r?=u>
zr*{E6z!@bpu?v!L7{|9r2Q#2Adt@BoFzB;yqBe?GW9Y_|J~5P5pFMIE+COr%Q<^g}
z4r>W5Vg$T#bHd1*o#_`mH#*bZR;?#;p9Izlyii+*Zt~^mum(lmgd6C(jD&;+cJV|4
z?wUw2z1%P-A(0Gm;A8`t;)sdPDp{bO&e0{pNx(ed=WY@^XKW?ghdk)}j<~s76DaN`
zczY<8OH_zEd)VC#5BEet2t>l{(w`1o;_-K9P1>T@JnI^4T9`1(aLUAgBqn7atg0{w
z>X<>WcAt9%ogSH=@A@(E#}j`+F?4U2NruVSev^;a)udS+r4G+XGPep%@3V7V81XN_
zZUdh@_#(vU!w}iy;YS(<_*QZyM-@7{m;pyWV9eew2O})tdYmd5g-X2l5S(;&>09Iw
zFOPwD2A%lM#7v5c3^g63h|5vlF$C63Fg0Ot1`KD-^h)ojcvm{xQ$;*bGaZfmQG=Zt
zc~_*7iq(_9DGQf$_0bvZ<$#18ZlIw*Yh)uvsRs)iL(d(6z!@-G<TNTBGdCk@;5cfQ
z#Ez-LZu=ons^&1Z{Krh<+d63(AIvm7i<b2q11mVakKg2kF)NYziqm#3jL)>e4!?2Q
zq3QWw2DHJnh3xXUmPuesaLh+Nd`Xwl_Zza0+qP1oGx!XBR6{Q8!MPx1r=knSt!BF9
z$q65c82=G)L(qq{f!%<6E4;;~E$lFDUv$+yRN6K|*2d1!qBI3_WEe&(-dw(!uy)p+
za$}V2)?xQ37f1dxqi}13`)0P2psPt|y&s27#~7z~!wsm^^J_?B!*td&!ZT0NO8HJ-
z%}^eo;l;Se7|D-YLIKu8S0DB>DRD&2$q;Cfvacnd`nJhW%4V;`lL+U?Ed%8Dgq%>b
zTTX(q*8`BfOx{-BGOhRf($;(A=8mJ3qIlzP1wV1kMGQ6)W22b4eM4ZfDJFAhOdiEt
zWwl3g&7qj|FNfrEP|UKSxfW8)6f|z2_N5fF@63>xhbX4AeMrnB6!Z1*Au)v%Q;Kt5
z1Le3VX4%OhF+`=H{tG<mUo-d4V49?DCi^k%6Z3dus{F<oWOvLx1@(;WMA-hr+5E^b
zg7^l<D+wZ?r=TvVCqED>m02I0XIg#@USTc+a2UW)5_ZO8r^l$k0St!?GixsV4nUsI
z8{>~#j=#LkP~UZYTx0q1EsZ?hTD&#K$KiPiU*Y3hz9^6aV)tdSQ**qavGKSaXJ4|A
zBMUBUxK-<mf>$l>iwFm$kEGt?1ry#M{aNv6pQeuBTIhj`y^cr$Uj|)FG|Ycy*bX}L
z#jZ;^yOkW@cF>I>%D2Py60i!r^g6DzNM+U7j@$myP~UmHyz%zqk8ks$Qd}oc-$8Hq
z*@$mzajfm}#^)%u(Z|vN`^DoAKL}UcA1UZHqq=^7e_Zvovw=1@dI<_JBj6w&x%Ep{
zT;{%LWLFl{cQii3%JVnYvUhvi30xVtuVh~=oMbiaCHpeyk^@BHphv8DM9_39kp~7M
zrB5Q!%|wRtN3nu1`A?X(u0a<E^ySpiUyQ>=zQ@Nk|6wTSSSVo&C2VO94P~-6baLc4
zsg?i^1EApIAQx>V7uukn%$)QusDB>LyGn?5i|JqE-;~BQ{x7|UoI!R+V=>HW<Z<X<
zq|~=J{)OIXp1&K1!uCQ3kLd)6iQ7s>$<;VCx&RiFlzpMk4x_gYu}uEPPa~N>qc=`)
z9>v)hoTbOX0O<p1zyH$Mn&Xfl@I#3CT8g8En8X%ht2GPer?jyh#E=i=t=6u_MI0Cl
z%{a^wMkVVhGRz|N6d4O)6k3JIfytO(trfPLXmRy{|H9b$3y^LfEJ;I|$d($Kf=Glp
zoA3(G{B{#E&sjgE*JkShdcA1vP$Gj$Bpv(0N%Hsc;#yt<fBI?}M1yHsyk`vNW!{!4
zf309_qjBAKi7*a)9u9}^AzHcqMohiuzfdoYQsI>qE6)W?LhU$kK=o0JP@8~&cQS#t
zfDbrfD$RpBM4sEF5o#}je}lEwE~L;u1V2<lbiSWraceBORi^K*&;_(n=pzl6H3JGM
z=Q-(pkwJL>#`3f{w1B2N50keLYlwY9)mZq22dlfl9xU-!A0i|*9>6oq*ysCeZsuTv
zU=>EALL0};oWVh9|4xNV|5=4B@jDd~Pqi#Vz9C57F@Pi`U|x@KbFi8arGE;tEU)W_
z@>0UT$XonFc`4yv<X!zkc`4yv<SqH3yp-@S@~-)zyp-@S@~-`%yp-@S@|ONkUP|~E
zdCPt%FD3kNUK+REU=QwxvQxr9_U`N1gR)l(udu!H8PJ5Q*D*^fqM(ct@0{~n20hWl
zwy?MlyZt!*gj(Tj^>+39h8A)emJSTz&A|c0k`#V!9vnc;QAVaY(P`Tu*#=pf5)_;X
z@;f*yBBT1a76xP{+9{$3dPPLi)2A2u82qZo@OU<t_R@tM2IGmX6dBZ0B%-)2z1Wql
zen+#F-a)-X*L{_HmP&bqLbVj)D3oK2giP27YCIg71$+(-+m%gk$FTrboy4je^qL&6
zY<|#qRQynDtzRHaI~)HX9F<S#M_Xy@kk$^<S$isDS-~upg~Dua(c#)nV)N&}XPRg;
ztumneSdf(|KWG4E5Bd!17g7kWWkEf8KPVx(JD4uyM)N2HX&BTm9SG4CylnGMpE?kt
z+juE%3(b|j_2H7B;xi{t^EwRPJR{iwbO|HNd2zi-;~6Jj<*E{uTZQ17qv6&G6l1Qr
zB*0p<&Lqb^fNPBF!W-IU9?IIdX7nvJfV?eO0~(F^qWg5&7ksx8P>qitIr%G0kT~|R
zH5+NZ=cx~+QF#bUqbP4=X4KGBwhCuS#0~+c6s0kAwel9q!tPYwN(Be?<#^J+puYEQ
zfwMa1&TWqNqkFcV$7e&_IXsE&wa-&BTkL*=WiE>k>P?injWU~+VtSc@bZY{>W?*jn
zX;o}cPapXAJf;bnJb^6dQ|3{4%h2&;q3H@v?I?y4<#0zI&TMSEOy?+J9zpOb9Nud#
zY=Wg>GvJ-L&f6X9oMC!gr~^;Z%nKEWy`jm&spJtn8eTFjgZlt(eeCr2>BJ+^Omo<O
z)UcT+V4R#`7MZ??ujkkO=bmv*d9HZ1(DPQqbF9?XE=;nx4z;1yN`-Ix;54l~p|Lnz
zr-}JSy~3Ce?tGC(g=XV23g&ks-3AhTZ>t@cuVGun<yp9$N@zME$^K)s+l=kCI56?x
zL4d1Z2{^0cSg9AjI<%y!#(K;QlM#^z0|j3eBvA~(DKUu-Sgde=0bGV1Sl;2jrl7-R
zS^{hz+d|ly>0&4YT$)iH1#!Y?uM*VY6d#cXH)mTmRb$0wM<|gF#=B!F6#qEl?n0Rf
zHE-L1%uaS<0qVk;7TVFo$@fm2C!p_bS1H)@YZTVfi!O&nAQXBRJ3=krpz*9T5b*{@
zlq0zn5)O{Ip+8ZCn;`JV$#)VWW)pa%j&5wh7DZyNdpKc2cQ7kIUI6FG+G<vODKhua
zAp*)(!gBSY6v}m@dl<cLRhow^)z$LbDPh>eG5|+r@(eK?<<U1M6CM!g#2v$EAGcHC
z5V|`cKp=>r`vERDla1ue4tmOoVz-74!X6TjeIv^JU>?{_&J2E?lCUbL+*0qh%V)$4
zE9ai$#U11arH{{lehwQgZsQgjQak7&-$Hi^g>~zUTWAFBpobj0g$CLVdidrfhsS*&
z4Z~i3DCEY*kml~0*f!7L#c;GxHxXHtZUXy8+=vg58?ka|ia1JqPlukmNXADx9L4%H
zgBXk=w_U-qu&ZvLd%V-X#%j}nKsH>bho6MF%IJX`4scytLrpmb*|y84iQtT1)>7Zl
zWeuKHimmeiIP<SDJE_`w@Wp8qln`g5YH&P7(+FaJeTKzVD{+mu>RthQz8~l>3<wuA
zBy=H)fQkRFVx%JMu=S6-eSgBZLj?NS!3olfmvPy^o7kjo&hwKzJM}(nPuVQ^6@m?M
zAv_h)){PKE+c*ysZ4?jDhG_#d3<veeAU3&)yXMje8vha)6f6dYhOS`bLd(H)%WG!z
zLwT@>W?_Soljpgdl;^A8!J4+&`V4X{gTZzg4E#&sk}~kq2Tv)dcRjcwqW^afeu-*a
zZV=b?6Dna7N?7_Jrm=1&OG(4;MrllzMph^Xv32|YYal@&CHy80OSu46U2>Tti30nw
zaz`2Ntm`qrRdNQLpE%FdlAzJY4sbf93T<=OF!;1x;E?2wtGQsp+hb}zZvX;Dh`E_!
zSg0~#0~0RdMXaW}a~pme(Ek!FhP@#@o$<W|b}oHlf1tWQ@C*X?63Gr-8qS5@f)t`<
z?G-F*pY5RuAYzWOqDie!VC0`1e;C2j+txR}cKT$>o{ZN#qfo8^rL5Nl^y~39vrcGz
z0&?S8;C%p2#AR8&XGqh7VVE<l*9M+pd6?MoCB_O(hw@!75n&g<h}}LD%JUx^?!?wv
z%mL?C`fR-bEE=_^Pp*78L+iO?+eI7zxDS4=p2TezaKSc^;Q-YKWH#a*%aFkVggvbn
zP$}g@uE~SBZe_WKV8wHNK#JvMD?a3fudkuCCsHl4PuzB*zf#M#9#o1+2RE|Ol9vnV
z0@dG>d9dz(npyju%!x4Zfh60AB=+A9kR+!1i?3pEw2D`VLI#C1Feq$4I;79KFc>gg
zx=4ALwV)yHE`(@UEnlI1o?>k?s?n96uSsj5v}O}Vv2$xDG^i5hS7om8zXJ%xp^UV%
z&`02QY4?!RWGwbAip6#&ES$z>6LMgnTRD%#wTH0w{RXL_(9QqOTyT;?BM?~HLkreC
zh&F40XZ}oQgSwS-9V?|0_=1v?Kn&k-e=Kt{u_{g`u;r7JNo?b!!M*=r4(G7Xbp&#v
z_+XBKTvUQN#(cYDk?$$f&cmp@1)YY27r`7Wc{T1N>3}28uV8YYBn950&l*sSGr32w
zbJlOq65iaC$>R5a>3et*CjN!kbei9c?M3K+3Z~}+I<EeHps0-(FR%;Owf){{?J-^T
zb{%Z-MyZlKi6@b{cz6(wkWuIgv<r<EJItC35x=$n?DqvxT)N;ui3?L_<!4&pj}m3E
zG%!a?9Q>K+%QrL{$S=}B3g@|iR*UVDiS=37$JE9LvXCzeyw`Ts_k;mg*PoM@4eY!H
zG&*dR%-1vc%&7YL(f$5TlN6PIs2k=NXeP}2BVbpL3S>rWaUSlf78k7d7(~AT%9jbZ
z%|m8!^2-4YAIQ|;g4awmDUb;thfKJsX2QoI6K)%shCrr)oDAR+U?Tt<bArH|IYDS9
zg06nL*7e<Y-g!sroX`hF(6>;Fot;Iu`Z7(<2_dJH!#6yP>*TQM2NzVmcFrg+3qNZ@
zn}QUb!#fs1m73%_Ni25fuSj_^g?@VoGmEqjGYdGG6m~bw5D|kcg=tB(5$}YhWcJrr
zBM2WeeLdb|m8j<sgtw`FGu{&r6=Z(>#72Y0Dr`<X2;PC^>`ldTwyjyQZI15+9QGe@
zCrnJ|Ryru4#N*&1)NS&$Czflb+jxN-ZM`w%8k6z$K6c({1NWODx5QSBvnjt3v3HK|
zX9V8=8xe}{5PZ5Zr?JcHP%Q2neuggF+e#6E8Uoj2ZyWc+2D7r+gqf8`ug2$<RUwW(
z_PR$fgJ+jAZ?=W*rjblO$!>u~F$owNgIL&=V`*l13p2x#Gee|I8j&W2&KI@NwaM%{
zkMl<~f%v~m_gFwgX@(Wgq007)im8sK#pbO{awMmOdmaX9geGi4(|Pi5Yu;sZW90TG
zw#=A8D)6m<62m&-*>nVO?3~mhsBIDD2_CFh{s-a<awXX*C0=<QVJSpPAt_CC*3)Bb
z?nP(5Ns6zW6gjsZS!wJ&CG8gfaT$>q?)_Jh(<yeG^qq8tU4Jj}SLpite6U`sW6=^<
zGB_mk`U_AZ%nYE}dJ?nf21q<#nMT}|aIS;*7<ZPV#<xh9mM5d|gn`2Q&&jjX#5M0F
zA_4j*lu%$25RYGG)hu4JNU0_V)i|Y$Qwk!frw9?BnSCnNYN^_%s9K1g<N@t#Aru5i
z=VS=wWN2T%g6<m7uOo3mv&LJPHNHJIq(2W3p8C+DU*c5v4EkLd`tzI#y?hK~EOKgf
zvLZU*eEq%F0;l)}vmS6lZ6#P8{rsOO4L|kpt?LmY*n-U%p}VjV68b6PAD*#^Sg0;f
z0o~XS`Xqtg0Z>{B(BQ?Jn2mcA7;-CpFIr#58zP$T`6FV`<}_zy^Lq-8yv)W0Ak>sw
zupO>*$J6!17cD{^9argDiATzzo{{V&=S!z|96<SC!v8^u^rI;^<Iar+HY78mtA?{}
zf;qlM8d6XP&iVL>4%g2Jz4~8(wz!b**U$-HqKGO)*s=L0Y}eB-tE6{qZ0z|8h2k>Z
z%UaJZi(Oj?YCfR6y3l73TdqG+gbfk$B=7z7BNR_7XMErZ#Yax~^aijnM}lLq>s5jt
z0cg}QGgs^|vVF+(;KrAF8m_@zxw!TRaBrki-uXGheJLTqaNmK52<~*jHsLO(VKJPB
z-#7Z_cr8-!dIAM7i2>v=1XHEj7heWaIHZqWO2rZ=jSeTKDo3S+=VpTwn`u8ORF7W9
zD$PBkuI(qM(nC-8<fZKM{mn|5Wqtw{D&E9jrXTRl);#@n$v$HqPX4T04~q#2SV-F#
zzZ6G7g_Pg^4F0l^)dbNHM^d$c{n$<YC<@ot(^F`g@eGou&!A1*r{bV$>p#SIsO9r;
zcqfH$o<m5#<c>z){sD1zF<_iNhJZKrDCQVoMiU5`VrcC2|Dx1tZ7W%!CbXyQVVf8~
z!C@q3*zt}bE6{|Fnq&0aO4xweGd~|jpcP2ZcfGk3bvuFgmZboKALl4CfZ^UGel~hO
zk51r+?;*pM>r;Zv03<v8nL?+rlDtvg#XN20>E;<mt}uqzndav^7A$dnL$D^m&J+V?
zaaZE>8C1kZTn`!o&debfC+kx7VTy`7ez39a_{Ru+s4Q*F%aHfO=W(iP@D{%(|A-&Z
zS%y&@=bB8(|BK{h@+2IJrcHB0+|mKL25I}M$ukVg>-2a`IQ!&ic&bF>EJA4Q5nLD)
zhmD`e`VO>%8cM4rMGd8t(4XKm@J|l=wJz>c4vHDkHu%1DK;N@i(4^!~hjZibHv)e;
z{C#t1IQI|yeT=`NQg=~>WqjqdSk7XZw`k5BdRq!+j89HmZ?QZYd9RAR3zc_aCEls)
zEk%)crShh%mBkT|$otW9<-0QSUKPnwOy4NN;$-hwZdJjWH7P%`R292jmg3TN1#5~6
zEtT$qRVA_9Lxjv-mYmW;i`!LER8Sbp6+K#5U|CzXuBg!BtSDP+8Nc4*F2ggHyNiGy
zvgEr9D%=C$g%!o?iY((-aRu&z@r9Ge7fwTyEtv~55wzqLR1{9mF0L%$EJ@=%mbt}Q
z8{9>e6O^x+{a@Kd>xx$uarW%V3(D5smA#m~zf+!L7L_=@lEeQ+r6r|hRi#{30gzl%
zR$jir;@(gWG=TrC>>P``cx{oT%;S#b%FC*XDm>*DiUnkWySVhRYhwpt(Snr~MU_Qv
zOXZpZG-@zq&7%d}nu3bQin!9U(xM@#IqZ4)Gsb)F8efS27I#HKDYCkY%SvZ}2y<8>
zrQm-o4kk}7TIH(bh|HE%1?2^+irpJ5&Vu4KMMzbMV5ul7FRO4@TIS|t&ssFsGVg(f
z7RQ2|{G53UW4R>-#e}}aSyo{wWHh6mDJ*gqt#Vt|78MqI)=rr+#RBS7ddjI7bYUgZ
z0A5-A1gPVQ<;EAz&5FQAa#H1Jd3o{5;z~5Xpl}0_aC<6Bk(<!AXD278XmaLQ7Cx|G
z*1`uY`Hmd>tlU}l%!RWan8y{TC8thhlmfXeWu=xXAZe+pD0Uac{y?I_W;4s&mh#G}
zmePU}OA@%z?E(9)pD^9Bs;m^P^ss&c>#PC`QKJdA5O@+l4uMBsR!#-ltJXaV*6K&(
zd#ZM>@l?9{<135SI4$5rcZB?wq{n~`N-o7KdHp^2Oz4L!DcbO88Bq8q(8<Yw9)SB7
zMHdtd1uiZ{k77JNL7lLuwBXS-XhNA~P1&jvOGUw2%Vf)=6~%>*6*0V=Wu8)i%__Cr
zJ@ru#8LaAA3o6g{tSzTp%C}{m(&I@WW-K@F`e<<XxL9r>#>bHUTKTxkGQQlB<c1I`
zw@^P=AePqO#frEdme`^kLZz(KS^U^aPvxT+@a2qCP}u+(ic8%U5H|NID4;3Cv}LYU
z#fU7%xExX{i>)kkx~mE*il`MuNGHT2xjcip5WBVvKx>Qe!q`EX1%-v6VOeRx8cXHc
zM~llUEp8%XB`abG+|WdZ?E~wIDj*T6(4L~SsmYc##g#;wtg<p?kTKZ@IXaDmsS+RI
zmTBNo&zeHkDQqyiT}75hk<U^HQ5Sn1EU{DpOJ?000YOVBhZ4oc@|5fAuEb!zt}Oet
z^)mTv&tCArTuaibvO<h-pvrpPZ7C`(^E~FdhEl7_i!BwEg<uw{7Hype)V>SnEGQ&G
z0K-bis3Jz?%F0OG_hneypW*uwUFD49zP~C)y;9HG0%d5k_AH+JgP2uT6ky`H7Wu(8
zmN_j&>p^R3rb1Z6D1xsLMJ@#I6qIftn4$_|m+K1p0cs6ah!eoGluVV=EI6s;pus{1
zn(+Q-+y+)mPPq&JrzR)=n9H6ucdjM*I_fHn3xxqp-H%rO+^ks-<Xg(!6;uz4WffHv
zJqC6M3r~Zjq8T}sTi_`zB^g;(P9woWoC`t`Genp-mqf?VWTp!|O7oDbXjKX1$TSi<
zRMDCu%w3o_JZm8VV!8ZP1*OW^9Vi>^nN##w!Kw{I3gqVJ%w5EhRy5c31SZ5-?*7Gd
zmH*rVjN^QWI9SCMbQNq+$*OWsQso46%X-w;KVuEV$8wHYvzFd{7d=y%*qCN1TC)n|
zNS?YLt(yw;9QIk$ERWLEQAkswvy@dbb^SDm!P3IAij~EMEC%Y3GGh)#3~AfqnVCb{
z0#?E7$LLvVS@&20%}AAHYanTv=0gejMFp&Lk|0AWS#MNMz_=f1*qU-oZZwY%iK{HC
zfT-_}Cizx|ej*Vz*Re1&YfcV$G<ix2R7B+;H`k%`I*B;O19Khr>tcwz(R9?plpv1u
zEeq4P6lIEo9>ylrin29pNEt0;j6ss!k_3X#lviF+_Sni|CxVb14v61MOK!?kh8UA+
zYl})fQ_#5lqBW#vC~}TTtZ9fHUpU30RBl<$J*<3VHA2zj(Rz9-s33X4pju&}*}Bq#
z0s0^ms=VUIFf}tNytbg+;wq>lOrb)oRg`C@RD#oqeK04|iv?!@EYd3$Ci<`Gk0BGP
zr}UprsrV76g3`h@MJrR%q0{$=Y2hCmJ8W2aMbYHsDXCNLo{RyUo{}>4?v*K1Q`7JH
z(d5d<J;fCjMQf&z@LgM0irH^URVA`<w5UqOAK9vDYn^uDCtywR=I6tiaf4v8Av);x
z1kFOa;sJiKODTqJ<8ZU)Eu3?kCdOh)e280Kot-svrDj-mV=TYCW*B|w@R(yU&Hi|0
ze%8w6&)ok3#zC@SW!|i8V`f*Z&ag5wdjV%yxoB3l#<0?{VB!DQ-n)QDRb*?!wYxi=
zCN$|z=s*GqG}zn}F$uSzt#$|rcL;==f)WL*qehI-P2z~y(21rK$T-eTXPk5Ja%Ma;
zo--L|ekC}AfoMQ38f8=j2ZK7;+h#B$Dj{I<y{q=_?!7~pIiBbH|L;8CZ+O^UReRN{
zT2-s6R@Gj$R_fdhfz<w{{`gKhZ^7IdObJT}=d)BRr6(B>nI4T85h-A)158$YNo14<
zaB7Tl0Wev4C-MO_8l{}TFJN)FqQI&#${7VUFp(3WA}6AhGg=BZ=nAaJX=Ic$3Tjkx
z0#xKglyag*0v2aX3alDaX%wI)C1<qqh-&GC9vpH;YXDz<3RaObLCG1dJfd1UanP=*
zfm!5?f|~VoBC4e`QAcN@j?P3qorr4b#8IV&PK(GHZ4!%~PDHhI;tWhfXFnaC{q%Gq
zs-+WK7!93CIy#f|bRw#y6PJ&W6Kx`TrN55O{(3qQ)zXRYk{UX#Iy$X-IuX^<3H=BS
zoda}q4$#wysFqHgF>2^c*3p@)rxQ^voj94%(21jWrS5`<Y<fBo)zXPiSPHCYA-j%F
zyPi%&wREQF=uFYknWCo?Q7xUgQmLUcRYzy4o=!xybmH=whR%UHItS|ML{v*Bj=42-
zI&^e8^mHPsr87-OXPS=AG(DY&YU#vvQ4O7gbaW2V(}}2-&cQl52kYn@tfv!EEuA=V
z*U*`+qcdGkC!$(9Gjw!j=;+MQ(}}2-PFy$E&^bg$=MX)eh-&E^s-ttLj?STaIuX^<
zi4O=GIx}^2X6orgR7+=;j?OF{omqN15!KR(HB&?9Fdd!4^mHPsrE|EB&fz*bhwJG?
zRH1Waptzu9iPWF{XOd;*7CS`>u-q<n;xWUyGEh=D2aB`iKgHrqk%H;jg>#%Mw~i{w
zS-n~;#hAn-=CG|UoRck8BpK-avsj)>mM)N1ZXI2c8wWGQ!Au&kBm==sjKdk@a273`
zk>Do9;Y@KjyB5wwaFgS332`{57A}F{ro`dQaX60_&P;Gq<8X;_xPTTeapl%AC3$f;
z3v<|&X2GJM1+)<0v^Zct4WPCGlll>0PIj!JlQe+3CQK55IWfTg8bDne_7{M;F+i&Z
zP}hi70XQ)RI6woaYsCQqa8e8~Sp%qR#$*9FIR<Fc0P5P&wsPyZlAI|qKs$4!D(xtE
zP1}-o0Xj7XnxX|YFfC|`0L_bmrfNY=I?z-BIxPk|Pz!3&fes|l+;|T;w4in!s6&9p
z`zTEd>ePXz3D9^i4bp;obfAL-XuO{WYe54#(7^&U-c#vXP(6pH3($C9W#~Y4Jenau
z<GnRR2dd-JAp$hsTSIlAIzAmLK;ylYsRPw<YNh~<_g0n;)T!lxECQVv@2z1vP>&XL
zm;jCU)^HtYKnptDvbtb#Ny_xZq;<6em;p?RKPYWtVw@>;T05;U^#u{l3c(+DukgCl
z8jIuG4HC~jg2h;QPoKMbddScT{TY~egKdiVYwziKg)YV5uX))0Y~|KM6IsHFZjK~u
zj<79aj()34mgKW%lWa=Oh9_kbngJ@Bw(cHdn}P;Aiu;*;{#6rbuSNT;m0PdGfkBM(
zF=b;a&zZrV6@lDnU?K%pZk>Jwlxt$Z5_WUNld=m8Nu^jXwqCt>Ndev|`?mgA5~z{V
zlhS5N70^Yu8%9#|tY_<)!AzvgFwLDlBL;6Y#))u@qpZxb1o})0f>Kt>B;;Pp*5Y@h
z0Yp4YZ&z-eIDg^N7!un+4U!BE5=&CTNM?^^nrSMUQ4rf=VtS9YpJTj|Yx>fn?3AHN
z=`*D-j9(a;X{L0}cn({)ksfxXiApB`>{S!y6)%YukM(J+=!lA2Z@qOw@rs;@GZvTR
zmp)KR91<wqVg6w$TJb3p`pGduQ;t1pz)Y#iSY@<WMh4=@^UVbd=jTKlGy$7m+5-1c
zM1fj_<)0MMY3wvI%Sd~?i0M>BZm%Me4F8~ve?~^9p%WgfM_S@#coL{36wv`KNIa7>
z5j?Xh$+dFJL<$?JnVfh`r$+%j3h7ZqkD2tCMUUC^nB%n1%@qd)TU^%|iGztFi3_FT
z#f!2nc;wI{mmU+b@XqfK@hU$`q7@?~dXP|(GAL<aD4F#$Vz-P@2(4)Rzn?jVD4m$p
zzjVid2a*DW_qK|pex=WrI#O28m|emiq$K5qqtK-EWbxv~*(u3M{X=HfPojZ$KdYm(
zqy%Er3d&KsqyLXflL8f`l=4(!1*6|*3CJ;cb;;rqsjf_grWcfB<<<pM{pr1`pJbqe
zkZ)1{oJ;GUBkG^?E$W~1t?Qqo*1w>4{V{KStNQ0&TK`;8|J-j;|J-j~|6H~HGkVwG
z^eyW@@zVNF6!o9@E$Tn<Th||>4sv#?*+dM9@FWU@H7Ptf8n(~=<?5Nmg@VKZ^jRP~
zJ9`Sv{`0c4*|U;k-jfLBupOfwSapptx@^#%A<4iV)+EseLE1687u1YCppuMzAT#Na
zVH?pGvP+@*L}t+=!(O8=WS2tqiOjA?h7Czy$S#HI6PZ(w47--TkX;JZCo+#78MZck
zA-fc+Ph<f-GVFi)LUt(>koE5LrP%-Iv0;}a?HJRWH~IqW8(l9}!(OUSbeDqljjk6P
zVaL@cx=X?OM%Rmxa&r1ccPUuk=z6hIPHx}mE(Plwom1ZxITQOvcPUuk=sdm9P3jxn
zrC@!d3-m%axo>orf&tywUJSKV>=%0>oC1X7dI8Sp8}KqHarCdB=%!u<Wgmc-L5W#d
zk23EvDEk1s3`!iL>rqa-49Y$LFM|^2xH^>B_x9bEeE?ntrL#9m8Y_KuPalAnLFws@
zlEzD4DEk1s49Y-nlr(1gLfHr4Wl;8>5p!wW^o6nyz{{cRHQnXX*y$7HrGS@1*=x$n
zz1-+wmjYf6Wv^*3_j02Lmz?$7Hg)yoQ1+VoaxXV}V6a1vGVih|oxLD0H+tBmfS0SK
zM~@Qc5SQtmO93y3GSCa<<wg&?6fnsMVUDD_T$1W2FfkgK6b(#{2Bt&<Q=@^rXkc12
zfCC2w&-7@ZAR54Ff%2*_8Yn`5efRhOs}|tPcnROVb00Lln+#aUCV1<HRUh{y)gI+=
z@xzNEXZS8khc9prqe>l(FvfJsiQxIe2L2?!x$7cd$#3N?e7V2`H)gOEm-9N$`MRNX
zG>nKjwm%0wY9$Qom@u|xRU!roC-Hn9JfGk{5^-_d_8rdQ(P0R(H|(Lj1b@_@BqH#Z
z99e{78=C3OfC{KLpp3{gp7XYXFW;m9@5TGj{icXZO}1*2t&ssr@@zYYfwsM(?yKXq
z-^X_;n2%E>TBxX87+~|wQNm_Et<yhMsa%nr3Nk2>Tdm6PGTiR!<l)bu^v`i29%dlJ
zA5$1c?D~88_GR|SuQ)Dc$BL!K51zL2P@A`PhO0jV%sf{Tf0+(CKp8)G78VY(y|pPY
zqvr3=LvJXZ6tVKzkq@I?BznyMca94QN?!;p7StVv;`q+8w}31BlL|ar_)@i>pcIeV
z&v04sgtc-!;Uk0R99QU^T#n{df&(ZBgo{q|;71)I?J2V4z;RD4jZZsJX%}gsG=k%y
zw<1QgoIvNm6W)lZoo`ZFXL2c_6<wP}L7**B&{En{bRR%PdkknPEtE!ZXdXh_j5ur!
zpebzCRR#sSm*d8_l@woWHOr+qf4BvD7)f;Vb0@&bUVard#)vNz{>jP{WgT0e2oh`$
zXGwgg2Te{dpAr{-;F6B-`KyT%cHjl$xE{kp`}m$ulTh#`S2~wI7XcTa_Mu;CKUc&i
z+T0Z@jN{@Z?tudk*6#V8%@pBM8{#lae0@)kh1ni{ifPKmXKobrQZwJvp2VlUW~&LJ
zk?J#D92No_Ftkvqun8%+j1KPSp>x}gH5@(rY{M}x@0sL6@0K0kOTFFo4GIE302C$d
z2`BMg9-wZ(;CP10pg<@~P)dCcFkEJ(_P(APP9(sx0}`GQ4MhVIFmOVJr26$1r4Mhm
zfX5YDz5E=UR(bgqOI&UNicTTWnHZFN*QfGn$0`RX9lG3tf$lFS=8kfk^~Yk05Th+0
zO*svnyxyj;pQJ{U_;g%tO7I_!JOqaFeb38r)62np_tE&LAzx29uR~7%tqpq-o#7JW
zGas{ts1WSU11dC7sl^79T1yKhJ^+H^SqhY~{1i<D^tM1{#Vkr7K71Seh{heOj^bPR
zUK7JO#?*&FYUgE%Ez|{-)YmH__it+x9a`+gPl17pUnBkWY`_TV*^o{TJ3TUanN4JM
zQ`X?CPLai>WGQf}za!~)d%<W01$r1h-sxfCWphOCZusAz+^AklY)*a`47``a;ztL#
z!GgddUREQ(-&DZuJam+YC*vjyV7#>jS>E7Wm!!-m3UP}m&rd|2pDTGVZy}F_JW=45
zC}`O;0&qP6uHZKl;7a-ZZsql^4`{gww^3p7afkg0^M(pCsos6fV1K@wv92#8-^Avy
z&>QHqau-^$eik}^`^~8On|#mbcC>U0m-d5FJKqKEBg`uMY&B0YZ{UVgaN-A0$B&DU
z+-N?Pgel{c73TX)9EJ(RuSht0Dgll%VY)8?_k}R=cAnZomqTd;!Z3xH*fYF9yemNH
z(eE?(F0w3gnvZIx6ya->Ur%BGIG)qPU;YYjxo~NOQFGc`Yr270v3BNkK9j>{hF?}0
zi&oRsTwy9@O%)47>jaSLG1cznuXup8VIL-@8xTNsj?v^)`#u-`VeIs#F8C;3J!dBa
zHQrW}E76Pl)e;Z2V=bpV;afPKF+_D~0+YDaMtItJKMbi_k=n2iErdw$N5}}_V3`%A
zz0F^?9}>|SN6b{<)AiyluP-tIX33F6WJ9Hp?@_7=P|$3o4jAn!g!OVC54{80Fb=kF
zz;Lf$VV&TuU+G3C9;bE|t00D<$%SPQuV>P0Paa+$MGUi>vP_0(5`%3HZ>`;1dkf<?
zsfFnq5?tQut(%n^IB&F7UnNxzsD9lyByiqftGU(~nG!e;6TE{Af%6Hrnk$X+Jy>Jv
zJt&SEp2&$$qP4Zu9GJo6WTOD$;e}$&r#S$bkrNAfGM-CZ1Mq|wa%J#^$*Ko(6h+a7
z_R-2OokFX*uzYM+ESB<qonCn7G<b2NeE@}w)Pp99CQ~$lGMTA<%P@7oUri6CCQ_<p
zC_Ve35Y#~8dp_z%s}Q~{^1I+^9s<c9X?78l75t@1UigcXnqiC>?s;j7P}d2n&H%ZG
z@t2(-RKAHi#$)B-J85B2GtWR`j7q9I>Z(#X1dY)Lm9Gi3fV`AS+y7=N-=&#Ht?190
zLZvSgGb+py8F;WA|2rj~ahwM~&f>uqW2CZ=7O)WmQ%}R9ui5}*vDWh!UY7i!Xr&nW
zuuM)PMxE%W3khxYK!Nv7=G{k*UgTC<=&6MhV+Gi1e#g9ZgJOulgetepN4FYyzb;}5
z19i7iWd*?`h$oZ_2KidlkeI*#Cb)>N+WaoFV1k#rqRr!<PgRm?_XJKh|HB3vMWQWD
zez7ULwvK3sSQQeuaGXIiJ**U5GSow_(KwoX=mc&<=J3!S9y-Ebp}X`{opYaJT++rt
zdV{BYh)T~-gv@rjy1B}X5}PBr$TF^jXLLaZV4E@@GNbd@Mh7qZPqE5azXCBUNwAJs
zE<Aen(XNY;=GgF$?o7lix{oT6rBp(hQ%E#3@jH({ik&atO@>~H0-94GUbR5T@^WJ)
zB)Wk<mnmX6`zY1qD9`vp)TBeL2^NKy_Qhv7+0qkVq~4<<F>$xF(bCb3$!pSU&!H8N
z<qRz+;rD6cz^qaG7xeb>1Tdr&xB%9~l-b^awph^!$$KI1cLd>O=F_!%V0nn=9EA5(
zAEq-P7)t9XA$Sr97Mj1_WAfz?EQ!Nsymd1ZDPo`yt&+=(6zWGI6NMnpZeNywkN}e?
ziN>{(f#xwK1Ex7O1EdX+0nbEOCKFYl`}U|p)lhPS&Ub=^dm=E--fmGw8If{9(<AX+
z2u$Q-;*M`YsIAngG1guV(OzBv+0lBA*M5!Gqgbktk1+o!`<VK>E!Z7_A%O$e%J~!g
z+<7$ee!PbvEiX**xS%5`UPF-ObCB*p$3l*@FyBZb1G04kr2I2Hc#0%>kqbgE1j)1a
zMuux3KIg$tbr9aO_jm!Birt#|G*t`YClB|~P{v(i62noXcU*}*QVLmZ9&Njjf+cU7
z!{xh%PZv#)&PRn%KQx)ekNz>j;gozU%_Fo;8&_cGJ27Z`aMyp-zY8)%&HW~{?T0AE
zXXZQ46DQynbl*)a8VbD^BC^rUB5qOGQ`6Yd=1mqQ1HL{R|Emzd1V0o{w1~GA^_<10
zwfVoQJ?O2S=Nb$UTA+CSU3PLySUD7p@EVOHse`A8aa(DjEl-ba<2<w^gixCB;TEAo
z%)8IGrSm<XVfBXBZ_G3FJA@=v3Jm4JgC=k7Di;>1zw<4)U5#}q2g1P{JoF*Wb8y!Z
z3KL{14}C#%;y?~d&K8J**r7m}rA=czK|rKw5<1X=VAlN}f*j<<rG9u2Z80}O+B<ee
z&`WX$nfZsOW;8G+F9>{tVdE3YqAiKt!lT8~xTleJMHm(PFWV6y`Zdv*ke@$}w&YR&
zS44_57C4t;T*IHJARdn;E^tGAA&A^dOF7h-=zzuc`~ftXj3!&+g7<Fa6*Y`_WydQB
zLNvE2uW0U9UZGuNfi;2XH3Rj0G2#}P+CHO|3S%tu9h#wNu)QO=0ToMzAc^%|Jh5{}
z*e;$a77C||@W34)>w9LtTO41Ao>kg!05wNAEY=*+c>ZnJki7IY-*ZY~E1Gd8WfL<f
zV-N%IcUY*7(Z~aToCa_U5C0bYt+amCBuq45(CsDCY2Jj%rzbKpaMI$(41iwfiKKDi
zeT(>yX2^OW42Z7jQoAO-&oP455(ijlvtWB-_kKS%fbe^Z;%Q56;REnZD!_#)6<84M
zrWFd~uLV<Q{ZuY|YVc`iH(_}?*b{lk3xf~_WIf3DoCH(s=fZ$uG&hI$4L&Q_`OQY#
z*DZ;D<Y}=)_V9wpp9E;Hf>51@FyJ7wRF2_WUdKcRi!cNzEHUy?q}s-Dg#^!O9h=dp
zp+s88ZtaswhqtacHPDq%nH=ac*@77cn22`BCPM&@3ab0#2OEd4CAnFVd9>361d!NF
zF<wl|U=ov<k>PIF?8Qu++L$b+!ZTcWN8#Zix6$dLk~RSib?NepHZ~2tbhR}rYq@U4
zJ*}>|pP*f_YrrZ%hi6>4qQj`P)xsK6@KecG*>_2Nw<2;J<>yX`u6|duyrUWqnj0Iz
zZ{S**ba}WL&gTT$Ut{!jopv|+M(e8cmRg<HdD$N!ibU1}$5M0S4nlxqwF%xj15Bx{
z`|nj|KDzM0>E}HD3A!@V)iQC?pol*MU;>ce5)*w6G+LC#j^v{jmsw4*P$kCps=roN
z9glxtB-y*q196lKQ+1ld4u^)3#IE#{wP48+V8{`^6khhOki)7YsK^TWr|gr`+Lox8
zh|TY4Z+&Glox9d894&s9kEwq9{`(pr@?n;2PlPzUVl4MS%)xP7+k>>D$(IQ5>CvcJ
zWR}RYdaQzBoPyy><fe_O0HGx83`b)6I*$LC0bhLk0xvFEwD>OO?SY30lFhm<s%O{A
z4m-XJr6K<g9UX|hkFrN^*ekHtR}7)krFu{1v{wH>c(=e&AI?QQa*$p45@P1t4ST?d
zM431ws`E&Jt`5Jsy4jDD=0I0FCL}ny5NAfT2cRjWUz<4O0IEc9aE<E~9AT>hHD)Um
zRTluwbnaNcbt^(>i)99!p<#+Y5Cz29UD^=5)AUJPqDsdRfjDMB)u@5$Rt)ymX1eIG
zp>73Mi&ZXh23Gg@PY6TkFKDZ?H1WcQC`my$*}_Z{?98%NKVsy;zjgynD2#R{aM@=J
zbp66sogh_u0$o#V)q7cGTA&NCZ?ZtwmA2|98Kx4i+=OPh)>l!P6zIyc)%-@1JMp^E
zR-K3RB3sSRBzZnUyL`7-4i0p^Xsdo0uXoz2zsAq6Z8Z-_k<vg{tF78C5eA%s-YLl`
z$k1-9o`#>3wwe`^Tp;nXF9q9SpW4H3l8<7yjFZyfS&z4F9z=lP>mK<Dq>1p!SLAb$
zj_LhDgZ!Wh`tdjNdNp`ZlD*N?Zh2KS6|?&(1FZdqKI6dyCiy6ED7Yp0`Y8AX4a`Ru
z<Ud4VPIk)~Q9R(lI3A1qXcXpkgZ!1G)a&DO0tTCOl=acM$UV`je<QyQ5T#hBN~2TW
z9Zfs=VI(X1+OEE~%l{gC{W+z{-^aXo7+))Zoi??iH-9PB9s^mTe1SnOm#W{k)!vLo
zF7c1@*5Py|*lq<kSpAb5J&=ue!c7Fj8S;AKop2jY<N{qQHfDf_=y0(t`Bh4O5T3&5
z&=1~Z#S3_!02kMm;=~A|@rx$ca~5AB){T5~Wc70<C1{E)5!7dbK{kRZN-9$Ufg`Kd
zJ!dTZ73f&^M6P?z=u5|xij&@Ilgno&fJhc0GDHT&(*<fn1P4)+f1ip1l4IzC<$ZrL
zFDn$ad=IX~P|Hilo)_DNL1F;b(Et>on}^V1?hxU{I7Qfgvtio7^$8>^4)R`yH@-13
zOtzOGbeu;cC(&l&?+DD1C}SuKSC`Q5*iDMg6y5wyG#kLOpbjpIt0nVkN+?Z?Qdm3F
zjCJfH1BVu#Kb(f|Z#Q*a44jmFiD=hmx$^=}eCZ(CTVL#eL9mU<5QAPvm+V>$e322+
zvM^=Qq-G+!eCbh;<p3d(A)E|vikLZ2pk|6}#qs8T>fE7t>#Zxwa>MV#BW%6RZLn2`
zncIk?MoGq&6EjJ;3cZC|U^%W1NocIQF?oH44?X(>*j+BjL|xDGbNkv+px@RAp<YPY
zB~qg)lHM#Q@SV(zl8!*UId+DmV3P8%C;JpTFr<BkwRL+*0!~nivM6MxQz|OeAWGds
zr4EdJ&!L9rPn8SWT9gw{WLlJP8ZtPEhQanyuy?6H2{d6Zdf-fC4V`ByS*EpMQx$5N
z>szm$D!eKRdV)5)AyE*-0+oUOc|j5uO04IoHwp?<^&@jdS@oXsSV__Iix!O50EqS0
zF3ZBVQKD~Tv{>I{g#@()7GcK;oZcXJbw`HqCadW27X`^3QMQq<4M&4I9x)J)d_X<B
zs}ngQBct@FJOcBz3X>=>-w3Q=5}C$$FD40|hWLyxsBMB#z5oQy5(J|>&(`+?qtsX=
zxV55Q4Bsz03vPXF)wVu5iv&qboiou=qQCtH?CefMsDOi?m|(eQ8LGYI<8IW6K81d9
zMp^gJI7_9|wR<5rL8$&>R%D#`<|CNEi*HK?pJkT7?~69}VFD8qVeRs)$StCRM@4Is
z-{A@%jFpc8GU@^fj8(!-mB9W~sevdvf^8^B{0T51I~~OoW0w-_n1$1Rd{*(In=*M*
zSTuS8N$h}L8SNeU2d6MAMLz<>Mqpzd*|UT@phX&4Qp|4e@ZCnWSE4d4moD&>Gm2Lt
zkttIrK!#NTvK_72Lo%NBu&ku9UYPsbtGFx*d{k<yeulm>w0*tT>9Yd({NXw3#PgAd
z<^cY(2jw^5tPJ8y-PRq5RHM}z#P__dPa?{%Z$lL;=POB%Jx)oXw`hk7E`tb#Y_u|A
ze!whfAWRswPZOe;KczinW0b_jQLiBR)O`^<zxpj86)2yfLSn*QiyBg=LPZ3w!xZIP
zQfYNdzCpx^|H2}J+&Jxjp1E<@|0s);(%iRF{`05ax`I@<!Dn_G{WBu{d6N^kK^i`}
zH)T^$NXBBK+;IkrQigyx`tEcm`0jwLkF7h+p&b|====qd84BLO7v8`FsrJe-SOIs>
zP37WS3w>$%_a9)><{$msSpOKTh1e!iEix8(_Z5&BF2EuKx$w<^+CYy0$2_9HwbOI(
zv_tG>-r3ehYfd|Fa!^%6`11WJz7YR~z7X^9X)t61P9Cr`!I4&|#15%gE7y}U0?ESf
zdIMDsR)tD>fQ2Tu+O&Lx(B_&HA5tLfVQc?|s5HM-eiWw}1zC*5+HS$Z)CD=mKUw>n
z!Jj~NAIEp*A{!5zOYkh<TQ1ngU=cXM%NoR*T<{^9Z3VF<vd4HI8WNaT=$O!fnGoOL
zdmv4HYNI3LJ>8H_PT6=E#v(B%zeWc$_u;GES`-^e=iyD1j5M6O(Me66X~?Nkl#4z3
z$D}=yuhdTRUlpy`Jy<E@75kW%{YF&m*C&AICNW;pK2ed?nsPZDmUnO3MGMKznlT&w
zY=>H7i}Pmf5n_cA;-ChT0Ug)u{4@1#c!;R=UaDapW{vP+G3ki-SWp3;JRjvZEC9cs
zjXXG+z<8~B+x9Qb{M=DKVlRp8(ZaP&21bPJgZ*vDidJjmdpgl-?Kri>)QXC|!}olH
zw)?9s+Na9yV|p_6cim$nXkLO-K)784)%J*4{5t8xDA^lW>q@>z<j_Z-B{(hHSt`hx
zE2^)20vjs9wF5bh@!yBJ4jjvO;fMnD$IN(K1NS~Yitd0F0~9aby)lb`1diH2L0+t<
z?|u+c)>38_=GOvdFF%JJRo8H|feKcP6Yt|PW+W_^^r4~&Q>;?rohVUIZXvY^^v3AO
zN+lBj9oZVl8)J3z-$>niW)swzzK)FIO<z)zs5KZHt7TP&T6ktQFM<XFJ`-%hNj(HZ
z5?s(k(Z-oT$Ac&tvJl3Y_9MwHV0DZ=tZu#SRHAZc@v7|9YbZKA>I1=qD*_j+zS7E!
zz=Z_g<VrJ?wZ=tO2QDP}CIl|@_b-i14qWK=4+57owDCVexsvg+SGtp#{L!tEJRZ(0
zjZKxxU_RP2!Ak~Y)tK#t(O&ju1bym3<24)=@q<)}Z$u?-hbT_91#5fj(=mUykl;U(
z&V$3%$MKH7_U|OYIe4Mek7HrmOGO56Ly-xLj0VKKV<!eybjE1DxxR;OoC-0|ebPUg
z?>vc&Je)xvbb=oTu&4(2XQ36Ec{o9&9W0C_De<qq1Pm<LV!Ay2W$bfH@N_9HkOP*q
z15eHCw(6s3@BMVDD7xQCyJ%Q`Mr4VL<oHEj;*o!m`UEOANQR5**f0?X5jbCpzr!X)
z9YV#F58`P2-MrYlSz^4YMb3zo=b<c^;rHUCn~H+2Oe{+ty~D8FgH@5<&2vqPz03AC
zKp98yR3@Es7(otJPBaRfj$z*u_|b=qksSU8BS<Sia5_tn^i910SmPx+8t7zGnFZ1b
z1n14$3!;@$UQ)81pF?*CpjGu#`UbSYuB<HLd=}MDL)sjS@RQ`KlV)JVH@Q|swULOw
z)q~uR@v#$Cri#Ju%U{vGCcfn`p++*)nD90<PE;H9>Ok5mQT32fepsU9B}jr-4MJj}
z_&fxbxMop&2*qcJ_a2G^Bj&cTlnPZOK;=>DwX`gZJB;ZL?Fv6R^j!!`#k-=9+9}P1
zJqj|8hoYdZ`Z-amrnUQ{M>5oJn@2uIvmd7dCW&IR<HcII?YC#S)T*@87qKp;0|d2o
zPzuf;Lho-o+HedjGN~`1x=KTd`i>=5!S;vQJAgO@nfEBL(uzF~M_AGxHAApD+NH7n
z3SqJl$b!xKz7%-J6E-lj3IUE53=w68?ej8lM8|<cZO>J%@c^FZqE-!MU{1v-#%J>t
zQ5}<k*jiT)eY6c-PY2`SN%U2ufCn#F{5X@{zRGoT1Z%C)y@tL5iBF!@YzLqr7OI2S
zAaVe9hN~2Mp#HZmEhH^gh&7-TbC^!?m12&_pIwCXQmR>WX--lFg*s2B+YD#QQsr<+
za%Ir+X!aF$@3+-_Pm(Jn68r9wY>)hmMecU@w^d&!RStB+9nmt$wzZzQlWa95l5CRP
zHd}Rp<c1f-T*;kmtGPjvvm}yl=#h!9?gc5uc-ZGdR7*E9c`&vyoAzLX4}~!#WwH)D
zEge1dnsuN-lr%U!u>Xm`L^8fg5{!Uyh#aPl9{CUs7v+7BqaLus8vJhNtuIK2^AF$E
z!A_%Z_AH#J;ZyZ#nsS?1s0Z_RotYM9BROS!6bqiv+m-q5FZ%-V;e(0*h;;GY7qt+*
z^nRggMMM(0P%mjM$Ozz(PV_jin4;d02(Lg=RzPTfMW#?#X&flKB9lU+A`U_rYbrj7
z8t>XoGdxMT)OYeT@2k5Vt>}VT8k!=WEcYX}>LrHC9CwMW`d9E==3Z#4{wZ@WwpFJj
zx?Q#!rzKM04%(`J$=nays_P~9YFmxfBG)oE8e)MF-CAp_&NSl7L<Np39{GEsY_z!d
z+NxI>ZCj@s-C<kJiA4D?W^Y|#CiVp>>yyAOcF6ssB11lTOg?77<4rvHTVc#ilDD=n
zQ-0j+-B)NwcYoi^o1PRq?T4?&!RS*s%$@I&<fju!7!0q&VlV$BkvDBqKyb1nZ%(9w
zz>58d756YY1g!Vlz4c2C-ul9H+LD^Q^$$9t`za`R?GSB+ozY3jzoen1Q5x;7-69g<
z1{#B+6{pE!2Nc>un<`ar6RK?O^!7cxr4hV^wnx2oQaBu~-4A)7DP5^xe*;5H#AQJU
zf&X{|CO4n~#wwYI8qlMly5T)AM)&+o`AIW<6dX?Ur4vcppfKhU73@XSO<JPFbTAys
zDpdLA-lUOG_g|z7+rxppDNj@`cu``q(M+fH-oPf*$@isvB;k|C#DIZxVL0^|$tX)P
zfnq^+c<XP8ezFq^w{4_H2%*pR>|VPl9xF7Rk-vUT;Lr~-N%~wut#pCVBQ3IG@4AzW
zNAO*?pOdh|Lq$${E^}>r3#CA%Tu3ABP_@1U=a$zgC(u%c1!G0#@!tCR>7#AZ63Yae
zH0-&9HfJ;HEZIgjfA))icfy$sB($CB*rVlqozrvn-^A<oZhHO4e`g((XU9RTNJl|0
z^t_DN))L7PEK2Zx^q73W2w@36^H5<hF*9xK2ky>f7v<lX_|@b|7mHJpHw3=lVZs{&
z>)<=TIz@9_p<UjNZH(wt@QP5HMyf%sgpwMDlhIavi&SZ+Q^G+w$SF**J#v9XGO*dM
z-beGSL=&{d;D)cT`9`_ffMH>wVX==zmPXNL195$Eas$pP>jGj!65Q{knp4WtA^~5t
zcYTGLtNZEj#V@c#(4kU?0RsCz>If5doHD$wsCC6ha9~}eV9g&>-CSkkO(tv<_^yN-
z0D06X%G;up2h9q!m%h9&HRWxKmKQ*I3Kr9BV0p}lEx14`EkZPCbelJ#oJk_dfUUD!
zVN{mJy1)uL7svEH9Q;4eHJtA{OESB1KoGtvTEK7=pkz0F57~2!)TnMFVV$914Iz05
z^aM4S!Wv8`|E@O8J5n@@>HEm?Dam*9Tv>eA7uc;u%l*9q?F0HH0=)_REWeDdoZ-sC
zOqe1!NZ!DMDMo@=D<F)&0>l%BXhWlw(@4P_Qbz1M9o1Ph<``;2nlh>ikO_*GM2zHH
zvfe_6Gf%UKUsP%c7apmil^PbWluxNt6LOChl^TLd;p+!!sMKOIMIaLahx{q_Y+w>F
zZH%_}l*1WY^+7D4)e0g!<-cJ22+&V8pwCA^cL4N93g{7lzJNA-Rz#)ah&}@e5_5=w
z<}M1&kDZhV9<ES6ey$ip9~t|-=fAG{`2E*mfAf&|l=+B`wec;nR!Qm2+fLMlM()7?
zWvk7iHWVK|L)VW)(A!#=#qgnxH~m4Wm=P0S629$-#m(Y&+G;*xk@>m-FKrxzVV%z0
zG};;T1jBX=Vn@WG8~y2kai9RPNEK${*C8f=ZO{<G=lo}(DuQbm4?2qT=a={gik7fL
z<NrZSslf-+2Ug;Q`FUlbK$Rj@+x8R4gC=i7p@HB11$G6k<lS01vx@E@6f9tZf*#x;
z@Z<6fmR-~lUR$6*g`P${lM19jI%)?o;|?6GUcsCGsFXDbW#P>3kP;g$Df|{`!zfUc
z;}tdQsCpo6%CRSSlM6NX(PFRrheHAw@-mL}hEPtp?V&T7*pU}sE$=(6*?eM48Nz{u
zvXo#69KxXJvde?&(J-Ky=cZ&31=RpF0aOdI<Up2h1Hx_i0{v;j@rEP(kEL{45+07P
z`VD_+K=Q@Fp`Y-kPl%9^a?}BBWBTTQIZdze;@s&7q{9QqvkTHD@Ih#Uq{yFQe?|-<
z_t@w_#ZrWN(ZNpxO}KTFB-EBdyYdi<BtZ_Jn}^2(ZfJjJ;yXzi%`t;%`kJ<XgB53h
zAm+ulr*+X>q?9P3T=^HYAA|2R5(TbAuhAA_u#od1>0oCHeY{N6OsMjWrT#9$_@ND%
z?WJXQ<(3S#y$~H@t4#geWcoM<y+7<5=<MNbr3LZC#tPSt>dRfJ+m28}Qp2eY`7XX#
ziH4<yd`GP!c0iCP!WPn42);UAvyX^>Ngu0-p$_+lm7uImwB-x?F{*wf&coyN6009I
zS>5!zu#kb@72w~!2_7sHwZ*wFCRv(lp@<*V`GWSGkdqdBx6O08_|Ch!s5NG|Mv{;a
z{uO4=sL%qn1FYYpq4N~O{TGG5m6BMy%HLDz<DK?yN-w#3A94AgJZSa?Xy@UU8*2S@
z1N8!Zs&Uw=KQdI_OsjOdR5_Z?6#mL8ZM3g=lF{;fI7$9D`q)?fF2gpeW_OZ|Z+})>
zb*Z7!Mti6)nY*8@=2uB_zJYd5euF#3R=vgG9$>3^EJ<EraL>RO10yi!+p1?6ktfYo
zz1iR%WUJYb1XX(XbZo<n?gCrQ+9Vl)nUMEQfGV_A-)wY4b6|dw>@&G%+p1saXWRNy
zlY0Ra_mkxJ@XfqaJF4ZoA?!VbGwgm1uc228@*{~#z(=28NY?NM7eZRkOcI}CWJi*s
zIf}z|;Y?2qa6QHqg;?OxPLYp$msN9-aMu@rH*xq9A7Xp`SBhjYmVP)TI;!evd=VSt
z^Dy53Mhr3s#@FI&@hHk8EHviU;S6K@9QuUjfRHj9o4l;USbF04Tm5OYVaGkI9XUWr
z<B`AB9_a_jBD$o}><!JtPIRV_+87BLp_!)0mEh*Van`NN@>A!dq;4qeHdzIeOAx8#
zGvYV^AAH1DootkVc5|sE)@{utD(aRycut!;5IBNQ0ab~C3x<t`-(zb$GZPZc!i+t#
zp>{t6wq|_A!_mf#r2A4k6FUM>$mwes)bx}RnT7ZlN5hr$)v$K8L*4>azI0I=J4&LN
z+$CaziPT=beO(v6&4{<d2)4cV`zLaE(=73xY7O1+rX?aq?$shM@TO7`V;;2*XQ3HD
z&5nIzz`c4S6dY$}Npc7D3Zk=TtAC8z=Sm;yJ6EIyMZempBdK2(&<t8cms;BJA4)^N
zrQg?}(nldWo~NZ3Z4+AVpz@4zAW^XJ{pgi)Q9o$~rk)kpQz}vON<?QTqJ!;Ae~o8)
zB9_o9g_5-@CF6(^V9S<skq_b>gW`?C;_?gxh@s`{AR{by1iHj5_ag<ti@^OiY>a2p
z#`tdK<LzlCH$jH-AdjGM07-W=t<QvV_4Y@dSYO1aysdN4tnMB^(UFNlb_kSzco-;u
zX67D(sTDA~_pBc8zh@TBT9O<?TPx7g4qywRg<_RJ3sRpKXd8cuYz1aMi^R%W6~=4(
zF}@tD5bPI#7(w?4G%JaI##Z5XDzyI!@PAL>O|Ocm^dE?Rl+c@{-aF5m5<!0-GsWXq
zc^jY*YI|uWHih-*RVaD~yE14E`9MMW1yFuJ0pk>Rd7wH?oZ+EiPqV<f8}L{*UDa>j
zUNi$-hm%inKbL~VSRnBo3_uGEG>h2P!j?nreh4ar19k&#bO#&p(MzevatqWJy`kwi
zhF9x_Z{6a=56GfPwB0PmkdM_IQL7qVh%ZO@Bo{&x^H9E>o{JnZuC9PcQhFywKKBv7
z^H|S~XptuIJa-aI;ea#<4fplAm7oBh-c1|Fswh!iT6*G@qWV)tLOvbSR2*(6@vR<|
z3Py7&uyIJ#LnKAXSdLN&Fjb^Rsi9jCI2<-nVlkbHTE)%RSq>GE`W|G4iqpMNvQN+2
zIDj@3gLyD)a7!fSC>_Z%aB9-3*#_5(E48r-H4X!gc&j6_A~W`q@4OZaO>_;Rel0T9
zigO;~h@ov^F@MvkbSB?Py4a%1ndo(ER5iQ2%>WKs(q<MP;`pvow36s}gMTzF0aGw@
zW5&i7%7O;OFveX-3t(`*Wk$%1QH(G2p#fA2bXB35qR+S~2KK?{JLLijXcjlTpS}Ta
za9VQ^^1_WGNLoyElW73vO?rdFsi*TrP?0L8i!c%kl*HfxYSOeBagb+<M7S{pK(o|j
zY`~OusWafjn@{Ikx@O~*{|rC(K2A?^{zfHIis+gA_^4tf=!|L6)+ToP%kCa<d1(5u
zSerMZr)#G>V;v0%2nj1j!~j&L92rY!ET$Y-_QbfrNGhQCsCaxf#Yd}g8u7I&#>6_y
z^v?6tcS`0;aWYRjuHuC2#Y4Q`fjwcIPPXIBixfk}@LHBle7SB?4CC+efpb=T+%zts
z67k6-Hd1S6MMsNLzIOhpT`^t@x#DVFY=SO!jT#ff2EzJKF>L4~O6V>KBQ&7_f=;fm
zH4TAV>ShcXrgT!U>k9wpF=Xf}s&js9ocPf-{{p^x$RQS)urkqZMrtkQ3njV*Tq;C>
zh8AVfGDkLx1;_~RUS_D`&xj<sO}>$Cv;W%2l{no|kc12jIu=b#oGr8OBQ^y>g%bNQ
zVq+mjD6yX-2K6YHh)GW&2BG4p*d9uMpc72J!1wtHtwgCRP1UwR&bcYjWwSl<G)Y{0
zG1A~c6Qe58_6UyNNd~*Sc^-XW*|N7Bh8KLBp!bnAsFFT}?w*^ao@9{T$Bj}c^DooZ
zAhHUJ@Ww$9JDhG?WdR{0^q&JgcH|_C*eb7%rhX_2tyDgaqDWeTsX#KL0Y)P&64RFu
zixg@H8bP1XEIGkdLmjQS1mN%ns<P(VY8J*+u*8U{e<0c0V5S~lW@#LVt~8LITHOyx
z%v4_#5vLbRO1h8*l?+O{famo=a%8J6TFUDM&?jgMBWpgs2#OMlu(o`JsRN6Tq73&#
zY}K`;V3Ib`oBAJKsechFPEyjz+i46NVX`Xe6MCm7E9oSyY2a&%#hvN;ACknTOHWbY
zg}@%IEs>q-4Q$S2eiWn3bR-<}rhs52_B?uPR#Z$<nsaWl5R8JV5WP@|QLE+c^-rP(
zN~2vlux1U~hz})Nrc^cf<kAml!z%Q`<g30QX$>nViQdPE>!3RkeYq^AQrd{wPwefY
z3Q@&7omc=Gj$)_Z*3jM%=AWH^C7l)T%+{qM(Z<Fy%~`UgIeL~1r2^zb{-aPXSiwoJ
zgUO*AZ~{`CTy}f2x2FP!A3YULkVF^8>MLliEu$~eD`=$!!{M%ey0^iDc{+UxBA(1Q
zpCn5L*b<l#56wdAw)AapHN4MnqG;w#-q0+UcN;SB5TOha$`GLp5z0`p1NDFg1yy$x
zM9_c5;Wup3?8MO~BSkhh^AA*2Au7;IWqaq@nEc-Ln7^Vh=)+U@L9A^!3aRjV&%bUq
z?)3btAW%6#2pyGIpWsU{8b0Aq0yWuASZp3fb;O{f6*@e5IC_tEe~K6nL1%a()F5s`
z)qcTO9pp=}vHXV!NWVxR(B(tRM9ag+&81MgSdMaWoR52BqB_v@3LD|Fn1?<<#?`p)
za|>8R6dZij^oxVg(}TYAn-DCZ_GsZf<6W1-2SmF*>gnl?#k<esO5W=YmLt0t*@2b+
z;$YWBo0Nr*5zHo~h4F*W5Gq>{bF}>tmZaHd)X)|jV8mNXX#(^$Nv$N?*m=)ed{va>
zHx*b7rNjjar6N<N$OM(pcFK1t$#3$qxBdive6dH{;SGb);is<CCf!C!N3OfP-_eSD
z?s2ZUt-Ra`51cu|E7|{9f2tfVJK^2x+EHuC$s*jl#uE_HxP8^TBE7tO(R=RoZ@9yG
z=lc8L%FGA1f^c$33FPh)9sptU`&zg^^JPzSDz2&4U+c`DcYU_@P1$Po)!1>@I{k`w
zR406At`lwn$<3bPEiShTUd9B%*vrw*+cvDZ^G*Rs4j8|8$NGEWwlVI>F<z}$np(5}
zsm?z)`24pk9fbb4q>}&hJ%Pf-r|Qfz=IL}ToU<)mcjrA7<#)g#oAB&f=J&0I6I^oT
z3+Jiu!YMrBRjjM%HCQyRHY?$r_5UkppL(~QQD>gt!UZV2?X6pT`~9rMzo7!o{8))f
zFvD1YMb<L-x+7<r*E+d>-5TNekXm58v*I=s2B*02H%cyPIUI?u^OC#E|7t$?rPE|Y
zyH0|`yy)Yf;hEr^Hyz#tH3*V09jiX&rcREBVN@`do~=pG$%&`u5R8}%R_9D!1NU>V
zFRhOQSo?m(3SFE~Y2On%ZG2*{_@rKOs+JahO0V*#z{<7$Jxb8jXNtZ)6pPWELod~K
z$(f3D?;XB*6~25pJB-6j)xc2Y08?=9J$jf)8kos>6RC<ZyoifJqvcG_n-Y6>8+ss`
zep~h=O?a{<tbqrnHSqK2U!5~?((RfuCUbomxl|*~dva{3kL%wfMvM%!B3%s&I&Qyh
z!<}nZ-?nDW9UC?PMHEi(OB60olRixoUZV-GjfZonE^1!EYtb;ZZ!}CD9}Q25hbIw3
zkptCrYwuVat(FQmNt0*NWYj*E4kn3*bK~JS-IKIsXy}=wp=Z(^8a#Kv5@!_W9q7Aw
zcuG7B{A&M}3xB1n2`bhvlXQJDS<ff8-JYWzpE(q#!4l&a#P86@Mc?(12rmAdA3%*d
z_9tAJ{QONOet)R^l1_>eSAT#0eKr1lHkCC(l2iU9JN<Tu$Zrj!45>qV%D=W*7BV_7
zR{spxBJ^Wylz|n)y}j~__+W~ss=qFF=sgK=ICdICzj!}}@=-j=G1gs7iUYB~p%VSW
zZ3vcQ7=gn8R>fGZ(PLyrc0XeiO;=Fq-(zf2f-3=`2N;`d9))8pwu!MRiMJ*WOJol+
zHq|nkPPsN?Z`JQg6v!T8Y+BM-ni2zyW%nP~AE7ObU2R=$9d2b?8M}VKRdg{w2#fp4
zmgI-%RGamKY)ik4-Dh89Pq8z*hgGI5PZ^xTQatRA)WXz+RF>*t>jy3#m^zRR^e~@e
ziNgU$Lmqa2+D&O0X)Mjd{DYPbN*lxmdDxwUXAkZ-m<{%@d(#)D+tOLOhgD=0XV^1X
zhKH>j^1zUxba=~d8T#PRtf3SdkU1bTNqirrnDTequ>4`tFgDD?HViKrK5#f2?qTr0
z>NGi-)5G|Pq7mj1Y=nn-N6s9XIFgO@u(B&=U17O`UEyJOx#qZ%T+HQRcaNGos{bf9
z%EQV>&l_zW%|?6Jbz`n2bprg289Q>U5-J_Hd7Ki8KUZC~>8i}DDE__iH;*4Oo{jgg
zs;gIAoqjdD+QZgND41ZJz$SRu#%q>cGw2$2jfdTyJw4ly&9XggUCx4><Q$gcVfW<D
z&mEA<ay@MPL^m-x{w7SiL97LgT{HPcu?i^Z%Ja&pSJH&7`*TiH{^=60V@uertPE*x
zwv?@AcOrB>TgFP+T?pO4mb2R!MkKqDtzfsaa)dnWCbov%gHS%Z8Ln&AAvB$>WOuN8
z5h`G-7^nRVo55~jUUnZsef`axI+Im0=45PE-Yfz@X!f+(teQes&$)UIrQvVxq`7Q^
zcsp<MJW6mfHh;=|=A+P63$9u~Y4}^1vyl14+v40}N^ml^XyPKaQG^y}FILk^CX}cl
z`swwzYT2e`YElh*goRi=Vh^)gR>!tQL0!e`itQt!F?H0dyx##^P4PFHkQBgR0jj_R
z4E0`rmeS4>w{@Plz4OGHP8@zRdn|$%5@YGg8wCo(+zGH)7EESiV-dW-kk8iUPheT>
zN|wh~wr90ZVR`MV+M}fpW7%v1S}B!{U?bTTY%p`NQEW8JWjQRJWk8p0AcMOoHi%ur
zQrOijjg5yRCwL8F3CzqAK@NP6!nq6_3bJI7J&jq}05*gTWyJ1dFl&ut6WJs-nO)1S
z19M#uX1Wo~lMiMo0COw{LrrZjVp%5_x6f>!-CokZuzgYc{Pwx+#qG1&3)$rMsca5g
zz%ttxVuoDA=CXNgKAXvAvDs`f6P*|(<-6bSTHw1D_^t)MYk}`t;JX(1t_8kpf$v)2
zyB7Ga1-@&6?^@vhrWTOrv}>+T;2s3*R%PS6b}LyF_-Ze{)`xR{j*r_n@zud@TqJu*
zS`Wjl2YQ0txFa;cAb*WpH}!L&7*JmTRT6RU0xlMkp0mKn*DGtu!N=|u<g&raU-5_-
zxd|bo05vl1thYn+3U_LA@HF~v<FjlvizQObfJt@LzXfa-jDsFeH=*)nBOtI{p#Uvc
zf#BhSfO-T_e*_4~R<llmfoP}g;ck@lnNwb^qP|swx+RJl2HFK`Ka9{`a8|-n%5l2q
z6LCT_fi!J-Jqi=Qy26l66h_&)M7Fmn+h<PPy|D%V28Ewvbo(iUtM7j`!F1u~4KOeR
z%ea3$9KX#TykM&|!<awVD%K)XM2k51EdO*e^B|*qaZ9BGT35O_5C6v#q<bLjm2B3%
zgC_S6@Gi0t+G3G4z%bW9dSk)!J-($es?t<fJCPCM4y$nYv)@l9h7@WI5yiJm{bD$g
zdE0*sFHl&7bVv#eJUr`h6b_`g?)PJz6%?|kQI`5BGywu19v+BGUS-x!L^gb=;WpUI
zY4tV;4c0O!lx#1AJ`=AO1_M@*mWdmBEV#S^v%})P33Pa27GkeZ#)Wb|ub&RbCN1kH
zptGjExgH9Cwik=Ch;4C!5p4SaRgDZ`G*ur!e3yj7YB@y8MO4aCapi|>IN-Vq_#HNq
z+k|QZ)a%Tobwx^4^&Y7ALPa8e|0Q~Vi1Z(j>5>aWXI_e37*g>pP&8dh?Q)SJaOh#R
zI_NOE`(njSRj9aWEdZ76`5YCU1A9Ebe+7a36Y_892v7H?>W>9aL(8lcBMUE8J*c|k
z!Ofq613wb(CK5?`s_yZh;(aa5c(f<x?e$%amY(NI<h%X`j-&1j&uu~_VEzW?8b9vz
zCarRbY_%dAlvuNH9lttJxyQe{(h7ane7c76Qz>#I>@BUP%O>@be1f@CZPimH+!Vp3
zlfe=$oz(c~y1x4{y4LT0+E!gBx$m{rtd`^jbjeRXFKz{bd8i@I{sxz|?~JLy;XcJ+
zR9fDG`wd0HA~o(>F32EGh+S?3-=T|s79ip=GV9}(0>3vzBnTsc(+#*FWh7OjoaSj4
zd{@V`!szA_v}cV_Cc`Zd3K|g9nh9*g{Lz6c=S7*MXWd$qnN0=(sPz)mi<;DW1E>pO
zQwG;|g%g2iiJ@Oy;xa?U6n#%Ot`g|dMX1OwG%a!bO58})nR<AW2y}Mympw!WYKaSK
zb@?zCT9ip6vTjkj_}TIk$|ej!esosc;ehG7Yf-7JKx87R!dd*|DQ19`oHBgq!GL>p
zKRuOObnAXB_zbt`(AIyZkwIE)LX!;xHGbWS)O&Py=j{LOyK^7^AvP3XbonaWhG=rr
zK#X0Vv;RM$PFh3hWuHHRW?68Y$<4<t>>`tV)G9QqweVeGF|3EvbO%i_rPH4ph(Od~
z4T8P?U@+&$KsfHWhC~b*SRE7|0WP(IObVLkPEv7XwaExGk;3T!4DH%p-2e3+$+r?_
zbuo0wnhm@Jv`c(i*nbV#m!-=Mdn5ipSC{XuKv%ba2zlz+_bO^1{yPj~K`9J&F1t}b
zcu-qJuryPh7VqDp_rX`KIs<VU2MhMs2+MB>YBgN~h}aZUh_V+g(FK&6&J^=*$|oRt
z(y<uPp?$D5MXczN$b8?&+F^DB<%hXhs40qI(-%1Zhjoh6m|5a35J(>uw_dHhUkiCY
z*yTa4hP{oWkc)zPzdO*9^}}b{DU*LnFShnz@))VG^$k$s6&3*^Cox++6z|g7MK{p(
zPMC-i?s{Oxq7D`<Va>gW=M(#eKFe!cAL#?}=zoqlyE&4Lp$iJhj$!D17|*$Y>XQeB
zAej$5^TL-=gUl)sF+XvlVJp#r@^6pE8WtYhh?`V)R3@b9;trZH;l=B>lJ>1wSDd&6
zoJyBAp{EY}U9<*mB`sSrH$=u=U|U{UmTb?r;ST0!Li0Z52=WRS2v`SkT@&}4No$Xc
z|BI`*-meRp(N+z=CAi4xl4$0^Rf}Y?rX|o7R#7wtHB=-WJbZ5>SO`mXO$|wHew5vT
zt~dVPG`0oI0po7)-DTgL;H`uGA0!;~@^MfTgynSDzDG5%Cf7fR;nNA`H#Ib?xoP=_
zWrltz6kyvMsaP@%hb&eX8Np80*xC_Dr1^ANwZ$vZ6=G;bI#8P+F6f}PxanaxZoU@<
zk!IqaPO<)C5Y`ux#wqkXqoh3hTPSOS+9kNN3C}8CX({9rQ1%-v7?d^Gei7K#0vn3L
z&90A7H)*M*ISk7Z&=1eStyKvndwB{9#?qh^&3xtmwU!)(;%Ujeo}B4`3SGO{UOYf;
zChX(w7QFz2O4JI+$>I>oe_K=+i--P_Xo-FpUEd7W^yR(qRij12mm(F82AhO0tCz{&
zl`>k7MLAc=_gR!Hv4$wFrGf_nSl~n$%E(Sk8W7Qn@O@G4_pXMc(aTr@=oWV9U8ugB
z>Edat!9B`W^9P9e+aXlvz&%0TEv%MQZwuPo{VG%W-EYIF&~9+h_9cckUKlwMxKQp-
z<b?p7&jRNwY}G;b(1^hKHMVNA;UQb#{3zd;!1)Qbnp+L>062SEYpYpeh-3uL`+YYA
z&R6-$0_Qi_YVr;8a6{uLc^|Q>4ZDW>t&LYJt}y8;3J>ms6n6mcP~Y&R21pRk0&@Fm
zVpMX5LCIN2CU+vC59JF|BSyag-!soNR$&su*Hf?@A%5FGnQu8yY8jP@nA~5GBEnk&
ziHEyL&jC&|@Z1PB`MnsM@ZA>d1dAQRtPR`!FpKjLM5iu;t@<Rheg9>~=lD~|2tcsQ
z?3=Zz48MuKVal43iJbi)?FXB)X`j%%JW7pNQPRP-*hu^X2wXw<ClJK?{}_j`t@aN~
z0e$}j2kQP0A^Lhty`{81`XhodzI`Ee6eLjtb&2StHzUizGB6MpI^*8ppG&<H=?~FW
z1<Ci;WmF%>JtW{le!mnMOCZQX$!OMnrpVJ8@W@{qM@91%$=Tmv4OV0x%;xCTvQrUo
z|A%kK#A&e8KH6F6T_o9ldyc;%%qL>L#B6u&97)~qCnr25MI92wTqDID60MF(SYo`j
zXw-OMt?zLZ{pj0}ZK9Sn>25j<G#XH`og@|V@C*MTW*OgL+?XL@ZkLJUNrn)f`#v^y
zumeCAdTU|p3IQVmDP;ahG4_NVyBOfV{~5};_!eVts$$fPgM|7h5RgPrf=w9RNqP1V
zFIxmAm%n*yC+om0wY%*E;Od7x`XTv)#oAM!jQ>T{W6LbIY#wa2^0~N(-O*#V{26Ad
zP~rbq{xmZaNp8X<6~^4XQe_(M)2&@UmM+LQ2;<kyX1R@#O`BYUZR?W~t^-y7-r)Wn
z?!ud8ILdAEpn?sw+S1}%QXaeUOLm`@I>d#Lf(jTc$s{1`D4woB26>*?4i>`COFJfd
ztiTS4-%$w&n4Td8mIl?pipY^>=HdOnQo0WJ6lc6nT?ds0CSPf84A6xL6q44sRSl&#
zRx8$ik(!}c{>A7bQ&$c-3481ZRa6tm{&3^yQ}^{YBXtt{l-F^~`_z4n+Xz$RcJV|>
z7)ohKMM(&yBZQI=$~bl3@9F^$*xJ3A$}y`zCWKLbNMfaMaz(FT`t&|w&IF$PGUb^G
zBFw`bzl_mUEa;;9Nb=%@#t>mcozoj@)lgdFBWlRe_<|b34i1Kl&YNIaK}B@^x1)+T
ztrEqSP_f5NRIExGidD%)u?RUpE{avijW-$Wcs)dRjH$U)`d}=}Yf>7%wgrL}G`^m5
zl1-g5QIwyGsz8;${5OU6Z`%=DVl@kj5OqXNv}RN;njeDwK_|7j{DCpvH`Ecr)K&ZH
zSZ$YP%1vZ=C=(m+>Nc@0w^eUvmBMt>FO8AOWE$c;gC&TX$Bpvc5}Af5C({tv#s5`;
zvAvotMtLxqgQ$MOKt}b}8|8yo*&#uih)FT8;>-mSH^x9D0UkjR3g1Fo#+v5)JJ4jA
z5(%GnWPy-o;<Ly+Jem7}5g12t!EC3TW~6ZftM+?Ni4jwX5z|UZWR0fJVkY1vtZw20
zCTRf%qV9QKxXAwoS2_?RU<G$0Ux=#Z(_R2ZdVh-gKypTvUgb@tG^Oo&7}{y_?@%q2
zje_bQRP38vO4N1n(jWrpOQXdd{-q&Ie(f{y1(8H=Xue%8AjwB9dU3qymv~c!QuJID
zJq0G@=A+>b!XElXkioa$9Scx>3h9^$w@X|2?oKP-V9JI0n$N+DXsYc$xQH~^k1tG@
zk4gUx98@`h<8LqtlrH}SG7!uk!NliDr5fO3eKq#*mz8Slr^XcCiy-tN>&kCkJQxvD
zOPq`|u)+9kNg$&}z!4+kbNL9k@LQ39?k-FRyL>J`j?0cu?WeU1_UjZ;7IHcUb3pXe
zmTL6WHi7;YVf_dPN4Ox5`{%gVosX%0`>b{{iiG33{?iU@fT<THU+9O}xi3}T)IWfm
za|BXfVA^&78zC5#0}A+l4z@ZG>CtR>gq48lWWNpm+F%??v5+*LH$AFU=Q-jA*x-8a
z5iIC1#o-fE&c9$Biez&w_?(O+#l#k2_jmWJbQbbYeZ^Czmcw>BeeF2~x<?#1`{+Sl
zwjh9T+JVCv2;ccjg!>)Ptg_=F1EJlpv7*zqE71`zRzTA5VCtp~Q{C!x+BgSK-iV9A
z!U|CuHiF&zt4#1QE)HR5ibL20aa!~BR#E?3cvFWUOju&OU)pl22d6eZ*H{Q!sxhR!
z5W#!xqs1ZK3*x3IU<WDDm}R723*#PSuHmk0y`gd!ypPncCkr2RPkOuK7hrk@Pi-_8
z;Rp^>&|V6ya;15%TjCnD!7}aa2GcZo<1}>G9$t(m8BvB)4!Q{mdm4g>>je=xL_`pW
zv{52%MVtMB7z|F1@TG)Kk8Qu*i{B$SMaIuN6h$TGNjMzG-X42rWiG<XLK7@*amUOo
zEx(MJCB>9YDzN-xGfStmW|r=KDr#owOEBaT*x{{Ro*6h)uGX9mo$*!Rr+@-IT7yev
z?NINQ-`RIKjpi)nZ}XOa+w!L;wrt+qbG)bJ)1J-c-QC@r@}P#Dw@LiwZOWsBO?D+=
z6VyuG?sU>>|Fi}0J+NpteL8ouo|Y&6^rt6UdTfcd2M--ORORNJyVEzP-#GEc?Cgq;
z_J`Iyv}TR>RPz%zyFdNZee)B6_Rj9k_5d>^-_U(SvH@5(r>Adrrz0EZPy~MH`0)pZ
z4jsyFSd&*?o_DB<YP)&!W&sDV9s!>Y^=|wjj%r!Et@vTtrQN031l`=+jDsBJ;yv7j
zUt|y(`8_=XoFM2gyQ&KJ8M0Y<IZ1d7zuov(&ayW(S6MrOsP#~KHg9El<#`)FIJA+K
zmNpBx^z72o((H7G|LF*0pt^h95ZqaI_C;~MgP^kM1x`4le|TZG0=hZCHnqNS;_FkJ
zSat>7{JF@g4q5X`4=KM^kelf)Kh$j<#x6E@S}C4a+T4j|Wfu<t0q|5ILUBAcS<@kr
zQlatxrBn*lPZW<DAWS7wIq5|2rq&ZDPBd46{zHc@9y-J>a=wZ4i|9_Y8~U@e9Q{z<
z$+~YZt17#_Tlp>R5bxjMH!$=uvK?Y*J^WR%VOCTV^*P1MtIGK))`8}^op-a=Gu_?q
zwzjg?Q(vEW1HXCYt*x!)d7`{h;6w3;KB$5vOq5Ugst&bRWD=c!Q1Ie4{w`8^K%dQ!
z``zv{zy~D2Md_$Q73*%@mY$39s!(oeX%!>lt!4wOA_hsX0zU&d{@0T&+J+LUteeoU
z?WLul{{xC2YDW2)RwN^x;uq0QdF7=bsRQwi)Z(4(rR5tr>YL3f1pQW~GyuHZpaD*a
zRH_$aho}MY+es7%eAG^ieE^CHp};o`@r_*I7mUa3*_*PnCsF@VHmV1HKtCAr-R^GU
zRWyJg3F)X0`uXwfwHH}tc6NJqb|#Gr@t-0{VjGDx`lE(u#mCaJizr+EvIVE!<X&zT
ztd^AB^(y!{Jmx{n94jK$Pf9UGHuLaTKk4aF_O^Iib_?wve}HKemxyC`zdw1*3iGat
z<y1Te;jS`ni7WO~`Dd_`3a#(>-DPnleg*dCy1%h&#yN2fF4s99cLUeocK016_i~@J
zWJ3M~=koP;`fxGHdHem&xp!>5bDeYEZI!-z*EvT!ePwqzr{BA#Y=hHx$8GmafPmPB
z*<3yuIGlcvx8R;~Ayqe-++*zWpg1yKw1WaTqs~%n89l8;@hMw5Gv=e-#QQV7c9I3<
zn55zMU`y9;q2<0&@$6Pm!9D5@l8y}2l?~g)P#X0R55KVkO-YViGI2rtX5kl49LXIX
XbdY_vvYmBgPq`*{;x*HzVUqY?{>O0J

-- 
1.6.5.2

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] [PATCH 8/8] debug: enable bios messages
  2009-12-18 11:01 [Qemu-devel] [PATCH 0/8] option rom loading overhaul Gerd Hoffmann
                   ` (6 preceding siblings ...)
  2009-12-18 11:01 ` [Qemu-devel] [PATCH 7/8] updated seabios binary for testing convinience Gerd Hoffmann
@ 2009-12-18 11:01 ` Gerd Hoffmann
  2009-12-18 14:35 ` [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul Anthony Liguori
  2009-12-20  8:38 ` Gleb Natapov
  9 siblings, 0 replies; 84+ messages in thread
From: Gerd Hoffmann @ 2009-12-18 11:01 UTC (permalink / raw)
  To: qemu-devel, seabios; +Cc: Gerd Hoffmann


Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/pc.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/pc.c b/hw/pc.c
index be70f50..18d958d 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -46,7 +46,7 @@
 #include "elf.h"
 
 /* output Bochs bios info messages */
-//#define DEBUG_BIOS
+#define DEBUG_BIOS
 
 /* Show multiboot debug output */
 //#define DEBUG_MULTIBOOT
-- 
1.6.5.2

^ permalink raw reply related	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-18 11:01 [Qemu-devel] [PATCH 0/8] option rom loading overhaul Gerd Hoffmann
                   ` (7 preceding siblings ...)
  2009-12-18 11:01 ` [Qemu-devel] [PATCH 8/8] debug: enable bios messages Gerd Hoffmann
@ 2009-12-18 14:35 ` Anthony Liguori
  2009-12-18 16:34   ` Gerd Hoffmann
  2009-12-20  8:38 ` Gleb Natapov
  9 siblings, 1 reply; 84+ messages in thread
From: Anthony Liguori @ 2009-12-18 14:35 UTC (permalink / raw)
  To: Gerd Hoffmann; +Cc: Anthony Liguori, seabios, qemu-devel

Gerd Hoffmann wrote:
> From: Anthony Liguori <aliguori@us.ibm.com>
>
>   Hi,
>
> Option rom saga continued.  This is the first series I consider ready
> for merging.  Changes:
>
>   * pci roms: will be loaded via option pci rom bar.
>   * non-pci roms: will be loaded via fw_cfg.
>
> Note that using the old bochs-bios based pc-bios will stop working
> with this patch series applied.
>
> The last two patches of this series are *not* intended to be merged,
> they are just for testing convinience.  They carry a new seabios
> binary and the changes needed and turn on bios debug messages in qemu.
>
> Seabios patches will be posted shortly as separate patch series.
>   

I know this series carries a good bit of risk but I'd like to bring it 
in 0.12.0.  Because this has a guest visible change to the PCI devices, 
we cannot carry it in stable-0.12 post release and I think the 
functionality it brings it's very important.  Otherwise, it's easy to 
trip up with using multiple nics and extboot in qemu-kvm.

Any objections?

Regards,

Anthony Liguori

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-18 14:35 ` [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul Anthony Liguori
@ 2009-12-18 16:34   ` Gerd Hoffmann
  2009-12-18 16:42     ` Anthony Liguori
  0 siblings, 1 reply; 84+ messages in thread
From: Gerd Hoffmann @ 2009-12-18 16:34 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: Anthony Liguori, seabios, qemu-devel

On 12/18/09 15:35, Anthony Liguori wrote:

> I know this series carries a good bit of risk but I'd like to bring it
> in 0.12.0. Because this has a guest visible change to the PCI devices,
> we cannot carry it in stable-0.12 post release and I think the
> functionality it brings it's very important.

The guest visible change automatically raises the question:
Do we need to do something for -M pc-0.11?  Like loading the pci roms 
via fw_cfg too so the guest doesn't see the new pci rom bar?

Oh, and while thinking about compatibility issues:  What about 
migration?  I think we have to save rom_offset in case $pcidevice has a 
rom bar, otherwise your roms are gone after migration.  Which you 
wouldn't notice until reboot though.

Is 0.11 -> 0.12 migration supposed to work?  That could become quite 
nasty too.  But maybe that is impossible anyway due to the switch to 
seabios?

cheers,
   Gerd

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-18 16:34   ` Gerd Hoffmann
@ 2009-12-18 16:42     ` Anthony Liguori
  2009-12-18 17:03       ` Gerd Hoffmann
  0 siblings, 1 reply; 84+ messages in thread
From: Anthony Liguori @ 2009-12-18 16:42 UTC (permalink / raw)
  To: Gerd Hoffmann; +Cc: qemu-devel

Gerd Hoffmann wrote:
> On 12/18/09 15:35, Anthony Liguori wrote:
>
>> I know this series carries a good bit of risk but I'd like to bring it
>> in 0.12.0. Because this has a guest visible change to the PCI devices,
>> we cannot carry it in stable-0.12 post release and I think the
>> functionality it brings it's very important.
>
> The guest visible change automatically raises the question:
> Do we need to do something for -M pc-0.11?  Like loading the pci roms 
> via fw_cfg too so the guest doesn't see the new pci rom bar?

Yes, we do.  We can fix that problem as a stable-0.12 update though.   
Right now, migration with pc-0.11 is broken in other areas too.

> Oh, and while thinking about compatibility issues:  What about 
> migration?  I think we have to save rom_offset in case $pcidevice has 
> a rom bar, otherwise your roms are gone after migration.  Which you 
> wouldn't notice until reboot though.

It's really unclear to me the best way to handle live migration.  The 
rom_offset is not enough because unfortunately it's not stable after 
invocations of qemu.  I think we're going to have to actually save the 
some contents with the PCIDevices.

For 0.13, we need to change the way that we migrate memory to fix this 
problem properly.

> Is 0.11 -> 0.12 migration supposed to work?  That could become quite 
> nasty too.  But maybe that is impossible anyway due to the switch to 
> seabios?

In theory, it should work.  SeaBIOS should not be a guest visible change 
because the guest should not depend on what BIOS we're using.  While 
it's probably debatable about whether that's true, what's really 
important is whether it's actually functional.  IOW, can we migrate, 
reboot Windows, and not have Windows freak out about the underlying 
machine changing.

If we can make the migration work, I suspect it won't be until 0.12.3 or 
0.12.4.

Regards,

Anthony Liguori

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-18 16:42     ` Anthony Liguori
@ 2009-12-18 17:03       ` Gerd Hoffmann
  2009-12-18 17:12         ` Anthony Liguori
                           ` (2 more replies)
  0 siblings, 3 replies; 84+ messages in thread
From: Gerd Hoffmann @ 2009-12-18 17:03 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: qemu-devel

On 12/18/09 17:42, Anthony Liguori wrote:
>> Do we need to do something for -M pc-0.11? Like loading the pci roms
>> via fw_cfg too so the guest doesn't see the new pci rom bar?
>
> Yes, we do. We can fix that problem as a stable-0.12 update though.
> Right now, migration with pc-0.11 is broken in other areas too.

Ok.  When it is fine to defer this to stable-0.12 then I have no 
objections to merge it for 0.12 (assuming the seabios folks ack+merge 
the seabios changes).

Note that I'll be offline for x-mas and newyear starting tomorrow, so I 
will not be able to work on that until January.

> It's really unclear to me the best way to handle live migration. The
> rom_offset is not enough because unfortunately it's not stable after
> invocations of qemu. I think we're going to have to actually save the
> some contents with the PCIDevices.

With hotplug this will become a issue indeed.

>> Is 0.11 -> 0.12 migration supposed to work? That could become quite
>> nasty too. But maybe that is impossible anyway due to the switch to
>> seabios?
>
> In theory, it should work. SeaBIOS should not be a guest visible change
> because the guest should not depend on what BIOS we're using.

Indeed.  In theory even the switch of the option rom loading should work 
just fine.  After migration old bios and roms are still in memory, the 
next reboot will be the world switch to new seabios, new roms, new way 
to deploy roms and everything.

Lets see how this works out in practice ...

cheers,
   Gerd

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-18 17:03       ` Gerd Hoffmann
@ 2009-12-18 17:12         ` Anthony Liguori
  2009-12-19  1:48           ` Kevin O'Connor
  2009-12-18 17:14         ` Anthony Liguori
  2009-12-18 19:41         ` Sebastian Herbszt
  2 siblings, 1 reply; 84+ messages in thread
From: Anthony Liguori @ 2009-12-18 17:12 UTC (permalink / raw)
  To: Gerd Hoffmann; +Cc: qemu-devel

Gerd Hoffmann wrote:
> On 12/18/09 17:42, Anthony Liguori wrote:
>>> Do we need to do something for -M pc-0.11? Like loading the pci roms
>>> via fw_cfg too so the guest doesn't see the new pci rom bar?
>>
>> Yes, we do. We can fix that problem as a stable-0.12 update though.
>> Right now, migration with pc-0.11 is broken in other areas too.
>
> Ok.  When it is fine to defer this to stable-0.12 then I have no 
> objections to merge it for 0.12 (assuming the seabios folks ack+merge 
> the seabios changes).

Note, I also needed this to quiet things a bit.

diff --git a/hw/fw_cfg.c b/hw/fw_cfg.c
index 0492f5f..fe9c527 100644
--- a/hw/fw_cfg.c
+++ b/hw/fw_cfg.c
@@ -309,8 +309,8 @@ int fw_cfg_add_file(FWCfgState *s,  const char *dir, 
const c
     }
     s->files->f[index].size   = cpu_to_be32(len);
     s->files->f[index].select = cpu_to_be16(FW_CFG_FILE_FIRST + index);
-    fprintf(stderr, "%s: #%d: %s (%d bytes)\n", __FUNCTION__,
-            index, s->files->f[index].name, len);
+    FW_CFG_DPRINTF("%s: #%d: %s (%d bytes)\n", __FUNCTION__,
+                   index, s->files->f[index].name, len);
 
     s->files->count = cpu_to_be32(index+1);
     return 1;

> Note that I'll be offline for x-mas and newyear starting tomorrow, so 
> I will not be able to work on that until January.

No problem.

>> It's really unclear to me the best way to handle live migration. The
>> rom_offset is not enough because unfortunately it's not stable after
>> invocations of qemu. I think we're going to have to actually save the
>> some contents with the PCIDevices.
>
> With hotplug this will become a issue indeed.

Yup.

> Lets see how this works out in practice ...

BTW, the following works:

sudo x86_64-softmmu/qemu-system-x86_64 -hda ~/images/linux.img -snapshot 
-m 512 -net nic,model=rtl8139,macaddr=56:54:32:12:34:56 -net 
nic,model=e1000,macaddr=56:54:32:12:34:57 -net 
nic,model=virtio,macaddr=56:54:32:12:34:58 -boot menu=on -net tap 
-kernel /boot/vmlinuz-2.6.27.38-170.2.113.fc10.x86_64 -initrd 
/boot/initrd-2.6.27.38-170.2.113.fc10.x86_64.img -append "ro"

Using the F12 menu, I can select any of the three option roms and it 
network boots or I can select 'Legacy Option ROM' and it will boot from 
-kernel.  That is exceedingly cool :-)  We just need to give it a proper 
PnP header and advertise it as a BEV device so that we can give it a 
meaningful name.

Regards,

Anthony Liguori

^ permalink raw reply related	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-18 17:03       ` Gerd Hoffmann
  2009-12-18 17:12         ` Anthony Liguori
@ 2009-12-18 17:14         ` Anthony Liguori
  2009-12-18 18:04           ` Gerd Hoffmann
  2009-12-18 19:41         ` Sebastian Herbszt
  2 siblings, 1 reply; 84+ messages in thread
From: Anthony Liguori @ 2009-12-18 17:14 UTC (permalink / raw)
  To: Gerd Hoffmann; +Cc: qemu-devel

Gerd Hoffmann wrote:
>>> Is 0.11 -> 0.12 migration supposed to work? That could become quite
>>> nasty too. But maybe that is impossible anyway due to the switch to
>>> seabios?
>>
>> In theory, it should work. SeaBIOS should not be a guest visible change
>> because the guest should not depend on what BIOS we're using.
>
> Indeed.  In theory even the switch of the option rom loading should 
> work just fine.  After migration old bios and roms are still in 
> memory, the next reboot will be the world switch to new seabios, new 
> roms, new way to deploy roms and everything.
>
> Lets see how this works out in practice ...

BTW, I've got the series in staging now and am testing it.  I've folded 
in the changes we've passed around and updated the commit log appropriately.

If you've got additional changes, please send them out, otherwise, let 
me know if you're happy with what's in staging.

Regards,

Anthony Liguori

> cheers,
>   Gerd
>

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-18 17:14         ` Anthony Liguori
@ 2009-12-18 18:04           ` Gerd Hoffmann
  0 siblings, 0 replies; 84+ messages in thread
From: Gerd Hoffmann @ 2009-12-18 18:04 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: qemu-devel

On 12/18/09 18:14, Anthony Liguori wrote:
> If you've got additional changes, please send them out, otherwise, let
> me know if you're happy with what's in staging.

Looks good.

cheers,
   Gerd

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-18 17:03       ` Gerd Hoffmann
  2009-12-18 17:12         ` Anthony Liguori
  2009-12-18 17:14         ` Anthony Liguori
@ 2009-12-18 19:41         ` Sebastian Herbszt
  2009-12-18 19:53           ` Anthony Liguori
  2 siblings, 1 reply; 84+ messages in thread
From: Sebastian Herbszt @ 2009-12-18 19:41 UTC (permalink / raw)
  To: Gerd Hoffmann, Anthony Liguori; +Cc: qemu-devel

Gerd Hoffmann wrote:
> On 12/18/09 17:42, Anthony Liguori wrote:
>>> Do we need to do something for -M pc-0.11? Like loading the pci roms
>>> via fw_cfg too so the guest doesn't see the new pci rom bar?
>>
>> Yes, we do. We can fix that problem as a stable-0.12 update though.
>> Right now, migration with pc-0.11 is broken in other areas too.
> 
> Ok.  When it is fine to defer this to stable-0.12 then I have no 
> objections to merge it for 0.12 (assuming the seabios folks ack+merge 
> the seabios changes).

0.12 will contain known regressions?

> Note that I'll be offline for x-mas and newyear starting tomorrow, so I 
> will not be able to work on that until January.
> 
>> It's really unclear to me the best way to handle live migration. The
>> rom_offset is not enough because unfortunately it's not stable after
>> invocations of qemu. I think we're going to have to actually save the
>> some contents with the PCIDevices.
> 
> With hotplug this will become a issue indeed.
> 
>>> Is 0.11 -> 0.12 migration supposed to work? That could become quite
>>> nasty too. But maybe that is impossible anyway due to the switch to
>>> seabios?
>>
>> In theory, it should work. SeaBIOS should not be a guest visible change
>> because the guest should not depend on what BIOS we're using.

If SeaBIOS would not have any regressions compared to Bochs BIOS then maybe.

> Indeed.  In theory even the switch of the option rom loading should work 
> just fine.  After migration old bios and roms are still in memory, the 
> next reboot will be the world switch to new seabios, new roms, new way 
> to deploy roms and everything.

Automagical "world switch" on reboot sounds like a nightmare. The VM environment
should be stable during reboots and only change if requested by the user.

- Sebastian

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-18 19:41         ` Sebastian Herbszt
@ 2009-12-18 19:53           ` Anthony Liguori
  2009-12-18 20:10             ` Sebastian Herbszt
  0 siblings, 1 reply; 84+ messages in thread
From: Anthony Liguori @ 2009-12-18 19:53 UTC (permalink / raw)
  To: Sebastian Herbszt; +Cc: Gerd Hoffmann, qemu-devel

Sebastian Herbszt wrote:
> Gerd Hoffmann wrote:
>> On 12/18/09 17:42, Anthony Liguori wrote:
>>>> Do we need to do something for -M pc-0.11? Like loading the pci roms
>>>> via fw_cfg too so the guest doesn't see the new pci rom bar?
>>>
>>> Yes, we do. We can fix that problem as a stable-0.12 update though.
>>> Right now, migration with pc-0.11 is broken in other areas too.
>>
>> Ok.  When it is fine to defer this to stable-0.12 then I have no 
>> objections to merge it for 0.12 (assuming the seabios folks ack+merge 
>> the seabios changes).
>
> 0.12 will contain known regressions?

Migrating between versions is not a regression.

> If SeaBIOS would not have any regressions compared to Bochs BIOS then 
> maybe.

Does it?  I'm not aware of any SeaBIOS regressions.

>> Indeed.  In theory even the switch of the option rom loading should 
>> work just fine.  After migration old bios and roms are still in 
>> memory, the next reboot will be the world switch to new seabios, new 
>> roms, new way to deploy roms and everything.
>
> Automagical "world switch" on reboot sounds like a nightmare. The VM 
> environment
> should be stable during reboots and only change if requested by the user.

That's extremely difficult to support.

Regards,

Anthony Liguori

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-18 19:53           ` Anthony Liguori
@ 2009-12-18 20:10             ` Sebastian Herbszt
  0 siblings, 0 replies; 84+ messages in thread
From: Sebastian Herbszt @ 2009-12-18 20:10 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: Gerd Hoffmann, qemu-devel

Anthony Liguori wrote:
> Sebastian Herbszt wrote:
>> Gerd Hoffmann wrote:
>>> On 12/18/09 17:42, Anthony Liguori wrote:
>>>>> Do we need to do something for -M pc-0.11? Like loading the pci roms
>>>>> via fw_cfg too so the guest doesn't see the new pci rom bar?
>>>>
>>>> Yes, we do. We can fix that problem as a stable-0.12 update though.
>>>> Right now, migration with pc-0.11 is broken in other areas too.
>>>
>>> Ok.  When it is fine to defer this to stable-0.12 then I have no 
>>> objections to merge it for 0.12 (assuming the seabios folks ack+merge 
>>> the seabios changes).
>>
>> 0.12 will contain known regressions?
> 
> Migrating between versions is not a regression.
> 
>> If SeaBIOS would not have any regressions compared to Bochs BIOS then 
>> maybe.
> 
> Does it?  I'm not aware of any SeaBIOS regressions.

E.g. BIOS32 and INT 15h function 89h.

>>> Indeed.  In theory even the switch of the option rom loading should 
>>> work just fine.  After migration old bios and roms are still in 
>>> memory, the next reboot will be the world switch to new seabios, new 
>>> roms, new way to deploy roms and everything.
>>
>> Automagical "world switch" on reboot sounds like a nightmare. The VM 
>> environment
>> should be stable during reboots and only change if requested by the user.
> 
> That's extremely difficult to support.

Isn't this what VMotion supports?

- Sebastian

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-18 17:12         ` Anthony Liguori
@ 2009-12-19  1:48           ` Kevin O'Connor
  2009-12-19  3:07             ` Anthony Liguori
  0 siblings, 1 reply; 84+ messages in thread
From: Kevin O'Connor @ 2009-12-19  1:48 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: Gerd Hoffmann, qemu-devel

On Fri, Dec 18, 2009 at 11:12:06AM -0600, Anthony Liguori wrote:
> BTW, the following works:
>
> sudo x86_64-softmmu/qemu-system-x86_64 -hda ~/images/linux.img -snapshot  
> -m 512 -net nic,model=rtl8139,macaddr=56:54:32:12:34:56 -net  
> nic,model=e1000,macaddr=56:54:32:12:34:57 -net  
> nic,model=virtio,macaddr=56:54:32:12:34:58 -boot menu=on -net tap  
> -kernel /boot/vmlinuz-2.6.27.38-170.2.113.fc10.x86_64 -initrd  
> /boot/initrd-2.6.27.38-170.2.113.fc10.x86_64.img -append "ro"
>
> Using the F12 menu, I can select any of the three option roms and it  
> network boots or I can select 'Legacy Option ROM' and it will boot from  
> -kernel.  That is exceedingly cool :-)  We just need to give it a proper  
> PnP header and advertise it as a BEV device so that we can give it a  
> meaningful name.

As it stands now, if the command line has -kernel, it will always boot
from the kernel regardless of the item one selects in the boot menu.
(Legacy roms are always run - the boot menu only selects the order wrt
BCVs.)  However, converting the rom into a BEV will indeed make it
selectable.

Also, to see a truly interesting boot menu - try appending something
like the following to the command line:

-fda disk.dsk -fdb odin1440.img -hdd dos-drivec -cdrom ../../iso/win-vista.iso -drive file=../../iso/win-xp.iso,media=cdrom,index=1

SeaBIOS allows one to boot from either floppy, any harddrive, and any
cdrom.

-Kevin

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-19  1:48           ` Kevin O'Connor
@ 2009-12-19  3:07             ` Anthony Liguori
  0 siblings, 0 replies; 84+ messages in thread
From: Anthony Liguori @ 2009-12-19  3:07 UTC (permalink / raw)
  To: Kevin O'Connor; +Cc: Gerd Hoffmann, qemu-devel

Kevin O'Connor wrote:
> On Fri, Dec 18, 2009 at 11:12:06AM -0600, Anthony Liguori wrote:
>   
>> BTW, the following works:
>>
>> sudo x86_64-softmmu/qemu-system-x86_64 -hda ~/images/linux.img -snapshot  
>> -m 512 -net nic,model=rtl8139,macaddr=56:54:32:12:34:56 -net  
>> nic,model=e1000,macaddr=56:54:32:12:34:57 -net  
>> nic,model=virtio,macaddr=56:54:32:12:34:58 -boot menu=on -net tap  
>> -kernel /boot/vmlinuz-2.6.27.38-170.2.113.fc10.x86_64 -initrd  
>> /boot/initrd-2.6.27.38-170.2.113.fc10.x86_64.img -append "ro"
>>
>> Using the F12 menu, I can select any of the three option roms and it  
>> network boots or I can select 'Legacy Option ROM' and it will boot from  
>> -kernel.  That is exceedingly cool :-)  We just need to give it a proper  
>> PnP header and advertise it as a BEV device so that we can give it a  
>> meaningful name.
>>     
>
> As it stands now, if the command line has -kernel, it will always boot
> from the kernel regardless of the item one selects in the boot menu.
>   
Ah, I spoke too soon, you are indeed correct.

I was wondering how that could possibly work :-)
> (Legacy roms are always run - the boot menu only selects the order wrt
> BCVs.)  However, converting the rom into a BEV will indeed make it
> selectable.
>
> Also, to see a truly interesting boot menu - try appending something
> like the following to the command line:
>
> -fda disk.dsk -fdb odin1440.img -hdd dos-drivec -cdrom ../../iso/win-vista.iso -drive file=../../iso/win-xp.iso,media=cdrom,index=1
>
> SeaBIOS allows one to boot from either floppy, any harddrive, and any
> cdrom.
>   

Very cool stuff!  We just have to figure out a way to let a user specify 
which of these devices they want to boot from via the qemu command 
line.   Maybe something that encodes a bus type and then an address on 
the bus or something like that.  I think that works okay for PCI and IDE 
buses.  For fw_cfg roms, I guess we could also just expose the filename 
as the address on the fw_cfg bus.

Regards,

Anthony Liguori

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] [PATCH 1/8] Support PCI based option rom loading
  2009-12-18 11:01 ` [Qemu-devel] [PATCH 1/8] Support PCI based option rom loading Gerd Hoffmann
@ 2009-12-19 10:57   ` Blue Swirl
  2009-12-20 15:34     ` Anthony Liguori
  0 siblings, 1 reply; 84+ messages in thread
From: Blue Swirl @ 2009-12-19 10:57 UTC (permalink / raw)
  To: Gerd Hoffmann; +Cc: Anthony Liguori, seabios, qemu-devel

On Fri, Dec 18, 2009 at 11:01 AM, Gerd Hoffmann <kraxel@redhat.com> wrote:
> From: Anthony Liguori <aliguori@us.ibm.com>
>
> Currently, we preload option roms into the option rom space in memory.  This
> prevents DDIM from functioning correctly which severely limits the number
> of roms we can support.
>
> This patch introduces a pci_add_option_rom() which registers the
> PCI_ROM_ADDRESS bar which points to our option rom.  It also converts over
> the cirrus vga adapter, the rtl8139, virtio, and the e1000 to use this
> new mechanism.

This means that the VGA roms are now visible for all targets, not just
when rom_enable_driver_roms is true. I'm not opposing this, but it may
create regressions.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] [PATCH 4/8] fw_cfg: add API for file transfer.
  2009-12-18 11:01 ` [Qemu-devel] [PATCH 4/8] fw_cfg: add API for file transfer Gerd Hoffmann
@ 2009-12-19 12:06   ` Blue Swirl
  2009-12-20  8:42   ` [Qemu-devel] Re: [SeaBIOS] " Gleb Natapov
  1 sibling, 0 replies; 84+ messages in thread
From: Blue Swirl @ 2009-12-19 12:06 UTC (permalink / raw)
  To: Gerd Hoffmann; +Cc: seabios, qemu-devel

On Fri, Dec 18, 2009 at 11:01 AM, Gerd Hoffmann <kraxel@redhat.com> wrote:
> This patch adds a file transfer interface to fw_cfg.  Intended to be
> used for passing non-pci option roms and vgabios to seabios.  Namespace
> is modeled after the existing cbfs filesystem support in seabios.
>
> Reading the new FW_CFG_FILE_DIR entry returns a file list.
> Fields there are in network byte order (aka bigendian).

The 16 bit selector for other cases is in little endian order. Please
use LE for consistency.

> +    fprintf(stderr, "%s: #%d: %s (%d bytes)\n", __FUNCTION__,
> +            index, s->files->f[index].name, len);

No.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-18 11:01 [Qemu-devel] [PATCH 0/8] option rom loading overhaul Gerd Hoffmann
                   ` (8 preceding siblings ...)
  2009-12-18 14:35 ` [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul Anthony Liguori
@ 2009-12-20  8:38 ` Gleb Natapov
  2009-12-20 14:43   ` Anthony Liguori
  9 siblings, 1 reply; 84+ messages in thread
From: Gleb Natapov @ 2009-12-20  8:38 UTC (permalink / raw)
  To: Gerd Hoffmann; +Cc: Anthony Liguori, seabios, qemu-devel

On Fri, Dec 18, 2009 at 12:01:06PM +0100, Gerd Hoffmann wrote:
> From: Anthony Liguori <aliguori@us.ibm.com>
> 
>   Hi,
> 
> Option rom saga continued.  This is the first series I consider ready
> for merging.  Changes:
> 
>   * pci roms: will be loaded via option pci rom bar.
>   * non-pci roms: will be loaded via fw_cfg.
> 
> Note that using the old bochs-bios based pc-bios will stop working
> with this patch series applied.
> 
> The last two patches of this series are *not* intended to be merged,
> they are just for testing convinience.  They carry a new seabios
> binary and the changes needed and turn on bios debug messages in qemu.
> 
> Seabios patches will be posted shortly as separate patch series.
> 
I see that this is merged already, but I have a question. How migration
during ROM loading suppose to work? What will happed if we migrate to newer
qemu with updated vgabios ROM while BIOS is in the middle of loading it on the
source? It seems that destination will have garbled ROM loaded.

--
			Gleb.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 4/8] fw_cfg: add API for file transfer.
  2009-12-18 11:01 ` [Qemu-devel] [PATCH 4/8] fw_cfg: add API for file transfer Gerd Hoffmann
  2009-12-19 12:06   ` Blue Swirl
@ 2009-12-20  8:42   ` Gleb Natapov
  1 sibling, 0 replies; 84+ messages in thread
From: Gleb Natapov @ 2009-12-20  8:42 UTC (permalink / raw)
  To: Gerd Hoffmann; +Cc: seabios, qemu-devel

On Fri, Dec 18, 2009 at 12:01:10PM +0100, Gerd Hoffmann wrote:
> This patch adds a file transfer interface to fw_cfg.  Intended to be
> used for passing non-pci option roms and vgabios to seabios.  Namespace
> is modeled after the existing cbfs filesystem support in seabios.
> 
> Reading the new FW_CFG_FILE_DIR entry returns a file list.
> Fields there are in network byte order (aka bigendian).
> 
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  hw/fw_cfg.c |   43 +++++++++++++++++++++++++++++++++++++++++++
>  hw/fw_cfg.h |   21 +++++++++++++++++++--
>  2 files changed, 62 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/fw_cfg.c b/hw/fw_cfg.c
> index 2e3662d..0492f5f 100644
> --- a/hw/fw_cfg.c
> +++ b/hw/fw_cfg.c
> @@ -47,6 +47,7 @@ typedef struct _FWCfgEntry {
>  
>  struct _FWCfgState {
>      FWCfgEntry entries[2][FW_CFG_MAX_ENTRY];
> +    FWCfgFiles *files;
>      uint16_t cur_entry;
>      uint32_t cur_offset;
>  };
> @@ -273,6 +274,48 @@ int fw_cfg_add_callback(FWCfgState *s, uint16_t key, FWCfgCallback callback,
>      return 1;
>  }
>  
> +int fw_cfg_add_file(FWCfgState *s,  const char *dir, const char *filename,
> +                    uint8_t *data, uint32_t len)
> +{
> +    const char *basename;
> +    int index;
> +
> +    if (!s->files) {
> +        int dsize = sizeof(uint32_t) + sizeof(FWCfgFile) * FW_CFG_FILE_SLOTS;
> +        s->files = qemu_mallocz(dsize);
> +        fw_cfg_add_bytes(s, FW_CFG_FILE_DIR, (uint8_t*)s->files, dsize);
> +    }
> +
> +    index = be32_to_cpu(s->files->count);
> +    if (index == FW_CFG_FILE_SLOTS) {
> +        fprintf(stderr, "fw_cfg: out of file slots\n");
> +        return 0;
> +    }
> +
> +    fw_cfg_add_bytes(s, FW_CFG_FILE_FIRST + index, data, len);
> +
> +    basename = strrchr(filename, '/');
> +    if (basename) {
> +        basename++;
> +    } else {
> +        basename = filename;
> +    }
> +    if (dir) {
> +        snprintf(s->files->f[index].name, sizeof(s->files->f[index].name),
> +                 "%s/%s", dir, basename);
> +    } else {
> +        snprintf(s->files->f[index].name, sizeof(s->files->f[index].name),
> +                 "%s", basename);
> +    }
> +    s->files->f[index].size   = cpu_to_be32(len);
> +    s->files->f[index].select = cpu_to_be16(FW_CFG_FILE_FIRST + index);
> +    fprintf(stderr, "%s: #%d: %s (%d bytes)\n", __FUNCTION__,
> +            index, s->files->f[index].name, len);
> +
> +    s->files->count = cpu_to_be32(index+1);
> +    return 1;
> +}
> +
>  FWCfgState *fw_cfg_init(uint32_t ctl_port, uint32_t data_port,
>                          target_phys_addr_t ctl_addr, target_phys_addr_t data_addr)
>  {
> diff --git a/hw/fw_cfg.h b/hw/fw_cfg.h
> index b06665e..a63f54f 100644
> --- a/hw/fw_cfg.h
> +++ b/hw/fw_cfg.h
> @@ -26,7 +26,11 @@
>  #define FW_CFG_SETUP_ADDR       0x16
>  #define FW_CFG_SETUP_SIZE       0x17
>  #define FW_CFG_SETUP_DATA       0x18
> -#define FW_CFG_MAX_ENTRY        0x19
> +#define FW_CFG_FILE_DIR         0x19
> +
> +#define FW_CFG_FILE_FIRST       0x20
> +#define FW_CFG_FILE_SLOTS       0x10
The name of this define looks like CFG option number but it is not.
Lets rename it.

> +#define FW_CFG_MAX_ENTRY        (FW_CFG_FILE_FIRST+FW_CFG_FILE_SLOTS)
>  
>  #define FW_CFG_WRITE_CHANNEL    0x4000
>  #define FW_CFG_ARCH_LOCAL       0x8000
> @@ -34,6 +38,18 @@
>  
>  #define FW_CFG_INVALID          0xffff
>  
> +typedef struct FWCfgFile {
> +    uint32_t  size;        /* file size */
> +    uint16_t  select;      /* write this to 0x510 to read it */
> +    uint16_t  reserved;
> +    char      name[56];
> +} FWCfgFile;
> +
> +typedef struct FWCfgFiles {
> +    uint32_t  count;
> +    FWCfgFile f[];
> +} FWCfgFiles;
> +
>  #ifndef NO_QEMU_PROTOS
>  typedef void (*FWCfgCallback)(void *opaque, uint8_t *data);
>  
> @@ -44,7 +60,8 @@ int fw_cfg_add_i32(FWCfgState *s, uint16_t key, uint32_t value);
>  int fw_cfg_add_i64(FWCfgState *s, uint16_t key, uint64_t value);
>  int fw_cfg_add_callback(FWCfgState *s, uint16_t key, FWCfgCallback callback,
>                          void *callback_opaque, uint8_t *data, size_t len);
> -int fw_cfg_add_file(FWCfgState *s, uint8_t type, uint8_t *data, uint32_t len);
> +int fw_cfg_add_file(FWCfgState *s, const char *dir, const char *filename,
> +                    uint8_t *data, uint32_t len);
>  FWCfgState *fw_cfg_init(uint32_t ctl_port, uint32_t data_port,
>                          target_phys_addr_t crl_addr, target_phys_addr_t data_addr);
>  
> -- 
> 1.6.5.2
> 
> 
> _______________________________________________
> SeaBIOS mailing list
> SeaBIOS@seabios.org
> http://www.seabios.org/mailman/listinfo/seabios

--
			Gleb.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 5/8] roms: use new fw_cfg file xfer support.
  2009-12-18 11:01 ` [Qemu-devel] [PATCH 5/8] roms: use new fw_cfg file xfer support Gerd Hoffmann
@ 2009-12-20  8:45   ` Gleb Natapov
  0 siblings, 0 replies; 84+ messages in thread
From: Gleb Natapov @ 2009-12-20  8:45 UTC (permalink / raw)
  To: Gerd Hoffmann; +Cc: seabios, qemu-devel

On Fri, Dec 18, 2009 at 12:01:11PM +0100, Gerd Hoffmann wrote:
> roms: use fw_cfg for vgabios and option rom loading, additionally to
> deploying them the traditional way (copy to 0xc0000 -> 0xe0000 range).
> 
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  hw/loader.c |   25 ++++++++++++++++++++++---
>  hw/loader.h |    5 +++--
>  hw/pc.c     |    2 ++
>  3 files changed, 27 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/loader.c b/hw/loader.c
> index 2d7a2c4..ccc0ccc 100644
> --- a/hw/loader.c
> +++ b/hw/loader.c
> @@ -48,6 +48,7 @@
>  #include "sysemu.h"
>  #include "uboot_image.h"
>  #include "loader.h"
> +#include "fw_cfg.h"
>  
>  #include <zlib.h>
>  
> @@ -528,6 +529,8 @@ struct Rom {
>      uint8_t *data;
>      int align;
>      int isrom;
> +    char *fw_dir;
> +    char *fw_file;
>  
>      target_phys_addr_t min;
>      target_phys_addr_t max;
> @@ -556,7 +559,7 @@ static void rom_insert(Rom *rom)
>      QTAILQ_INSERT_TAIL(&roms, rom, next);
>  }
>  
> -int rom_add_file(const char *file,
> +int rom_add_file(const char *file, const char *fw_dir, const char *fw_file,
Currently file == fw_file except for rom_add_file_fixed. Is this always
going to be the case? If yes may be better to pass "bool fixed" instead
of "const char *fw_file"?

>                   target_phys_addr_t min, target_phys_addr_t max, int align)
>  {
>      Rom *rom;
> @@ -576,6 +579,8 @@ int rom_add_file(const char *file,
>          goto err;
>      }
>  
> +    rom->fw_dir  = fw_dir  ? qemu_strdup(fw_dir)  : NULL;
> +    rom->fw_file = fw_file ? qemu_strdup(fw_file) : NULL;
>      rom->align   = align;
>      rom->min     = min;
>      rom->max     = max;
> @@ -623,14 +628,16 @@ int rom_add_vga(const char *file)
>  {
>      if (!rom_enable_driver_roms)
>          return 0;
> -    return rom_add_file(file, PC_ROM_MIN_VGA, PC_ROM_MAX, PC_ROM_ALIGN);
> +    return rom_add_file(file, "vgaroms", file,
> +                        PC_ROM_MIN_VGA, PC_ROM_MAX, PC_ROM_ALIGN);
>  }
>  
>  int rom_add_option(const char *file)
>  {
>      if (!rom_enable_driver_roms)
>          return 0;
> -    return rom_add_file(file, PC_ROM_MIN_OPTION, PC_ROM_MAX, PC_ROM_ALIGN);
> +    return rom_add_file(file, "genroms", file,
> +                        PC_ROM_MIN_OPTION, PC_ROM_MAX, PC_ROM_ALIGN);
>  }
>  
>  static void rom_reset(void *unused)
> @@ -692,6 +699,18 @@ int rom_load_all(void)
>      return 0;
>  }
>  
> +int rom_load_fw(void *fw_cfg)
> +{
> +    Rom *rom;
> +
> +    QTAILQ_FOREACH(rom, &roms, next) {
> +        if (!rom->fw_file)
> +            continue;
> +        fw_cfg_add_file(fw_cfg, rom->fw_dir, rom->fw_file, rom->data, rom->romsize);
> +    }
> +    return 0;
> +}
> +
>  static Rom *find_rom(target_phys_addr_t addr)
>  {
>      Rom *rom;
> diff --git a/hw/loader.h b/hw/loader.h
> index b3311a3..634f7d5 100644
> --- a/hw/loader.h
> +++ b/hw/loader.h
> @@ -19,17 +19,18 @@ void pstrcpy_targphys(const char *name,
>                        target_phys_addr_t dest, int buf_size,
>                        const char *source);
>  
> -int rom_add_file(const char *file,
> +int rom_add_file(const char *file, const char *fw_dir, const char *fw_file,
>                   target_phys_addr_t min, target_phys_addr_t max, int align);
>  int rom_add_blob(const char *name, const void *blob, size_t len,
>                   target_phys_addr_t min, target_phys_addr_t max, int align);
>  int rom_load_all(void);
> +int rom_load_fw(void *fw_cfg);
>  int rom_copy(uint8_t *dest, target_phys_addr_t addr, size_t size);
>  void *rom_ptr(target_phys_addr_t addr);
>  void do_info_roms(Monitor *mon);
>  
>  #define rom_add_file_fixed(_f, _a)              \
> -    rom_add_file(_f, _a, 0, 0)
> +    rom_add_file(_f, NULL, NULL, _a, 0, 0)
>  #define rom_add_blob_fixed(_f, _b, _l, _a)      \
>      rom_add_blob(_f, _b, _l, _a, 0, 0)
>  
> diff --git a/hw/pc.c b/hw/pc.c
> index 147a9a7..be70f50 100644
> --- a/hw/pc.c
> +++ b/hw/pc.c
> @@ -1248,6 +1248,8 @@ static void pc_init1(ram_addr_t ram_size,
>              }
>          }
>      }
> +
> +    rom_load_fw(fw_cfg);
>  }
>  
>  static void pc_init_pci(ram_addr_t ram_size,
> -- 
> 1.6.5.2
> 
> 
> _______________________________________________
> SeaBIOS mailing list
> SeaBIOS@seabios.org
> http://www.seabios.org/mailman/listinfo/seabios

--
			Gleb.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-20  8:38 ` Gleb Natapov
@ 2009-12-20 14:43   ` Anthony Liguori
  2009-12-20 14:52     ` Gleb Natapov
  0 siblings, 1 reply; 84+ messages in thread
From: Anthony Liguori @ 2009-12-20 14:43 UTC (permalink / raw)
  To: Gleb Natapov; +Cc: Gerd Hoffmann, qemu-devel

Gleb Natapov wrote:
> On Fri, Dec 18, 2009 at 12:01:06PM +0100, Gerd Hoffmann wrote:
>   
>> From: Anthony Liguori <aliguori@us.ibm.com>
>>
>>   Hi,
>>
>> Option rom saga continued.  This is the first series I consider ready
>> for merging.  Changes:
>>
>>   * pci roms: will be loaded via option pci rom bar.
>>   * non-pci roms: will be loaded via fw_cfg.
>>
>> Note that using the old bochs-bios based pc-bios will stop working
>> with this patch series applied.
>>
>> The last two patches of this series are *not* intended to be merged,
>> they are just for testing convinience.  They carry a new seabios
>> binary and the changes needed and turn on bios debug messages in qemu.
>>
>> Seabios patches will be posted shortly as separate patch series.
>>
>>     
> I see that this is merged already, but I have a question. How migration
> during ROM loading suppose to work?

Magically :-)

Really, we have a fundamentally problem with live migration (that's 
orthogonal to this series).  We allocate memory via qemu_ram_alloc() but 
we don't have any context to that allocation.  When we migrate memory, 
we do so by transferring ram basically in allocation order.

If for some reason allocation order changes, badness ensues.  The 
problem is, a lot of devices use qemu_ram_alloc() now and they do so 
when they are initialized so the stability of the allocation depends on 
the initialization order.  It's exacerbated by things like PCI hotplug.

We need to make a change in the live migration protocol that transfers 
memory identified with tuples (id, chunk offset).  We'll need to change 
every qemu_ram_alloc() to take an id argument too.

>  What will happed if we migrate to newer
> qemu with updated vgabios ROM while BIOS is in the middle of loading it on the
> source? It seems that destination will have garbled ROM loaded.
>   

During device init, pci device allocates memory, loads rom into 
allocated memory.  Upon live migration, allocated memory gets over 
written by rom contents from source.  So in this case, it will actually 
work today (assuming you get stable ram allocation offsets).

Regards,

Anthony Liguori

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-20 14:43   ` Anthony Liguori
@ 2009-12-20 14:52     ` Gleb Natapov
  2009-12-20 14:58       ` Anthony Liguori
  0 siblings, 1 reply; 84+ messages in thread
From: Gleb Natapov @ 2009-12-20 14:52 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: Gerd Hoffmann, qemu-devel

On Sun, Dec 20, 2009 at 08:43:38AM -0600, Anthony Liguori wrote:
> Gleb Natapov wrote:
> >On Fri, Dec 18, 2009 at 12:01:06PM +0100, Gerd Hoffmann wrote:
> >>From: Anthony Liguori <aliguori@us.ibm.com>
> >>
> >>  Hi,
> >>
> >>Option rom saga continued.  This is the first series I consider ready
> >>for merging.  Changes:
> >>
> >>  * pci roms: will be loaded via option pci rom bar.
> >>  * non-pci roms: will be loaded via fw_cfg.
> >>
> >>Note that using the old bochs-bios based pc-bios will stop working
> >>with this patch series applied.
> >>
> >>The last two patches of this series are *not* intended to be merged,
> >>they are just for testing convinience.  They carry a new seabios
> >>binary and the changes needed and turn on bios debug messages in qemu.
> >>
> >>Seabios patches will be posted shortly as separate patch series.
> >>
> >I see that this is merged already, but I have a question. How migration
> >during ROM loading suppose to work?
> 
> Magically :-)
> 
> Really, we have a fundamentally problem with live migration (that's
> orthogonal to this series).  We allocate memory via qemu_ram_alloc()
> but we don't have any context to that allocation.  When we migrate
> memory, we do so by transferring ram basically in allocation order.
> 
> If for some reason allocation order changes, badness ensues.  The
> problem is, a lot of devices use qemu_ram_alloc() now and they do so
> when they are initialized so the stability of the allocation depends
> on the initialization order.  It's exacerbated by things like PCI
> hotplug.
> 
> We need to make a change in the live migration protocol that
> transfers memory identified with tuples (id, chunk offset).  We'll
> need to change every qemu_ram_alloc() to take an id argument too.
> 
> > What will happed if we migrate to newer
> >qemu with updated vgabios ROM while BIOS is in the middle of loading it on the
> >source? It seems that destination will have garbled ROM loaded.
> 
> During device init, pci device allocates memory, loads rom into
> allocated memory.  Upon live migration, allocated memory gets over
> written by rom contents from source.  So in this case, it will
> actually work today (assuming you get stable ram allocation
> offsets).
> 
That much I noticed :), but first after reboot new ROMs should take effect.
Does this happed? Second what if ROM size have changed (on destination it is
smaller)? And third what about roms that are loaded with fw_cfg interface (me
mentioning vgabios was not accident :))

--
			Gleb.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-20 14:52     ` Gleb Natapov
@ 2009-12-20 14:58       ` Anthony Liguori
  2009-12-20 15:07         ` Gleb Natapov
  0 siblings, 1 reply; 84+ messages in thread
From: Anthony Liguori @ 2009-12-20 14:58 UTC (permalink / raw)
  To: Gleb Natapov; +Cc: Gerd Hoffmann, qemu-devel

Gleb Natapov wrote:
> On Sun, Dec 20, 2009 at 08:43:38AM -0600, Anthony Liguori wrote:
>   
>> Gleb Natapov wrote:
>>     
>>> On Fri, Dec 18, 2009 at 12:01:06PM +0100, Gerd Hoffmann wrote:
>>>       
>>>> From: Anthony Liguori <aliguori@us.ibm.com>
>>>>
>>>>  Hi,
>>>>
>>>> Option rom saga continued.  This is the first series I consider ready
>>>> for merging.  Changes:
>>>>
>>>>  * pci roms: will be loaded via option pci rom bar.
>>>>  * non-pci roms: will be loaded via fw_cfg.
>>>>
>>>> Note that using the old bochs-bios based pc-bios will stop working
>>>> with this patch series applied.
>>>>
>>>> The last two patches of this series are *not* intended to be merged,
>>>> they are just for testing convinience.  They carry a new seabios
>>>> binary and the changes needed and turn on bios debug messages in qemu.
>>>>
>>>> Seabios patches will be posted shortly as separate patch series.
>>>>
>>>>         
>>> I see that this is merged already, but I have a question. How migration
>>> during ROM loading suppose to work?
>>>       
>> Magically :-)
>>
>> Really, we have a fundamentally problem with live migration (that's
>> orthogonal to this series).  We allocate memory via qemu_ram_alloc()
>> but we don't have any context to that allocation.  When we migrate
>> memory, we do so by transferring ram basically in allocation order.
>>
>> If for some reason allocation order changes, badness ensues.  The
>> problem is, a lot of devices use qemu_ram_alloc() now and they do so
>> when they are initialized so the stability of the allocation depends
>> on the initialization order.  It's exacerbated by things like PCI
>> hotplug.
>>
>> We need to make a change in the live migration protocol that
>> transfers memory identified with tuples (id, chunk offset).  We'll
>> need to change every qemu_ram_alloc() to take an id argument too.
>>
>>     
>>> What will happed if we migrate to newer
>>> qemu with updated vgabios ROM while BIOS is in the middle of loading it on the
>>> source? It seems that destination will have garbled ROM loaded.
>>>       
>> During device init, pci device allocates memory, loads rom into
>> allocated memory.  Upon live migration, allocated memory gets over
>> written by rom contents from source.  So in this case, it will
>> actually work today (assuming you get stable ram allocation
>> offsets).
>>
>>     
> That much I noticed :), but first after reboot new ROMs should take effect.
> Does this happed?

No.  You have to physically shut down and start up again.  That's the 
right semantics IMHO.

>  Second what if ROM size have changed (on destination it is
> smaller)?

Then we're in trouble :-)

>  And third what about roms that are loaded with fw_cfg interface (me
> mentioning vgabios was not accident :))
>   

vgabios will be loaded as a PCI rom.  -std vga still uses fw_cfg but 
that's a really easy fix.

But the fw_cfg rom loading doesn't seem handle migration :-/

Regards,

Anthony Liguori

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-20 14:58       ` Anthony Liguori
@ 2009-12-20 15:07         ` Gleb Natapov
  2009-12-20 15:11           ` Anthony Liguori
  0 siblings, 1 reply; 84+ messages in thread
From: Gleb Natapov @ 2009-12-20 15:07 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: Gerd Hoffmann, qemu-devel

On Sun, Dec 20, 2009 at 08:58:40AM -0600, Anthony Liguori wrote:
> Gleb Natapov wrote:
> >On Sun, Dec 20, 2009 at 08:43:38AM -0600, Anthony Liguori wrote:
> >>Gleb Natapov wrote:
> >>>On Fri, Dec 18, 2009 at 12:01:06PM +0100, Gerd Hoffmann wrote:
> >>>>From: Anthony Liguori <aliguori@us.ibm.com>
> >>>>
> >>>> Hi,
> >>>>
> >>>>Option rom saga continued.  This is the first series I consider ready
> >>>>for merging.  Changes:
> >>>>
> >>>> * pci roms: will be loaded via option pci rom bar.
> >>>> * non-pci roms: will be loaded via fw_cfg.
> >>>>
> >>>>Note that using the old bochs-bios based pc-bios will stop working
> >>>>with this patch series applied.
> >>>>
> >>>>The last two patches of this series are *not* intended to be merged,
> >>>>they are just for testing convinience.  They carry a new seabios
> >>>>binary and the changes needed and turn on bios debug messages in qemu.
> >>>>
> >>>>Seabios patches will be posted shortly as separate patch series.
> >>>>
> >>>I see that this is merged already, but I have a question. How migration
> >>>during ROM loading suppose to work?
> >>Magically :-)
> >>
> >>Really, we have a fundamentally problem with live migration (that's
> >>orthogonal to this series).  We allocate memory via qemu_ram_alloc()
> >>but we don't have any context to that allocation.  When we migrate
> >>memory, we do so by transferring ram basically in allocation order.
> >>
> >>If for some reason allocation order changes, badness ensues.  The
> >>problem is, a lot of devices use qemu_ram_alloc() now and they do so
> >>when they are initialized so the stability of the allocation depends
> >>on the initialization order.  It's exacerbated by things like PCI
> >>hotplug.
> >>
> >>We need to make a change in the live migration protocol that
> >>transfers memory identified with tuples (id, chunk offset).  We'll
> >>need to change every qemu_ram_alloc() to take an id argument too.
> >>
> >>>What will happed if we migrate to newer
> >>>qemu with updated vgabios ROM while BIOS is in the middle of loading it on the
> >>>source? It seems that destination will have garbled ROM loaded.
> >>During device init, pci device allocates memory, loads rom into
> >>allocated memory.  Upon live migration, allocated memory gets over
> >>written by rom contents from source.  So in this case, it will
> >>actually work today (assuming you get stable ram allocation
> >>offsets).
> >>
> >That much I noticed :), but first after reboot new ROMs should take effect.
> >Does this happed?
> 
> No.  You have to physically shut down and start up again.  That's
> the right semantics IMHO.
> 
Reset is equivalent (or should be) to shut down and start up again.

> > Second what if ROM size have changed (on destination it is
> >smaller)?
> 
> Then we're in trouble :-)
> 
Yeah, we are. May be relaying on file size is not good enough heuristic
to determine ROM BAR size.

> > And third what about roms that are loaded with fw_cfg interface (me
> >mentioning vgabios was not accident :))
> 
> vgabios will be loaded as a PCI rom.  -std vga still uses fw_cfg but
> that's a really easy fix.
I mean -std vga and other "genroms" (multiboot, linuxboot, vapic). 

> 
> But the fw_cfg rom loading doesn't seem handle migration :-/
> 
Looks like it. We should send them over during migration too.

--
			Gleb.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-20 15:07         ` Gleb Natapov
@ 2009-12-20 15:11           ` Anthony Liguori
  2009-12-20 15:20             ` Avi Kivity
  2009-12-20 15:23             ` Gleb Natapov
  0 siblings, 2 replies; 84+ messages in thread
From: Anthony Liguori @ 2009-12-20 15:11 UTC (permalink / raw)
  To: Gleb Natapov; +Cc: Gerd Hoffmann, qemu-devel

Gleb Natapov wrote:
> On Sun, Dec 20, 2009 at 08:58:40AM -0600, Anthony Liguori wrote:
>   
>> No.  You have to physically shut down and start up again.  That's
>> the right semantics IMHO.
>>
>>     
> Reset is equivalent (or should be) to shut down and start up again.
>   

Not at all.  Reset can happen in a lot of different ways, some that 
there is really no way to detect (jumping right to BIOS vector).  From a 
hardware perspective, powering down a CPU and powering it on again 
behaves very differently than reset (consider the VT enablement MSRs).

>>> Second what if ROM size have changed (on destination it is
>>> smaller)?
>>>       
>> Then we're in trouble :-)
>>     
> Yeah, we are. May be relaying on file size is not good enough heuristic
> to determine ROM BAR size.
>   

Practically speaking, I don't think it's a huge problem to be honest.  
It's a very unlikely scenario.  We could make the rom size a qdev 
property which would allow a user to explicitly deal with this case.

>> But the fw_cfg rom loading doesn't seem handle migration :-/
>>
>>     
> Looks like it. We should send them over during migration too.
>   

We should just qemu_ram_alloc() that memory regardless of whether we 
every map it into the guest.  Since roms can be large, we want to send 
their contents over during the live part of migration.  If we use 
qemu_ram_alloc(), we get that for free.

Regards,

Anthony Liguori

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-20 15:11           ` Anthony Liguori
@ 2009-12-20 15:20             ` Avi Kivity
  2009-12-20 15:31               ` Anthony Liguori
  2009-12-22 13:04               ` Paul Brook
  2009-12-20 15:23             ` Gleb Natapov
  1 sibling, 2 replies; 84+ messages in thread
From: Avi Kivity @ 2009-12-20 15:20 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: Gerd Hoffmann, Gleb Natapov, qemu-devel

On 12/20/2009 05:11 PM, Anthony Liguori wrote:
>
> Not at all.  Reset can happen in a lot of different ways, some that 
> there is really no way to detect (jumping right to BIOS vector).  From 
> a hardware perspective, powering down a CPU and powering it on again 
> behaves very differently than reset (consider the VT enablement MSRs).

Power down and reset are equivalent, you're thinking of INIT (though 
some boards wire reset to INIT).

> We should just qemu_ram_alloc() that memory regardless of whether we 
> every map it into the guest.  Since roms can be large, we want to send 
> their contents over during the live part of migration.  If we use 
> qemu_ram_alloc(), we get that for free.

Currently live migration uses ram_addrs, so this would work.  But 
ram_addrs have no meaning in the guest and thus depend on qemu 
implementation details.  IMO we should switch live migration to use 
guest physical addresses, which would require a different migration 
implementation for roms.  Most of it can be shared with ram, though.

-- 
error compiling committee.c: too many arguments to function

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-20 15:11           ` Anthony Liguori
  2009-12-20 15:20             ` Avi Kivity
@ 2009-12-20 15:23             ` Gleb Natapov
  2009-12-20 15:28               ` Anthony Liguori
  1 sibling, 1 reply; 84+ messages in thread
From: Gleb Natapov @ 2009-12-20 15:23 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: Gerd Hoffmann, qemu-devel

On Sun, Dec 20, 2009 at 09:11:18AM -0600, Anthony Liguori wrote:
> Gleb Natapov wrote:
> >On Sun, Dec 20, 2009 at 08:58:40AM -0600, Anthony Liguori wrote:
> >>No.  You have to physically shut down and start up again.  That's
> >>the right semantics IMHO.
> >>
> >Reset is equivalent (or should be) to shut down and start up again.
> 
> Not at all.  Reset can happen in a lot of different ways, some that
We support only one way of reset: hard reset. It equivalent to full
HW power cycling. ACPI spec define ACPI reset as equivalent to HW power
cycling too BTW (see 4.7.3.6).

> there is really no way to detect (jumping right to BIOS vector).
This is not reset at all from qemu POV. No need to reload ROMS.
 
> From a hardware perspective, powering down a CPU and powering it on
> again behaves very differently than reset (consider the VT
> enablement MSRs).
May be you are confusing cpu reset by INIT with CPU reset by power
cycling. system_reset (or triple fault or kbd reset or ACPI reset)
does the later.

> 
> >>>Second what if ROM size have changed (on destination it is
> >>>smaller)?
> >>Then we're in trouble :-)
> >Yeah, we are. May be relaying on file size is not good enough heuristic
> >to determine ROM BAR size.
> 
> Practically speaking, I don't think it's a huge problem to be
> honest.  It's a very unlikely scenario.  We could make the rom size
> a qdev property which would allow a user to explicitly deal with
> this case.
Agree that it is unlikely, but I don't want to be the one debugging it.

> 
> >>But the fw_cfg rom loading doesn't seem handle migration :-/
> >>
> >Looks like it. We should send them over during migration too.
> 
> We should just qemu_ram_alloc() that memory regardless of whether we
> every map it into the guest.  Since roms can be large, we want to
> send their contents over during the live part of migration.  If we
> use qemu_ram_alloc(), we get that for free.
> 
This will work only if we assume that rom file size doesn't shrink, 

--
			Gleb.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-20 15:23             ` Gleb Natapov
@ 2009-12-20 15:28               ` Anthony Liguori
  2009-12-20 15:33                 ` Gleb Natapov
  0 siblings, 1 reply; 84+ messages in thread
From: Anthony Liguori @ 2009-12-20 15:28 UTC (permalink / raw)
  To: Gleb Natapov; +Cc: Gerd Hoffmann, qemu-devel

Gleb Natapov wrote:
> On Sun, Dec 20, 2009 at 09:11:18AM -0600, Anthony Liguori wrote:
>   
>> Gleb Natapov wrote:
>>     
>>> On Sun, Dec 20, 2009 at 08:58:40AM -0600, Anthony Liguori wrote:
>>>       
>>>> No.  You have to physically shut down and start up again.  That's
>>>> the right semantics IMHO.
>>>>
>>>>         
>>> Reset is equivalent (or should be) to shut down and start up again.
>>>       
>> Not at all.  Reset can happen in a lot of different ways, some that
>>     
> We support only one way of reset: hard reset. It equivalent to full
> HW power cycling. ACPI spec define ACPI reset as equivalent to HW power
> cycling too BTW (see 4.7.3.6).
>   

For every system periphereal?  For instance, memory contents survive a 
reset whereas they won't survive a hard power down.

More importantly though, what's the use-case here?

> This will work only if we assume that rom file size doesn't shrink,

Well the easy thing to do is hard code the rom size into qemu and throw 
an error if the rom size increases.  That way, if a rom does shrink, 
we're safe and if a rom size increases, we get an immediate run time 
error that gives the contributor feed back that they need to bump the 
constant.

Regards,

Anthony Liguori

>  
>
> --
> 			Gleb.
>   

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-20 15:20             ` Avi Kivity
@ 2009-12-20 15:31               ` Anthony Liguori
  2009-12-20 15:35                 ` Avi Kivity
  2009-12-22 13:04               ` Paul Brook
  1 sibling, 1 reply; 84+ messages in thread
From: Anthony Liguori @ 2009-12-20 15:31 UTC (permalink / raw)
  To: Avi Kivity; +Cc: Gerd Hoffmann, Gleb Natapov, qemu-devel

Avi Kivity wrote:
>> We should just qemu_ram_alloc() that memory regardless of whether we 
>> every map it into the guest.  Since roms can be large, we want to 
>> send their contents over during the live part of migration.  If we 
>> use qemu_ram_alloc(), we get that for free.
>
> Currently live migration uses ram_addrs, so this would work.  But 
> ram_addrs have no meaning in the guest and thus depend on qemu 
> implementation details.  IMO we should switch live migration to use 
> guest physical addresses, which would require a different migration 
> implementation for roms.  Most of it can be shared with ram, though.

I'd rather do (id, offset) instead of guest physical address.  Guest 
physical addresses map to ram_addrs in chunks.  Each chunk usually has 
some reasonable identification (below 640k, above 1mb, above 4gb, 
etc.).  Other type of memory like roms and vga lfb memory aren't always 
part of the guest physical address space but nonetheless still need to 
be migrated.  This gives us one mechanism to support everything.

Regards,

Anthony Liguori

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-20 15:28               ` Anthony Liguori
@ 2009-12-20 15:33                 ` Gleb Natapov
  2009-12-20 15:39                   ` Anthony Liguori
  2010-01-12  4:48                   ` Jamie Lokier
  0 siblings, 2 replies; 84+ messages in thread
From: Gleb Natapov @ 2009-12-20 15:33 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: Gerd Hoffmann, qemu-devel

On Sun, Dec 20, 2009 at 09:28:34AM -0600, Anthony Liguori wrote:
> Gleb Natapov wrote:
> >On Sun, Dec 20, 2009 at 09:11:18AM -0600, Anthony Liguori wrote:
> >>Gleb Natapov wrote:
> >>>On Sun, Dec 20, 2009 at 08:58:40AM -0600, Anthony Liguori wrote:
> >>>>No.  You have to physically shut down and start up again.  That's
> >>>>the right semantics IMHO.
> >>>>
> >>>Reset is equivalent (or should be) to shut down and start up again.
> >>Not at all.  Reset can happen in a lot of different ways, some that
> >We support only one way of reset: hard reset. It equivalent to full
> >HW power cycling. ACPI spec define ACPI reset as equivalent to HW power
> >cycling too BTW (see 4.7.3.6).
> 
> For every system periphereal?
To cite ACPI spec : "From an OSPM perspective, asserting the reset mechanism
is the logical equivalent to power cycling the machine."

>                                For instance, memory contents survive
> a reset whereas they won't survive a hard power down.
> 
We cannot rely on memory content after such reset.

> More importantly though, what's the use-case here?
> 
Use-case for what? This just what need to be done for correct HW
emulation.

> >This will work only if we assume that rom file size doesn't shrink,
> 
> Well the easy thing to do is hard code the rom size into qemu and
> throw an error if the rom size increases.  That way, if a rom does
> shrink, we're safe and if a rom size increases, we get an immediate
> run time error that gives the contributor feed back that they need
> to bump the constant.
> 

--
			Gleb.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] [PATCH 1/8] Support PCI based option rom loading
  2009-12-19 10:57   ` Blue Swirl
@ 2009-12-20 15:34     ` Anthony Liguori
  2009-12-20 17:02       ` Blue Swirl
  0 siblings, 1 reply; 84+ messages in thread
From: Anthony Liguori @ 2009-12-20 15:34 UTC (permalink / raw)
  To: Blue Swirl; +Cc: Anthony Liguori, seabios, Gerd Hoffmann, qemu-devel

Blue Swirl wrote:
> On Fri, Dec 18, 2009 at 11:01 AM, Gerd Hoffmann <kraxel@redhat.com> wrote:
>   
>> From: Anthony Liguori <aliguori@us.ibm.com>
>>
>> Currently, we preload option roms into the option rom space in memory.  This
>> prevents DDIM from functioning correctly which severely limits the number
>> of roms we can support.
>>
>> This patch introduces a pci_add_option_rom() which registers the
>> PCI_ROM_ADDRESS bar which points to our option rom.  It also converts over
>> the cirrus vga adapter, the rtl8139, virtio, and the e1000 to use this
>> new mechanism.
>>     
>
> This means that the VGA roms are now visible for all targets, not just
> when rom_enable_driver_roms is true. I'm not opposing this, but it may
> create regressions.
>   

This is pretty normal on bare metal though, no?  I thought a lot of 
non-x86 systems actually use x86 emulators specifically to enable 
support for these roms.

Regards,

Anthony Liguori

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-20 15:31               ` Anthony Liguori
@ 2009-12-20 15:35                 ` Avi Kivity
  0 siblings, 0 replies; 84+ messages in thread
From: Avi Kivity @ 2009-12-20 15:35 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: Gerd Hoffmann, Gleb Natapov, qemu-devel

On 12/20/2009 05:31 PM, Anthony Liguori wrote:
> Avi Kivity wrote:
>>> We should just qemu_ram_alloc() that memory regardless of whether we 
>>> every map it into the guest.  Since roms can be large, we want to 
>>> send their contents over during the live part of migration.  If we 
>>> use qemu_ram_alloc(), we get that for free.
>>
>> Currently live migration uses ram_addrs, so this would work.  But 
>> ram_addrs have no meaning in the guest and thus depend on qemu 
>> implementation details.  IMO we should switch live migration to use 
>> guest physical addresses, which would require a different migration 
>> implementation for roms.  Most of it can be shared with ram, though.
>
> I'd rather do (id, offset) instead of guest physical address.  Guest 
> physical addresses map to ram_addrs in chunks.  Each chunk usually has 
> some reasonable identification (below 640k, above 1mb, above 4gb, 
> etc.).  Other type of memory like roms and vga lfb memory aren't 
> always part of the guest physical address space but nonetheless still 
> need to be migrated.  This gives us one mechanism to support everything.
>

What about hotplugged memory?  I guess we can introduce the notion of 
user-visible memory slots; those exist on real hardware as well.  These 
slots would be different from the kvm memory slots, of course.

ids do have a nice property in that pci memory can be migrated while its 
BAR changes.  With gpa you'd need special handling.

-- 
error compiling committee.c: too many arguments to function

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-20 15:33                 ` Gleb Natapov
@ 2009-12-20 15:39                   ` Anthony Liguori
  2009-12-20 15:52                     ` Gleb Natapov
  2010-01-12  4:48                   ` Jamie Lokier
  1 sibling, 1 reply; 84+ messages in thread
From: Anthony Liguori @ 2009-12-20 15:39 UTC (permalink / raw)
  To: Gleb Natapov; +Cc: Gerd Hoffmann, qemu-devel

Gleb Natapov wrote:
>> More importantly though, what's the use-case here?
>>
>>     
> Use-case for what? This just what need to be done for correct HW
> emulation.
>   

Live migration is transparent to the guest.  The fact that firmware can 
upgrade itself without the guest doing anything is not something that 
really has a real world equivalent.

Even if it did, whether that automatic upgrade happens after a reboot 
vs. a hard power cycle is irrelevant.  The guest has no knowledge of the 
fact that the automatic firmware upgrade happened so if it gets delayed 
indefinitely, it doesn't matter.

It's not a matter of correctness IMHO.

I can understand an argument for predictability wrt wanted to be able to 
guarantee that after the first reboot during a live migration, you'll 
get the new firmware.  I'm not sure that's less predictable then hard 
shutdown/start-up and I'm not sure I can really make an argument for one 
way vs. the other.

If anything, I can better understand the argument for not ever upgrading 
the firmware transparently.  Something like having a nvram file that we 
load all of the ROMs into, then do live migration and migrate the nvram 
file.  That would mean that we would have to be very careful in the 
future about supporting fw_cfg as a versioned interface.

We would also want to provide a mechanism for a user to manually upgrade 
the firmware from within a guest if we went this route.

Regards,

Anthony Liguori

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-20 15:39                   ` Anthony Liguori
@ 2009-12-20 15:52                     ` Gleb Natapov
  2009-12-20 16:08                       ` Blue Swirl
  2009-12-20 17:48                       ` Anthony Liguori
  0 siblings, 2 replies; 84+ messages in thread
From: Gleb Natapov @ 2009-12-20 15:52 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: Gerd Hoffmann, qemu-devel

On Sun, Dec 20, 2009 at 09:39:38AM -0600, Anthony Liguori wrote:
> Gleb Natapov wrote:
> >>More importantly though, what's the use-case here?
> >>
> >Use-case for what? This just what need to be done for correct HW
> >emulation.
> 
> Live migration is transparent to the guest.  The fact that firmware
> can upgrade itself without the guest doing anything is not something
> that really has a real world equivalent.
> 
> Even if it did, whether that automatic upgrade happens after a
> reboot vs. a hard power cycle is irrelevant.  The guest has no
> knowledge of the fact that the automatic firmware upgrade happened
> so if it gets delayed indefinitely, it doesn't matter.
> 
> It's not a matter of correctness IMHO.
> 
Ah now I see what you mean. New FW has to be used after reboot because old
one may not be able to init HW any longer. Suppose some bug in cirrus
emulation has being fixed and old vga bios should be accommodated to
those changes, if old vga bios will run after reset video output may not
work. Thinking about it we'll have the same problem if migration happens
during vga bios loading, but this is MUCH less likely to happen.

> I can understand an argument for predictability wrt wanted to be
> able to guarantee that after the first reboot during a live
> migration, you'll get the new firmware.  I'm not sure that's less
> predictable then hard shutdown/start-up and I'm not sure I can
> really make an argument for one way vs. the other.
> 
system_reset _is_ hard shutdown/start-up. If it is not it is a bug, we
just arguing if the same applies for the case that migration was done
between boot and reset.

> If anything, I can better understand the argument for not ever
> upgrading the firmware transparently.  Something like having a nvram
> file that we load all of the ROMs into, then do live migration and
> migrate the nvram file.  That would mean that we would have to be
> very careful in the future about supporting fw_cfg as a versioned
> interface.
This will prevent us from fixing bugs/adding features.

> 
> We would also want to provide a mechanism for a user to manually
> upgrade the firmware from within a guest if we went this route.
> 
> Regards,
> 
> Anthony Liguori

--
			Gleb.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-20 15:52                     ` Gleb Natapov
@ 2009-12-20 16:08                       ` Blue Swirl
  2009-12-20 16:15                         ` Gleb Natapov
  2009-12-20 17:48                       ` Anthony Liguori
  1 sibling, 1 reply; 84+ messages in thread
From: Blue Swirl @ 2009-12-20 16:08 UTC (permalink / raw)
  To: Gleb Natapov; +Cc: Gerd Hoffmann, qemu-devel

On Sun, Dec 20, 2009 at 3:52 PM, Gleb Natapov <gleb@redhat.com> wrote:
> On Sun, Dec 20, 2009 at 09:39:38AM -0600, Anthony Liguori wrote:
>> Gleb Natapov wrote:
>> >>More importantly though, what's the use-case here?
>> >>
>> >Use-case for what? This just what need to be done for correct HW
>> >emulation.
>>
>> Live migration is transparent to the guest.  The fact that firmware
>> can upgrade itself without the guest doing anything is not something
>> that really has a real world equivalent.
>>
>> Even if it did, whether that automatic upgrade happens after a
>> reboot vs. a hard power cycle is irrelevant.  The guest has no
>> knowledge of the fact that the automatic firmware upgrade happened
>> so if it gets delayed indefinitely, it doesn't matter.
>>
>> It's not a matter of correctness IMHO.
>>
> Ah now I see what you mean. New FW has to be used after reboot because old
> one may not be able to init HW any longer. Suppose some bug in cirrus
> emulation has being fixed and old vga bios should be accommodated to
> those changes, if old vga bios will run after reset video output may not
> work. Thinking about it we'll have the same problem if migration happens
> during vga bios loading, but this is MUCH less likely to happen.
>
>> I can understand an argument for predictability wrt wanted to be
>> able to guarantee that after the first reboot during a live
>> migration, you'll get the new firmware.  I'm not sure that's less
>> predictable then hard shutdown/start-up and I'm not sure I can
>> really make an argument for one way vs. the other.
>>
> system_reset _is_ hard shutdown/start-up. If it is not it is a bug, we
> just arguing if the same applies for the case that migration was done
> between boot and reset.

Some devices are careful enough to implement warm reset using a flag,
see for example hw/sun4u.c. If you want more precision, you could
introduce for example system_off_on with the memory clearing behavior
you want.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-20 16:08                       ` Blue Swirl
@ 2009-12-20 16:15                         ` Gleb Natapov
  2009-12-20 16:23                           ` Blue Swirl
  0 siblings, 1 reply; 84+ messages in thread
From: Gleb Natapov @ 2009-12-20 16:15 UTC (permalink / raw)
  To: Blue Swirl; +Cc: Gerd Hoffmann, qemu-devel

On Sun, Dec 20, 2009 at 04:08:32PM +0000, Blue Swirl wrote:
> On Sun, Dec 20, 2009 at 3:52 PM, Gleb Natapov <gleb@redhat.com> wrote:
> > On Sun, Dec 20, 2009 at 09:39:38AM -0600, Anthony Liguori wrote:
> >> Gleb Natapov wrote:
> >> >>More importantly though, what's the use-case here?
> >> >>
> >> >Use-case for what? This just what need to be done for correct HW
> >> >emulation.
> >>
> >> Live migration is transparent to the guest.  The fact that firmware
> >> can upgrade itself without the guest doing anything is not something
> >> that really has a real world equivalent.
> >>
> >> Even if it did, whether that automatic upgrade happens after a
> >> reboot vs. a hard power cycle is irrelevant.  The guest has no
> >> knowledge of the fact that the automatic firmware upgrade happened
> >> so if it gets delayed indefinitely, it doesn't matter.
> >>
> >> It's not a matter of correctness IMHO.
> >>
> > Ah now I see what you mean. New FW has to be used after reboot because old
> > one may not be able to init HW any longer. Suppose some bug in cirrus
> > emulation has being fixed and old vga bios should be accommodated to
> > those changes, if old vga bios will run after reset video output may not
> > work. Thinking about it we'll have the same problem if migration happens
> > during vga bios loading, but this is MUCH less likely to happen.
> >
> >> I can understand an argument for predictability wrt wanted to be
> >> able to guarantee that after the first reboot during a live
> >> migration, you'll get the new firmware.  I'm not sure that's less
> >> predictable then hard shutdown/start-up and I'm not sure I can
> >> really make an argument for one way vs. the other.
> >>
> > system_reset _is_ hard shutdown/start-up. If it is not it is a bug, we
> > just arguing if the same applies for the case that migration was done
> > between boot and reset.
> 
> Some devices are careful enough to implement warm reset using a flag,
> see for example hw/sun4u.c. If you want more precision, you could
> introduce for example system_off_on with the memory clearing behavior
> you want.
I am not familiar with other architectures. All I am saying applies to
IBM PC only. Of course it is possible to design a system that impossible
to reset completely from software or by pushing reset button. (To design
general purpose computer like that one should be braindead though). On
IBM PC there are ways to reset different parts of the system and there
are ways to completely reset the system. We support only the later and
ACPI spec mandates this kind of reset if reset is done via ACPI.

--
			Gleb.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-20 16:15                         ` Gleb Natapov
@ 2009-12-20 16:23                           ` Blue Swirl
  0 siblings, 0 replies; 84+ messages in thread
From: Blue Swirl @ 2009-12-20 16:23 UTC (permalink / raw)
  To: Gleb Natapov; +Cc: Gerd Hoffmann, qemu-devel

2009/12/20 Gleb Natapov <gleb@redhat.com>:
> On Sun, Dec 20, 2009 at 04:08:32PM +0000, Blue Swirl wrote:
>> On Sun, Dec 20, 2009 at 3:52 PM, Gleb Natapov <gleb@redhat.com> wrote:
>> > On Sun, Dec 20, 2009 at 09:39:38AM -0600, Anthony Liguori wrote:
>> >> Gleb Natapov wrote:
>> >> >>More importantly though, what's the use-case here?
>> >> >>
>> >> >Use-case for what? This just what need to be done for correct HW
>> >> >emulation.
>> >>
>> >> Live migration is transparent to the guest.  The fact that firmware
>> >> can upgrade itself without the guest doing anything is not something
>> >> that really has a real world equivalent.
>> >>
>> >> Even if it did, whether that automatic upgrade happens after a
>> >> reboot vs. a hard power cycle is irrelevant.  The guest has no
>> >> knowledge of the fact that the automatic firmware upgrade happened
>> >> so if it gets delayed indefinitely, it doesn't matter.
>> >>
>> >> It's not a matter of correctness IMHO.
>> >>
>> > Ah now I see what you mean. New FW has to be used after reboot because old
>> > one may not be able to init HW any longer. Suppose some bug in cirrus
>> > emulation has being fixed and old vga bios should be accommodated to
>> > those changes, if old vga bios will run after reset video output may not
>> > work. Thinking about it we'll have the same problem if migration happens
>> > during vga bios loading, but this is MUCH less likely to happen.
>> >
>> >> I can understand an argument for predictability wrt wanted to be
>> >> able to guarantee that after the first reboot during a live
>> >> migration, you'll get the new firmware.  I'm not sure that's less
>> >> predictable then hard shutdown/start-up and I'm not sure I can
>> >> really make an argument for one way vs. the other.
>> >>
>> > system_reset _is_ hard shutdown/start-up. If it is not it is a bug, we
>> > just arguing if the same applies for the case that migration was done
>> > between boot and reset.
>>
>> Some devices are careful enough to implement warm reset using a flag,
>> see for example hw/sun4u.c. If you want more precision, you could
>> introduce for example system_off_on with the memory clearing behavior
>> you want.
> I am not familiar with other architectures. All I am saying applies to
> IBM PC only. Of course it is possible to design a system that impossible
> to reset completely from software or by pushing reset button. (To design
> general purpose computer like that one should be braindead though). On
> IBM PC there are ways to reset different parts of the system and there
> are ways to completely reset the system. We support only the later and
> ACPI spec mandates this kind of reset if reset is done via ACPI.

Then hw/pc.c could install a reset handler that clears all memory etc.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] [PATCH 1/8] Support PCI based option rom loading
  2009-12-20 15:34     ` Anthony Liguori
@ 2009-12-20 17:02       ` Blue Swirl
  2009-12-20 17:18         ` Alexander Graf
  0 siblings, 1 reply; 84+ messages in thread
From: Blue Swirl @ 2009-12-20 17:02 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: Anthony Liguori, seabios, Gerd Hoffmann, qemu-devel

On Sun, Dec 20, 2009 at 3:34 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Blue Swirl wrote:
>>
>> On Fri, Dec 18, 2009 at 11:01 AM, Gerd Hoffmann <kraxel@redhat.com> wrote:
>>
>>>
>>> From: Anthony Liguori <aliguori@us.ibm.com>
>>>
>>> Currently, we preload option roms into the option rom space in memory.
>>>  This
>>> prevents DDIM from functioning correctly which severely limits the number
>>> of roms we can support.
>>>
>>> This patch introduces a pci_add_option_rom() which registers the
>>> PCI_ROM_ADDRESS bar which points to our option rom.  It also converts
>>> over
>>> the cirrus vga adapter, the rtl8139, virtio, and the e1000 to use this
>>> new mechanism.
>>>
>>
>> This means that the VGA roms are now visible for all targets, not just
>> when rom_enable_driver_roms is true. I'm not opposing this, but it may
>> create regressions.
>>
>
> This is pretty normal on bare metal though, no?  I thought a lot of non-x86
> systems actually use x86 emulators specifically to enable support for these
> roms.

I think so too, but ROM loading was first introduced with
rom_enable_driver_roms mechanism just for cases like this.

But if there are no regressions, rom_enable_driver_roms mechanism
could be removed.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] [PATCH 1/8] Support PCI based option rom loading
  2009-12-20 17:02       ` Blue Swirl
@ 2009-12-20 17:18         ` Alexander Graf
  2009-12-20 17:55           ` Anthony Liguori
  0 siblings, 1 reply; 84+ messages in thread
From: Alexander Graf @ 2009-12-20 17:18 UTC (permalink / raw)
  To: Blue Swirl; +Cc: Anthony Liguori, seabios, Gerd Hoffmann, qemu-devel


On 20.12.2009, at 18:02, Blue Swirl wrote:

> On Sun, Dec 20, 2009 at 3:34 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
>> Blue Swirl wrote:
>>> 
>>> On Fri, Dec 18, 2009 at 11:01 AM, Gerd Hoffmann <kraxel@redhat.com> wrote:
>>> 
>>>> 
>>>> From: Anthony Liguori <aliguori@us.ibm.com>
>>>> 
>>>> Currently, we preload option roms into the option rom space in memory.
>>>>  This
>>>> prevents DDIM from functioning correctly which severely limits the number
>>>> of roms we can support.
>>>> 
>>>> This patch introduces a pci_add_option_rom() which registers the
>>>> PCI_ROM_ADDRESS bar which points to our option rom.  It also converts
>>>> over
>>>> the cirrus vga adapter, the rtl8139, virtio, and the e1000 to use this
>>>> new mechanism.
>>>> 
>>> 
>>> This means that the VGA roms are now visible for all targets, not just
>>> when rom_enable_driver_roms is true. I'm not opposing this, but it may
>>> create regressions.
>>> 
>> 
>> This is pretty normal on bare metal though, no?  I thought a lot of non-x86
>> systems actually use x86 emulators specifically to enable support for these
>> roms.
> 
> I think so too, but ROM loading was first introduced with
> rom_enable_driver_roms mechanism just for cases like this.
> 
> But if there are no regressions, rom_enable_driver_roms mechanism
> could be removed.

Don't macs usually have a powerpc vgabios?

I don't think we'd introduce regressions, just something you wouldn't find in a real machine. But then again the mac target isn't exactly that close to real hw anyways ...

Alex

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-20 15:52                     ` Gleb Natapov
  2009-12-20 16:08                       ` Blue Swirl
@ 2009-12-20 17:48                       ` Anthony Liguori
  2009-12-21  1:59                         ` Kevin O'Connor
  2009-12-21  7:40                         ` [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul Gleb Natapov
  1 sibling, 2 replies; 84+ messages in thread
From: Anthony Liguori @ 2009-12-20 17:48 UTC (permalink / raw)
  To: Gleb Natapov; +Cc: Gerd Hoffmann, qemu-devel

Gleb Natapov wrote:
>> It's not a matter of correctness IMHO.
>>
>>     
> Ah now I see what you mean. New FW has to be used after reboot because old
> one may not be able to init HW any longer.

I think we have two ways to view firmware.  The first would be to treat 
guest firmware as part of the guest.  What that means it that we should 
store all firmware in an nvram file, migrate the nvram file during 
migration, and provide a mechanism for the user to individually 
upgrade/replace the firmware.  We would never replace it from underneath 
the guest.  We only put things in nvram the first time it is 
initialized.  After that, it's entirely based on what the guest does.

On the one hand, this simplifies live migration, puts the user in more 
control over when there are firmware changes, gives us a very clear set 
of rules to follow with respect to compatibility.  On the other hand, it 
means we must provide backwards compatibility at the fw_cfg level and it 
means that any firmware upgrade has to be initiated by the user.  That 
means it's very likely that a user will not upgrade their firmware when 
upgrading qemu.  We could version the nvram and if we detect a guest 
image being moved between versions (without the use of -M xxx) we could 
automatically clear the nvram causing new firmware to be loaded.  Stable 
fixes for firmware though would require explicit action on the part of 
the guest.  This could be considered an advantage depending on your 
perspective.

The other option would be to treat guest firmware as part of the machine 
state.  The problem with this approach is that the firmware maintains 
state within the guest that qemu has no visibility into.  This makes it 
impossible for us to upgrade the firmware unless the guest is at a very 
well defined point in time (IOW, start-up or reset).  This has very 
different semantics than the rest of our machine and that's concerning.

I'm honestly on the fence about the two.  The first mechanism (nvram) is 
very appealing in that it matches hardware.  Having to rely on a guest 
to update it's firmware is concerning though.  The second mechanism is 
appealing from an ease of use perspective but the semantics of doing a 
live migration and getting a different firmware after reset/shutdown is 
rather scary from a support perspective.

>> I can understand an argument for predictability wrt wanted to be
>> able to guarantee that after the first reboot during a live
>> migration, you'll get the new firmware.  I'm not sure that's less
>> predictable then hard shutdown/start-up and I'm not sure I can
>> really make an argument for one way vs. the other.
>>
>>     
> system_reset _is_ hard shutdown/start-up. If it is not it is a bug, we
> just arguing if the same applies for the case that migration was done
> between boot and reset.
>   

It's not and it will never be completely.  By this logic, we should 
close the file descriptors for the block devices and try to reopen 
them.  It's certainly possible that someone does a mv of the block 
device and replaces it under the covers.

Likewise, if a user upgrades the firmware independently of the qemu 
version, it would need to reread the firmware from disk each boot.

Regards,

Anthony Liguori

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] [PATCH 1/8] Support PCI based option rom loading
  2009-12-20 17:18         ` Alexander Graf
@ 2009-12-20 17:55           ` Anthony Liguori
  2009-12-20 18:01             ` Alexander Graf
  0 siblings, 1 reply; 84+ messages in thread
From: Anthony Liguori @ 2009-12-20 17:55 UTC (permalink / raw)
  To: Alexander Graf; +Cc: Blue Swirl, seabios, Gerd Hoffmann, qemu-devel

Alexander Graf wrote:
> Don't macs usually have a powerpc vgabios?
>   
I'm not certain, but this is what x86emu is for in X11.

VGA is a PC concept and just about nothing about it really make sense on 
a different architecture.  The interface is an extension of the PC BIOS 
(software interrupts) and the dictated memory layouts are specific to 
the x86.  I think most non-x86 systems have to use native drivers for 
whatever graphics cards they support from the start.

Regards,

Anthony Liguori

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] [PATCH 1/8] Support PCI based option rom loading
  2009-12-20 17:55           ` Anthony Liguori
@ 2009-12-20 18:01             ` Alexander Graf
  2009-12-20 18:24               ` Andreas Färber
  2009-12-20 21:23               ` Benjamin Herrenschmidt
  0 siblings, 2 replies; 84+ messages in thread
From: Alexander Graf @ 2009-12-20 18:01 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: Blue Swirl, seabios, Gerd Hoffmann, QEMU Developers


On 20.12.2009, at 18:55, Anthony Liguori wrote:

> Alexander Graf wrote:
>> Don't macs usually have a powerpc vgabios?
>>  
> I'm not certain, but this is what x86emu is for in X11.
> 
> VGA is a PC concept and just about nothing about it really make sense on a different architecture.  The interface is an extension of the PC BIOS (software interrupts) and the dictated memory layouts are specific to the x86.  I think most non-x86 systems have to use native drivers for whatever graphics cards they support from the start.

Yes. The Alpha for example used stock VGABIOSes. IIRC Sparc has its own graphics anyways and I don't know about the others, but I suspect they either use x86 VGABIOSes or no VGABIOSes.

Macs are different though. IIRC they have a normal VGA interface in ppc logic, but I might be wrong. Maybe it's also some OpenFirmware stuff. They definitely don't have an x86 VGABIOS in the graphics card's rom slot, but something different.

Since we're using the Cirrus on Macs, I guess we'd need a Cirrus PPC VGABIOS - phew.

Other PPCs on the other hand, such as the Powerstation, use x86 roms.

Oh well, let's just export the x86 one for now but use video.x for video output. Looks like there'd be quite a lot of work involved in getting it aligned to real world mac hw :-(.

Alex

PS: Ben, please correct me if I'm wrong.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] [PATCH 1/8] Support PCI based option rom loading
  2009-12-20 18:01             ` Alexander Graf
@ 2009-12-20 18:24               ` Andreas Färber
  2009-12-20 18:53                 ` Blue Swirl
  2009-12-20 21:23               ` Benjamin Herrenschmidt
  1 sibling, 1 reply; 84+ messages in thread
From: Andreas Färber @ 2009-12-20 18:24 UTC (permalink / raw)
  To: Alexander Graf; +Cc: seabios, QEMU Developers, Blue Swirl, Gerd Hoffmann


Am 20.12.2009 um 19:01 schrieb Alexander Graf:

>
> On 20.12.2009, at 18:55, Anthony Liguori wrote:
>
>> Alexander Graf wrote:
>>> Don't macs usually have a powerpc vgabios?
>>>
>> I'm not certain, but this is what x86emu is for in X11.
>>
>> VGA is a PC concept and just about nothing about it really make  
>> sense on a different architecture.  The interface is an extension  
>> of the PC BIOS (software interrupts) and the dictated memory  
>> layouts are specific to the x86.  I think most non-x86 systems have  
>> to use native drivers for whatever graphics cards they support from  
>> the start.
>
> Yes. The Alpha for example used stock VGABIOSes. IIRC Sparc has its  
> own graphics anyways and I don't know about the others, but I  
> suspect they either use x86 VGABIOSes or no VGABIOSes.
>
> Macs are different though. IIRC they have a normal VGA interface in  
> ppc logic, but I might be wrong. Maybe it's also some OpenFirmware  
> stuff. They definitely don't have an x86 VGABIOS in the graphics  
> card's rom slot, but something different.
>
> Since we're using the Cirrus on Macs, I guess we'd need a Cirrus PPC  
> VGABIOS - phew.

ATI used to sell special "Mac Edition" graphics cards. That would seem  
to back up the possibility of a ppc VGABIOS on Mac.

Never tried putting such a card into a PC though or vice versa. Maybe  
we'd get the same sick-coloured penguins then...? ;)

Andreas

> Other PPCs on the other hand, such as the Powerstation, use x86 roms.
>
> Oh well, let's just export the x86 one for now but use video.x for  
> video output. Looks like there'd be quite a lot of work involved in  
> getting it aligned to real world mac hw :-(.
>
> Alex
>
> PS: Ben, please correct me if I'm wrong.
>

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] [PATCH 1/8] Support PCI based option rom loading
  2009-12-20 18:24               ` Andreas Färber
@ 2009-12-20 18:53                 ` Blue Swirl
  2009-12-20 21:24                   ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 84+ messages in thread
From: Blue Swirl @ 2009-12-20 18:53 UTC (permalink / raw)
  To: Andreas Färber
  Cc: seabios, QEMU Developers, Alexander Graf, Gerd Hoffmann

On Sun, Dec 20, 2009 at 6:24 PM, Andreas Färber <andreas.faerber@web.de> wrote:
>
> Am 20.12.2009 um 19:01 schrieb Alexander Graf:
>
>>
>> On 20.12.2009, at 18:55, Anthony Liguori wrote:
>>
>>> Alexander Graf wrote:
>>>>
>>>> Don't macs usually have a powerpc vgabios?
>>>>
>>> I'm not certain, but this is what x86emu is for in X11.
>>>
>>> VGA is a PC concept and just about nothing about it really make sense on
>>> a different architecture.  The interface is an extension of the PC BIOS
>>> (software interrupts) and the dictated memory layouts are specific to the
>>> x86.  I think most non-x86 systems have to use native drivers for whatever
>>> graphics cards they support from the start.
>>
>> Yes. The Alpha for example used stock VGABIOSes. IIRC Sparc has its own
>> graphics anyways and I don't know about the others, but I suspect they
>> either use x86 VGABIOSes or no VGABIOSes.
>>
>> Macs are different though. IIRC they have a normal VGA interface in ppc
>> logic, but I might be wrong. Maybe it's also some OpenFirmware stuff. They
>> definitely don't have an x86 VGABIOS in the graphics card's rom slot, but
>> something different.
>>
>> Since we're using the Cirrus on Macs, I guess we'd need a Cirrus PPC
>> VGABIOS - phew.
>
> ATI used to sell special "Mac Edition" graphics cards. That would seem to
> back up the possibility of a ppc VGABIOS on Mac.

Some Sun machines also had "ATY,Rage XL" cards but I don't know if
they had special roms.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] [PATCH 1/8] Support PCI based option rom loading
  2009-12-20 18:01             ` Alexander Graf
  2009-12-20 18:24               ` Andreas Färber
@ 2009-12-20 21:23               ` Benjamin Herrenschmidt
  1 sibling, 0 replies; 84+ messages in thread
From: Benjamin Herrenschmidt @ 2009-12-20 21:23 UTC (permalink / raw)
  To: Alexander Graf; +Cc: Blue Swirl, seabios, Gerd Hoffmann, QEMU Developers

On Sun, 2009-12-20 at 19:01 +0100, Alexander Graf wrote:
> 
> Yes. The Alpha for example used stock VGABIOSes. IIRC Sparc has its
> own graphics anyways and I don't know about the others, but I suspect
> they either use x86 VGABIOSes or no VGABIOSes.
> 
> Macs are different though. IIRC they have a normal VGA interface in
> ppc logic, but I might be wrong. Maybe it's also some OpenFirmware
> stuff. They definitely don't have an x86 VGABIOS in the graphics
> card's rom slot, but something different.
> 
> Since we're using the Cirrus on Macs, I guess we'd need a Cirrus PPC
> VGABIOS - phew.
> 
> Other PPCs on the other hand, such as the Powerstation, use x86 roms.
> 
> Oh well, let's just export the x86 one for now but use video.x for
> video output. Looks like there'd be quite a lot of work involved in
> getting it aligned to real world mac hw :-(.

Hrm, I missed the beginning of the story :-) But basically here's what
things look like vs. option ROMs on powerpc:

 - Most Open Firmware based machines (pSeries and Macs) can load some
f-code firmware from there (tokenized forth). The f-code is platform
agnostic (in theory, Apple did play games in that area) and so in theory
the same f-code would work on, for example, an x86 with Open Firmware
(if you had a slot on the OLPC you could try :-)

 - That f-code firmware is used for whatever initializations the card
need (for example, video cards generally need specific inits before
being usable at all by the OS, at least older ones do). It can create
additional properties in the device-tree as well.

 - On Macs specifically, they have a trick consisting of putting a
powerpc MacOS video driver in there, in the form of one big property
(AAPL,NDRV iirc). This is a MacOS 7/8/9 style PEF driver but generally
compiled and linked to work in a very limited environment for which OS X
provides a sandbox, and which provides basic monitor detection and mode
settings. video.x is such a driver (I wrote it :-) though I don't
remember precisely whether the video.x file is the raw NDRV or the
packaged f-code which contains the ndrv).

 - Some powerpc machines (Pegasos, Efika, PowerStation, ... ) also have
an x86emu variant in their firmware that can load a VGA ROM and use it
to setup some kind of boot display for the firmware.

 - An option ROM can contain multiple images :-) IE. It can contain
-both- the x86 style ROM and the Open Firmware style f-code...

Now, in the light of the above, what is interesting to do on qemu ?

It all depends how "close" we consider OpenBIOS to be from qemu. If
"close" then we don't need any of the f-code stuff. OpenBIOS could use
some private calls to inside qemu and be done with it, including for
sucking the video.x MacOS driver if the machine "profile" is a Mac (see
the discussions on using the device-tree to define machines inside qemu,
I believe that would be a great improvement).

A VGA ROM is not really useful past the firmware stage on ppc, as
generally X is built without Int10 and we cannot really do anything with
it appart from the FW initializing the card. This is not true of real
ATI or nVidia cards because their driver uses tables in the VGA ROM for
various things but that isn't necessarily very useful for qemu. But on
the other hand, it doesn't hurt to have it there.

We should also look formward to native flat device tree booting without
OpenBIOS in which case we probably don't care much (though again a VGA
ROM might prove useful if whatever we boot has an x86emu variant).

Cheers,
Ben.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] [PATCH 1/8] Support PCI based option rom loading
  2009-12-20 18:53                 ` Blue Swirl
@ 2009-12-20 21:24                   ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 84+ messages in thread
From: Benjamin Herrenschmidt @ 2009-12-20 21:24 UTC (permalink / raw)
  To: Blue Swirl
  Cc: seabios, QEMU Developers, Alexander Graf, Andreas Färber,
	Gerd Hoffmann

On Sun, 2009-12-20 at 18:53 +0000, Blue Swirl wrote:
> 
> Some Sun machines also had "ATY,Rage XL" cards but I don't know if
> they had special roms. 

They would have similar f-code to the mac ones (ie. Tokenized forth for
Open Firmware).

However, in the case of qemu, I don't see much point in doing so for the
sake of OpenBIOS :-)

Cheers
Ben.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-20 17:48                       ` Anthony Liguori
@ 2009-12-21  1:59                         ` Kevin O'Connor
  2009-12-21  7:32                           ` Gleb Natapov
  2009-12-21  7:40                         ` [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul Gleb Natapov
  1 sibling, 1 reply; 84+ messages in thread
From: Kevin O'Connor @ 2009-12-21  1:59 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: Gerd Hoffmann, Gleb Natapov, qemu-devel

On Sun, Dec 20, 2009 at 11:48:20AM -0600, Anthony Liguori wrote:
> I think we have two ways to view firmware.  The first would be to treat  
> guest firmware as part of the guest.  What that means it that we should  
> store all firmware in an nvram file, migrate the nvram file during  
> migration
[...]
> The other option would be to treat guest firmware as part of the machine  
> state.

How about mixing the two?  Store the firmware in an nvram file and
migrate it during migration, but clear the nvram and reload the
firmware on each start-up and qemu reset.

[...]
>The second mechanism is  
> appealing from an ease of use perspective but the semantics of doing a  
> live migration and getting a different firmware after reset/shutdown is  
> rather scary from a support perspective.

I'm not sure I see the problem with upgrading firmware on a reboot.  I
think it would be a pretty severe bug if a new firmware broke the OS
or if an OS was heavily dependent on a specific firmware across
reboots.  After all, normal users update their bios and reboot into
pre-existing OSs all the time.

-Kevin

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-21  1:59                         ` Kevin O'Connor
@ 2009-12-21  7:32                           ` Gleb Natapov
  2009-12-21 16:40                             ` Anthony Liguori
  0 siblings, 1 reply; 84+ messages in thread
From: Gleb Natapov @ 2009-12-21  7:32 UTC (permalink / raw)
  To: Kevin O'Connor; +Cc: Gerd Hoffmann, qemu-devel

On Sun, Dec 20, 2009 at 08:59:48PM -0500, Kevin O'Connor wrote:
> On Sun, Dec 20, 2009 at 11:48:20AM -0600, Anthony Liguori wrote:
> > I think we have two ways to view firmware.  The first would be to treat  
> > guest firmware as part of the guest.  What that means it that we should  
> > store all firmware in an nvram file, migrate the nvram file during  
> > migration
> [...]
> > The other option would be to treat guest firmware as part of the machine  
> > state.
> 
> How about mixing the two?  Store the firmware in an nvram file and
> migrate it during migration, but clear the nvram and reload the
> firmware on each start-up and qemu reset.
> 
That's precisely what I propose.

> [...]
> >The second mechanism is  
> > appealing from an ease of use perspective but the semantics of doing a  
> > live migration and getting a different firmware after reset/shutdown is  
> > rather scary from a support perspective.
> 
> I'm not sure I see the problem with upgrading firmware on a reboot.  I
> think it would be a pretty severe bug if a new firmware broke the OS
> or if an OS was heavily dependent on a specific firmware across
> reboots.  After all, normal users update their bios and reboot into
> pre-existing OSs all the time.
> 
Exactly.

--
			Gleb.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-20 17:48                       ` Anthony Liguori
  2009-12-21  1:59                         ` Kevin O'Connor
@ 2009-12-21  7:40                         ` Gleb Natapov
  2009-12-21 17:27                           ` Michael S. Tsirkin
  1 sibling, 1 reply; 84+ messages in thread
From: Gleb Natapov @ 2009-12-21  7:40 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: Gerd Hoffmann, qemu-devel

On Sun, Dec 20, 2009 at 11:48:20AM -0600, Anthony Liguori wrote:
> >system_reset _is_ hard shutdown/start-up. If it is not it is a bug, we
> >just arguing if the same applies for the case that migration was done
> >between boot and reset.
> 
> It's not and it will never be completely.
There are always bugs left. As long as we agree on what is right that is
OK.

>                                            By this logic, we should
> close the file descriptors for the block devices and try to reopen
> them.  It's certainly possible that someone does a mv of the block
> device and replaces it under the covers.
What is the analogue in real HW? BTW it is not a bad idea to get
notification when disk file has changed and issue "change device"
automatically.

> 
> Likewise, if a user upgrades the firmware independently of the qemu
> version, it would need to reread the firmware from disk each boot.
> 
That's the idea. Qemu should reread firmware from disk on each hard reset.

--
			Gleb.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-21  7:32                           ` Gleb Natapov
@ 2009-12-21 16:40                             ` Anthony Liguori
  2009-12-21 16:43                               ` Gleb Natapov
  0 siblings, 1 reply; 84+ messages in thread
From: Anthony Liguori @ 2009-12-21 16:40 UTC (permalink / raw)
  To: Gleb Natapov; +Cc: Kevin O'Connor, Gerd Hoffmann, qemu-devel

On 12/21/2009 01:32 AM, Gleb Natapov wrote:
> On Sun, Dec 20, 2009 at 08:59:48PM -0500, Kevin O'Connor wrote:
>    
>> On Sun, Dec 20, 2009 at 11:48:20AM -0600, Anthony Liguori wrote:
>>      
>>> I think we have two ways to view firmware.  The first would be to treat
>>> guest firmware as part of the guest.  What that means it that we should
>>> store all firmware in an nvram file, migrate the nvram file during
>>> migration
>>>        
>> [...]
>>      
>>> The other option would be to treat guest firmware as part of the machine
>>> state.
>>>        
>> How about mixing the two?  Store the firmware in an nvram file and
>> migrate it during migration, but clear the nvram and reload the
>> firmware on each start-up and qemu reset.
>>
>>      
> That's precisely what I propose.
>    

There are some really ugly corner cases here.  For instance, guest is 
running and the user does a yum update which upgrades the qemu package.  
This includes laying down a new bios.

User eventually restarts guest, now we re-read BIOS and we're on a newer 
BIOS than the device model.  Badness ensues.

And more importantly, what is the end-user benefit of doing this?

Regards,

Anthony Liguori

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-21 16:40                             ` Anthony Liguori
@ 2009-12-21 16:43                               ` Gleb Natapov
  2009-12-21 17:26                                 ` Anthony Liguori
  0 siblings, 1 reply; 84+ messages in thread
From: Gleb Natapov @ 2009-12-21 16:43 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: Kevin O'Connor, Gerd Hoffmann, qemu-devel

On Mon, Dec 21, 2009 at 10:40:56AM -0600, Anthony Liguori wrote:
> On 12/21/2009 01:32 AM, Gleb Natapov wrote:
> >On Sun, Dec 20, 2009 at 08:59:48PM -0500, Kevin O'Connor wrote:
> >>On Sun, Dec 20, 2009 at 11:48:20AM -0600, Anthony Liguori wrote:
> >>>I think we have two ways to view firmware.  The first would be to treat
> >>>guest firmware as part of the guest.  What that means it that we should
> >>>store all firmware in an nvram file, migrate the nvram file during
> >>>migration
> >>[...]
> >>>The other option would be to treat guest firmware as part of the machine
> >>>state.
> >>How about mixing the two?  Store the firmware in an nvram file and
> >>migrate it during migration, but clear the nvram and reload the
> >>firmware on each start-up and qemu reset.
> >>
> >That's precisely what I propose.
> 
> There are some really ugly corner cases here.  For instance, guest
> is running and the user does a yum update which upgrades the qemu
> package.  This includes laying down a new bios.
> 
> User eventually restarts guest, now we re-read BIOS and we're on a
> newer BIOS than the device model.  Badness ensues.
> 
My package manager warns me that certain application need to be
restarted to work correctly after upgrade. This is hardly qemu specific
problem.

> And more importantly, what is the end-user benefit of doing this?
> 
Working migration?

--
			Gleb.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-21 16:43                               ` Gleb Natapov
@ 2009-12-21 17:26                                 ` Anthony Liguori
  2009-12-21 17:43                                   ` Gleb Natapov
  0 siblings, 1 reply; 84+ messages in thread
From: Anthony Liguori @ 2009-12-21 17:26 UTC (permalink / raw)
  To: Gleb Natapov; +Cc: Kevin O'Connor, Gerd Hoffmann, qemu-devel

On 12/21/2009 10:43 AM, Gleb Natapov wrote:
>> There are some really ugly corner cases here.  For instance, guest
>> is running and the user does a yum update which upgrades the qemu
>> package.  This includes laying down a new bios.
>>
>> User eventually restarts guest, now we re-read BIOS and we're on a
>> newer BIOS than the device model.  Badness ensues.
>>
>>      
> My package manager warns me that certain application need to be
> restarted to work correctly after upgrade. This is hardly qemu specific
> problem.
>    

But again, I don't see when this is ever a feature that a user actually 
wants.  Unless you change restart to fork/exec+exit, you'll never have 
reset equivalent to power off + startup.  Can you advocate rereading 
roms and not advocate re-execing qemu?

>> And more importantly, what is the end-user benefit of doing this?
>>
>>      
> Working migration?
>    

How does it fix migration?  Migration needs to transfer the current roms 
in order to work.  A new version of qemu must support interacting with 
the old version of the firmware for migration to work.  What happens 
after reset has nothing to do with migration but because of the last 
requirement, the guest will obviously continue to work after reboot too.

Regards,

Anthony Liguori

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-21  7:40                         ` [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul Gleb Natapov
@ 2009-12-21 17:27                           ` Michael S. Tsirkin
  0 siblings, 0 replies; 84+ messages in thread
From: Michael S. Tsirkin @ 2009-12-21 17:27 UTC (permalink / raw)
  To: Gleb Natapov; +Cc: Gerd Hoffmann, qemu-devel

On Mon, Dec 21, 2009 at 09:40:47AM +0200, Gleb Natapov wrote:
> On Sun, Dec 20, 2009 at 11:48:20AM -0600, Anthony Liguori wrote:
> > >system_reset _is_ hard shutdown/start-up. If it is not it is a bug, we
> > >just arguing if the same applies for the case that migration was done
> > >between boot and reset.
> > 
> > It's not and it will never be completely.
> There are always bugs left. As long as we agree on what is right that is
> OK.
> 
> >                                            By this logic, we should
> > close the file descriptors for the block devices and try to reopen
> > them.  It's certainly possible that someone does a mv of the block
> > device and replaces it under the covers.
> What is the analogue in real HW? BTW it is not a bad idea to get
> notification when disk file has changed and issue "change device"
> automatically.
> 
> > 
> > Likewise, if a user upgrades the firmware independently of the qemu
> > version, it would need to reread the firmware from disk each boot.
> > 
> That's the idea. Qemu should reread firmware from disk on each hard reset.

We could have another copy in memory if we are concerned about being consistent,
reset firmware to that on reboot.

> --
> 			Gleb.
> 

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-21 17:26                                 ` Anthony Liguori
@ 2009-12-21 17:43                                   ` Gleb Natapov
  2009-12-21 18:24                                     ` [Qemu-devel] Re: Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul Sebastian Herbszt
  2009-12-21 19:13                                     ` [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul Anthony Liguori
  0 siblings, 2 replies; 84+ messages in thread
From: Gleb Natapov @ 2009-12-21 17:43 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: Kevin O'Connor, Gerd Hoffmann, qemu-devel

On Mon, Dec 21, 2009 at 11:26:12AM -0600, Anthony Liguori wrote:
> On 12/21/2009 10:43 AM, Gleb Natapov wrote:
> >>There are some really ugly corner cases here.  For instance, guest
> >>is running and the user does a yum update which upgrades the qemu
> >>package.  This includes laying down a new bios.
> >>
> >>User eventually restarts guest, now we re-read BIOS and we're on a
> >>newer BIOS than the device model.  Badness ensues.
> >>
> >My package manager warns me that certain application need to be
> >restarted to work correctly after upgrade. This is hardly qemu specific
> >problem.
> 
> But again, I don't see when this is ever a feature that a user
> actually wants.  Unless you change restart to fork/exec+exit, you'll
> never have reset equivalent to power off + startup.  Can you
> advocate rereading roms and not advocate re-execing qemu?
Why I will never have reset equivalent to power off + startup? Are you
saying we are not capable of implementing spec correctly?

> >>And more importantly, what is the end-user benefit of doing this?
> >>
> >Working migration?
> 
> How does it fix migration? Migration needs to transfer the current
> roms in order to work.  A new version of qemu must support
> interacting with the old version of the firmware for migration to
> work.  What happens after reset has nothing to do with migration but
> because of the last requirement, the guest will obviously continue
> to work after reboot too.
I don't agree with your last requirement. Firmware goes hand in hand with
HW. Change that is only FW visible should not be backwards compatible.

--
			Gleb.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.
  2009-12-21 17:43                                   ` Gleb Natapov
@ 2009-12-21 18:24                                     ` Sebastian Herbszt
  2009-12-21 18:36                                       ` Gleb Natapov
  2009-12-21 19:17                                       ` [Qemu-devel] " Anthony Liguori
  2009-12-21 19:13                                     ` [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul Anthony Liguori
  1 sibling, 2 replies; 84+ messages in thread
From: Sebastian Herbszt @ 2009-12-21 18:24 UTC (permalink / raw)
  To: Gleb Natapov, Anthony Liguori
  Cc: Kevin O'Connor, Gerd Hoffmann, qemu-devel

Gleb Natapov wrote:
> On Mon, Dec 21, 2009 at 11:26:12AM -0600, Anthony Liguori wrote:
>> On 12/21/2009 10:43 AM, Gleb Natapov wrote:
>> >>There are some really ugly corner cases here.  For instance, guest
>> >>is running and the user does a yum update which upgrades the qemu
>> >>package.  This includes laying down a new bios.
>> >>
>> >>User eventually restarts guest, now we re-read BIOS and we're on a
>> >>newer BIOS than the device model.  Badness ensues.
>> >>
>> >My package manager warns me that certain application need to be
>> >restarted to work correctly after upgrade. This is hardly qemu specific
>> >problem.
>> 
>> But again, I don't see when this is ever a feature that a user
>> actually wants.  Unless you change restart to fork/exec+exit, you'll
>> never have reset equivalent to power off + startup.  Can you
>> advocate rereading roms and not advocate re-execing qemu?
> Why I will never have reset equivalent to power off + startup? Are you
> saying we are not capable of implementing spec correctly?

In the "POST failure (loop) with isapc and seabios" thread we have concluded
that the "system_reset" monitor command should trigger a power cycle, but
it currently doesn't. This same power cycle logic has to be implemented for ACPI
reset.

>> >>And more importantly, what is the end-user benefit of doing this?
>> >>
>> >Working migration?
>> 
>> How does it fix migration? Migration needs to transfer the current
>> roms in order to work.  A new version of qemu must support
>> interacting with the old version of the firmware for migration to
>> work.  What happens after reset has nothing to do with migration but
>> because of the last requirement, the guest will obviously continue
>> to work after reboot too.
> I don't agree with your last requirement. Firmware goes hand in hand with
> HW. Change that is only FW visible should not be backwards compatible.

As stated before i don't like the idea of automagically upgrading the firmware
on reset, e.g. after a live migration to a newer qemu version. You have explained
that qemu-kvm needs this in order to work with live migration and changed hw
support because of bug fixes. Is this only needed in the kvm case?

Does any OS (Windows?) depend on the tables the bios creates (e.g. smbios)
for licensing? It would be ugly if Windows wants you to re-activate after a reboot
following a migration to newer qemu version and therefore possibly changed tables
due to newer bios.

- Sebastian

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.
  2009-12-21 18:24                                     ` [Qemu-devel] Re: Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul Sebastian Herbszt
@ 2009-12-21 18:36                                       ` Gleb Natapov
  2009-12-21 19:28                                         ` Sebastian Herbszt
  2009-12-21 19:17                                       ` [Qemu-devel] " Anthony Liguori
  1 sibling, 1 reply; 84+ messages in thread
From: Gleb Natapov @ 2009-12-21 18:36 UTC (permalink / raw)
  To: Sebastian Herbszt; +Cc: Kevin O'Connor, Gerd Hoffmann, qemu-devel

On Mon, Dec 21, 2009 at 07:24:43PM +0100, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
> >On Mon, Dec 21, 2009 at 11:26:12AM -0600, Anthony Liguori wrote:
> >>On 12/21/2009 10:43 AM, Gleb Natapov wrote:
> >>>>There are some really ugly corner cases here.  For instance, guest
> >>>>is running and the user does a yum update which upgrades the qemu
> >>>>package.  This includes laying down a new bios.
> >>>>
> >>>>User eventually restarts guest, now we re-read BIOS and we're on a
> >>>>newer BIOS than the device model.  Badness ensues.
> >>>>
> >>>My package manager warns me that certain application need to be
> >>>restarted to work correctly after upgrade. This is hardly qemu specific
> >>>problem.
> >>
> >>But again, I don't see when this is ever a feature that a user
> >>actually wants.  Unless you change restart to fork/exec+exit, you'll
> >>never have reset equivalent to power off + startup.  Can you
> >>advocate rereading roms and not advocate re-execing qemu?
> >Why I will never have reset equivalent to power off + startup? Are you
> >saying we are not capable of implementing spec correctly?
> 
> In the "POST failure (loop) with isapc and seabios" thread we have concluded
> that the "system_reset" monitor command should trigger a power cycle, but
> it currently doesn't. This same power cycle logic has to be implemented for ACPI
> reset.
> 
It currently tries to do that, but state after reset is not exactly the
same as after qemu start. Each and every such difference is an instance
of a bug.

> >>>>And more importantly, what is the end-user benefit of doing this?
> >>>>
> >>>Working migration?
> >>
> >>How does it fix migration? Migration needs to transfer the current
> >>roms in order to work.  A new version of qemu must support
> >>interacting with the old version of the firmware for migration to
> >>work.  What happens after reset has nothing to do with migration but
> >>because of the last requirement, the guest will obviously continue
> >>to work after reboot too.
> >I don't agree with your last requirement. Firmware goes hand in hand with
> >HW. Change that is only FW visible should not be backwards compatible.
> 
> As stated before i don't like the idea of automagically upgrading the firmware
> on reset, e.g. after a live migration to a newer qemu version. You have explained
> that qemu-kvm needs this in order to work with live migration and changed hw
> support because of bug fixes. Is this only needed in the kvm case?
> 
There basically two approaches. One is you allow HW to change in such a
way that new FW is needed to init it and then you have to reload newer
FW after migration or you disallow HW changes that will prevent
old FW from configuring it and then you can use old FW after migration.

This is nothing special for KVM.

> Does any OS (Windows?) depend on the tables the bios creates (e.g. smbios)
> for licensing? It would be ugly if Windows wants you to re-activate after a reboot
> following a migration to newer qemu version and therefore possibly changed tables
> due to newer bios.
> 
I am not talking about OS visible stuff.

--
			Gleb.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-21 17:43                                   ` Gleb Natapov
  2009-12-21 18:24                                     ` [Qemu-devel] Re: Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul Sebastian Herbszt
@ 2009-12-21 19:13                                     ` Anthony Liguori
  2009-12-21 19:43                                       ` Gleb Natapov
  1 sibling, 1 reply; 84+ messages in thread
From: Anthony Liguori @ 2009-12-21 19:13 UTC (permalink / raw)
  To: Gleb Natapov; +Cc: Kevin O'Connor, Gerd Hoffmann, qemu-devel

On 12/21/2009 11:43 AM, Gleb Natapov wrote:
> Why I will never have reset equivalent to power off + startup? Are you
> saying we are not capable of implementing spec correctly?
>    

No, I'm saying that if you want reset absolutely equivalent to power off 
+ startup, then you need to fork() and re-exec qemu at startup since the 
qemu binary may have changed while the guest was running.

My point behind this is I think that's equivalent to re-reading rom 
contents from disk.

>>>> And more importantly, what is the end-user benefit of doing this?
>>>>
>>>>          
>>> Working migration?
>>>        
>> How does it fix migration? Migration needs to transfer the current
>> roms in order to work.  A new version of qemu must support
>> interacting with the old version of the firmware for migration to
>> work.  What happens after reset has nothing to do with migration but
>> because of the last requirement, the guest will obviously continue
>> to work after reboot too.
>>      
> I don't agree with your last requirement. Firmware goes hand in hand with
> HW. Change that is only FW visible should not be backwards compatible.
>    

I think we're papering over this issue.  FW interfaces are guest visible 
even though we've been pretending like they aren't.

SeaBIOS does not implement every possible BIOS function.  I'm sure that 
it will implement new functions over time.  The presence of those 
functions are certainly visible to the guest.  Likewise, any bug or 
added feature is visible to a guest.

More concretely, we have an internal OS that interacts very closely with 
PXE roms (it makes use of UNDI).  It's very aware of the difference 
between etherboot and gPXE and it is also aware of different versions of 
those two.

The arguments for saying FW is not guest visible is that FW interfaces 
are well defined and do not change.  The same is true for 99% of the 
hardware we emulate.  The reason we have guest visible changes is that 
we're constantly improving and increasing the functionality of the 
hardware.  The same is true for FW.

I'm starting to think having an nvram with saved firmware and user 
driven upgrades is the best approach for compatibility by far.  I'm 
still concerned though about the relatively complexity of having to 
force users to upgrade their firmware.

Regards,

Anthony Liguori

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.
  2009-12-21 18:24                                     ` [Qemu-devel] Re: Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul Sebastian Herbszt
  2009-12-21 18:36                                       ` Gleb Natapov
@ 2009-12-21 19:17                                       ` Anthony Liguori
  2009-12-21 19:39                                         ` Sebastian Herbszt
  2009-12-21 19:48                                         ` Gleb Natapov
  1 sibling, 2 replies; 84+ messages in thread
From: Anthony Liguori @ 2009-12-21 19:17 UTC (permalink / raw)
  To: Sebastian Herbszt
  Cc: Kevin O'Connor, Gerd Hoffmann, Gleb Natapov, qemu-devel

On 12/21/2009 12:24 PM, Sebastian Herbszt wrote:
> As stated before i don't like the idea of automagically upgrading the 
> firmware
> on reset, e.g. after a live migration to a newer qemu version. You 
> have explained
> that qemu-kvm needs this in order to work with live migration and 
> changed hw
> support because of bug fixes. Is this only needed in the kvm case?

It's not "needed", it's desired.  The same case can be made for real 
hardware (automated firmware updates).

> Does any OS (Windows?) depend on the tables the bios creates (e.g. 
> smbios)
> for licensing? It would be ugly if Windows wants you to re-activate 
> after a reboot
> following a migration to newer qemu version and therefore possibly 
> changed tables
> due to newer bios.

Yes, and this is a good point.  ACPI table changes can absolutely cause 
re-activation.  If we migrate from 0.12 -> 0.13 and make major changes 
to the ACPI tables in 0.13, then it's very likely that will result in 
problems for Windows guests.

I really think that we need to snapshot the FW and store it with the 
guest state.  If we switch all FW to be allocated with qemu_ram_alloc() 
and we use an id mechanism, then this will Just Work for savevm based 
snapshots and live migration.  However, for it to work with -M pc-0.11 
started from a cold boot, we need an nvram file.  We probably want to 
make available versioned nvram files from each release too.

Regards,

Anthony Liguori

>
> - Sebastian
>

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.
  2009-12-21 18:36                                       ` Gleb Natapov
@ 2009-12-21 19:28                                         ` Sebastian Herbszt
  2009-12-21 19:57                                           ` Gleb Natapov
  0 siblings, 1 reply; 84+ messages in thread
From: Sebastian Herbszt @ 2009-12-21 19:28 UTC (permalink / raw)
  To: Gleb Natapov; +Cc: Kevin O'Connor, Gerd Hoffmann, qemu-devel

Gleb Natapov wrote:
> On Mon, Dec 21, 2009 at 07:24:43PM +0100, Sebastian Herbszt wrote:
>> Does any OS (Windows?) depend on the tables the bios creates (e.g. smbios)
>> for licensing? It would be ugly if Windows wants you to re-activate after a reboot
>> following a migration to newer qemu version and therefore possibly changed tables
>> due to newer bios.
>> 
> I am not talking about OS visible stuff.

How do you want to avoid OS visible changes if the bios is reread on each reset? People
can upgrade/change their bios in the pc-bios directory and bad things could happen if its
reloaded on each reset.

- Sebastian

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.
  2009-12-21 19:17                                       ` [Qemu-devel] " Anthony Liguori
@ 2009-12-21 19:39                                         ` Sebastian Herbszt
  2009-12-21 19:53                                           ` Gleb Natapov
  2009-12-21 19:48                                         ` Gleb Natapov
  1 sibling, 1 reply; 84+ messages in thread
From: Sebastian Herbszt @ 2009-12-21 19:39 UTC (permalink / raw)
  To: Anthony Liguori
  Cc: Kevin O'Connor, Gerd Hoffmann, Gleb Natapov, qemu-devel

Anthony Liguori wrote:
> On 12/21/2009 12:24 PM, Sebastian Herbszt wrote:
>> As stated before i don't like the idea of automagically upgrading the 
>> firmware
>> on reset, e.g. after a live migration to a newer qemu version. You 
>> have explained
>> that qemu-kvm needs this in order to work with live migration and 
>> changed hw
>> support because of bug fixes. Is this only needed in the kvm case?
> 
> It's not "needed", it's desired.  The same case can be made for real 
> hardware (automated firmware updates).

Tho on real hardware those updates are initiated by someone and not
automagic.

>> Does any OS (Windows?) depend on the tables the bios creates (e.g. 
>> smbios)
>> for licensing? It would be ugly if Windows wants you to re-activate 
>> after a reboot
>> following a migration to newer qemu version and therefore possibly 
>> changed tables
>> due to newer bios.
> 
> Yes, and this is a good point.  ACPI table changes can absolutely cause 
> re-activation.  If we migrate from 0.12 -> 0.13 and make major changes 
> to the ACPI tables in 0.13, then it's very likely that will result in 
> problems for Windows guests.

Another problem could be on guest resume from S3 after migration if the
bios or acpi tables change.

> I really think that we need to snapshot the FW and store it with the 
> guest state.  If we switch all FW to be allocated with qemu_ram_alloc() 
> and we use an id mechanism, then this will Just Work for savevm based 
> snapshots and live migration.  However, for it to work with -M pc-0.11 
> started from a cold boot, we need an nvram file.  We probably want to 
> make available versioned nvram files from each release too.

So the idea is to store the bios/option roms in the guest state and read them
from there on reset or power cycle?

- Sebastian

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-21 19:13                                     ` [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul Anthony Liguori
@ 2009-12-21 19:43                                       ` Gleb Natapov
  2009-12-21 23:54                                         ` Anthony Liguori
  0 siblings, 1 reply; 84+ messages in thread
From: Gleb Natapov @ 2009-12-21 19:43 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: Kevin O'Connor, Gerd Hoffmann, qemu-devel

On Mon, Dec 21, 2009 at 01:13:10PM -0600, Anthony Liguori wrote:
> On 12/21/2009 11:43 AM, Gleb Natapov wrote:
> >Why I will never have reset equivalent to power off + startup? Are you
> >saying we are not capable of implementing spec correctly?
> 
> No, I'm saying that if you want reset absolutely equivalent to power
> off + startup, then you need to fork() and re-exec qemu at startup
> since the qemu binary may have changed while the guest was running.
> 
> My point behind this is I think that's equivalent to re-reading rom
> contents from disk.
> 
You are exaggerating. If user want to update qemu it should exit old
one and re-run new one. Power off + startup, on the other hand, is defied
to be equivalent to ACPI reset by ACPI spec. In other words if devices
state as seen by vmstate after qemu start is different by even one bit
from the state after system_restart this is bug. This is completely
orthogonal to our firmware loading discussion.

> >>>>And more importantly, what is the end-user benefit of doing this?
> >>>>
> >>>Working migration?
> >>How does it fix migration? Migration needs to transfer the current
> >>roms in order to work.  A new version of qemu must support
> >>interacting with the old version of the firmware for migration to
> >>work.  What happens after reset has nothing to do with migration but
> >>because of the last requirement, the guest will obviously continue
> >>to work after reboot too.
> >I don't agree with your last requirement. Firmware goes hand in hand with
> >HW. Change that is only FW visible should not be backwards compatible.
> 
> I think we're papering over this issue.  FW interfaces are guest
> visible even though we've been pretending like they aren't.
Not all of it. We can completely change extboot interface, for instance,
and support migration if we will handle things right. We can fix bugs in
tpr patching without losing migration capability.

> 
> SeaBIOS does not implement every possible BIOS function.  I'm sure
> that it will implement new functions over time.  The presence of
> those functions are certainly visible to the guest.  Likewise, any
> bug or added feature is visible to a guest.
> 
No, not any bug is visible to the guest. Example: kvm currently configures
lvt0 to virtual wire inside qemu/kvm acpi code, but this should be done
by the BIOS on real HW. So suppose we fixed this bug and moved
initialization into the BIOS If we'll try to init new kvm with old BIOS
next OS boot will fail.

> More concretely, we have an internal OS that interacts very closely
> with PXE roms (it makes use of UNDI).  It's very aware of the
> difference between etherboot and gPXE and it is also aware of
> different versions of those two.
> 
> The arguments for saying FW is not guest visible is that FW
> interfaces are well defined and do not change.  The same is true for
> 99% of the hardware we emulate.  The reason we have guest visible
> changes is that we're constantly improving and increasing the
> functionality of the hardware.  The same is true for FW.
> 
We can't do guest visible changes in devices and FW and support
migration from older qemu. I think we agree on this. Non guest visible
changes are allowed for device emulation, you are trying to disallow it for
FW.

> I'm starting to think having an nvram with saved firmware and user
> driven upgrades is the best approach for compatibility by far.  I'm
> still concerned though about the relatively complexity of having to
> force users to upgrade their firmware.
> 
Please stop thinking so :) Especially about "user driven upgrades".
Why combine disadvantages of vitalization with pain of physical HW
management? Or may be next step will be to require uploading of CPU
microcode to take advantage of KVM/tcg bug fixes?

--
			Gleb.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.
  2009-12-21 19:17                                       ` [Qemu-devel] " Anthony Liguori
  2009-12-21 19:39                                         ` Sebastian Herbszt
@ 2009-12-21 19:48                                         ` Gleb Natapov
  1 sibling, 0 replies; 84+ messages in thread
From: Gleb Natapov @ 2009-12-21 19:48 UTC (permalink / raw)
  To: Anthony Liguori
  Cc: qemu-devel, Kevin O'Connor, Gerd Hoffmann, Sebastian Herbszt

On Mon, Dec 21, 2009 at 01:17:23PM -0600, Anthony Liguori wrote:
> >Does any OS (Windows?) depend on the tables the bios creates (e.g.
> >smbios)
> >for licensing? It would be ugly if Windows wants you to
> >re-activate after a reboot
> >following a migration to newer qemu version and therefore possibly
> >changed tables
> >due to newer bios.
> 
> Yes, and this is a good point.  ACPI table changes can absolutely
> cause re-activation.  If we migrate from 0.12 -> 0.13 and make major
> changes to the ACPI tables in 0.13, then it's very likely that will
> result in problems for Windows guests.
> 
On the contrary. This is very unlikely. Otherwise BIOS upgrade would
cause Windows reactivation.

> I really think that we need to snapshot the FW and store it with the
> guest state.  If we switch all FW to be allocated with
> qemu_ram_alloc() and we use an id mechanism, then this will Just
> Work for savevm based snapshots and live migration.  However, for it
> to work with -M pc-0.11 started from a cold boot, we need an nvram
> file.  We probably want to make available versioned nvram files from
> each release too.
> 
Yes, firmware should be part of machine description.

--
			Gleb.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.
  2009-12-21 19:39                                         ` Sebastian Herbszt
@ 2009-12-21 19:53                                           ` Gleb Natapov
  2009-12-21 20:16                                             ` Sebastian Herbszt
  0 siblings, 1 reply; 84+ messages in thread
From: Gleb Natapov @ 2009-12-21 19:53 UTC (permalink / raw)
  To: Sebastian Herbszt; +Cc: Kevin O'Connor, Gerd Hoffmann, qemu-devel

On Mon, Dec 21, 2009 at 08:39:03PM +0100, Sebastian Herbszt wrote:
> Anthony Liguori wrote:
> >On 12/21/2009 12:24 PM, Sebastian Herbszt wrote:
> >>As stated before i don't like the idea of automagically
> >>upgrading the firmware
> >>on reset, e.g. after a live migration to a newer qemu version.
> >>You have explained
> >>that qemu-kvm needs this in order to work with live migration
> >>and changed hw
> >>support because of bug fixes. Is this only needed in the kvm case?
> >
> >It's not "needed", it's desired.  The same case can be made for
> >real hardware (automated firmware updates).
> 
> Tho on real hardware those updates are initiated by someone and not
> automagic.
> 
Because on real hardware it is impossible to do it differently may be?
My cable TV provider upgrades FW on my set-top-box automatically.

> >>Does any OS (Windows?) depend on the tables the bios creates
> >>(e.g. smbios)
> >>for licensing? It would be ugly if Windows wants you to
> >>re-activate after a reboot
> >>following a migration to newer qemu version and therefore
> >>possibly changed tables
> >>due to newer bios.
> >
> >Yes, and this is a good point.  ACPI table changes can absolutely
> >cause re-activation.  If we migrate from 0.12 -> 0.13 and make
> >major changes to the ACPI tables in 0.13, then it's very likely
> >that will result in problems for Windows guests.
> 
> Another problem could be on guest resume from S3 after migration if the
> bios or acpi tables change.
On resume from S3 BIOS doesn't recreate ACPI tables. ACPI tables are not
part of a BIOS image and in fact OS can reuse memory ACPI tables reside
in. So such problem definitely does not exist.

> 
> >I really think that we need to snapshot the FW and store it with
> >the guest state.  If we switch all FW to be allocated with
> >qemu_ram_alloc() and we use an id mechanism, then this will Just
> >Work for savevm based snapshots and live migration.  However, for
> >it to work with -M pc-0.11 started from a cold boot, we need an
> >nvram file.  We probably want to make available versioned nvram
> >files from each release too.
> 
> So the idea is to store the bios/option roms in the guest state and read them
> from there on reset or power cycle?
> 
> - Sebastian

--
			Gleb.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.
  2009-12-21 19:28                                         ` Sebastian Herbszt
@ 2009-12-21 19:57                                           ` Gleb Natapov
  0 siblings, 0 replies; 84+ messages in thread
From: Gleb Natapov @ 2009-12-21 19:57 UTC (permalink / raw)
  To: Sebastian Herbszt; +Cc: Kevin O'Connor, Gerd Hoffmann, qemu-devel

On Mon, Dec 21, 2009 at 08:28:20PM +0100, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
> >On Mon, Dec 21, 2009 at 07:24:43PM +0100, Sebastian Herbszt wrote:
> >>Does any OS (Windows?) depend on the tables the bios creates (e.g. smbios)
> >>for licensing? It would be ugly if Windows wants you to re-activate after a reboot
> >>following a migration to newer qemu version and therefore possibly changed tables
> >>due to newer bios.
> >>
> >I am not talking about OS visible stuff.
> 
> How do you want to avoid OS visible changes if the bios is reread on each reset? People
> can upgrade/change their bios in the pc-bios directory and bad things could happen if its
> reloaded on each reset.
> 
The fact that people can doesn't mean people should. Arbitrary
combination of qemu + BIOS is not supported. If people do what you say
the bad things will happen anyway after restarting qemu instead of
reboot.

--
			Gleb.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.
  2009-12-21 19:53                                           ` Gleb Natapov
@ 2009-12-21 20:16                                             ` Sebastian Herbszt
  2009-12-22  7:58                                               ` Gleb Natapov
  0 siblings, 1 reply; 84+ messages in thread
From: Sebastian Herbszt @ 2009-12-21 20:16 UTC (permalink / raw)
  To: Gleb Natapov; +Cc: Kevin O'Connor, Gerd Hoffmann, qemu-devel

Gleb Natapov wrote:
> On Mon, Dec 21, 2009 at 08:39:03PM +0100, Sebastian Herbszt wrote:
>> Anthony Liguori wrote:
>> >On 12/21/2009 12:24 PM, Sebastian Herbszt wrote:
>> >>As stated before i don't like the idea of automagically
>> >>upgrading the firmware
>> >>on reset, e.g. after a live migration to a newer qemu version.
>> >>You have explained
>> >>that qemu-kvm needs this in order to work with live migration
>> >>and changed hw
>> >>support because of bug fixes. Is this only needed in the kvm case?
>> >
>> >It's not "needed", it's desired.  The same case can be made for
>> >real hardware (automated firmware updates).
>> 
>> Tho on real hardware those updates are initiated by someone and not
>> automagic.
>> 
> Because on real hardware it is impossible to do it differently may be?
> My cable TV provider upgrades FW on my set-top-box automatically.

Your cable TV provider does likely also control what beside the FW (if anything)
runs on your set-top-box. So he can verify the FW upgrade doesn't break anything
in the field. That pre-deployment verification is not possible in non closed
environments.

>> >>Does any OS (Windows?) depend on the tables the bios creates
>> >>(e.g. smbios)
>> >>for licensing? It would be ugly if Windows wants you to
>> >>re-activate after a reboot
>> >>following a migration to newer qemu version and therefore
>> >>possibly changed tables
>> >>due to newer bios.
>> >
>> >Yes, and this is a good point.  ACPI table changes can absolutely
>> >cause re-activation.  If we migrate from 0.12 -> 0.13 and make
>> >major changes to the ACPI tables in 0.13, then it's very likely
>> >that will result in problems for Windows guests.
>> 
>> Another problem could be on guest resume from S3 after migration if the
>> bios or acpi tables change.
> On resume from S3 BIOS doesn't recreate ACPI tables. ACPI tables are not
> part of a BIOS image and in fact OS can reuse memory ACPI tables reside
> in. So such problem definitely does not exist.

If the OS recycles the whole memory which holds the ACPI tables i am not sure how
the BIOS will find the firmware_waking_vector. Maybe the OS can only use the memory
which holds the DSDT? Anyway, will the guest even resume from S3 if the hw changed
on migration and the bios doesn't know how to init it?

- Sebastian

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-21 19:43                                       ` Gleb Natapov
@ 2009-12-21 23:54                                         ` Anthony Liguori
  2009-12-22 20:50                                           ` [Qemu-devel] Re: Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul Sebastian Herbszt
  0 siblings, 1 reply; 84+ messages in thread
From: Anthony Liguori @ 2009-12-21 23:54 UTC (permalink / raw)
  To: Gleb Natapov; +Cc: Kevin O'Connor, Gerd Hoffmann, qemu-devel

On 12/21/2009 01:43 PM, Gleb Natapov wrote:
> Please stop thinking so :) Especially about "user driven upgrades".
> Why combine disadvantages of vitalization with pain of physical HW
> management? Or may be next step will be to require uploading of CPU
> microcode to take advantage of KVM/tcg bug fixes?
>    

I think your real argument boils down to that we can be better than real 
hardware therefore we should.  I actually agree with you for 90% of 
users.  Let me summarize where I'm at.

  - We are currently horribly broken with respect to how we handle roms 
particularly with respect to backwards compatibility
  - We must support running older roms on newer qemu at least within a 
stable series (because of live migration)
  - We need a mechanism to include roms specific to a machine type
  - Probably by default, we want new roms to be used by guests at some 
well defined time (either first reset or first power-down/start-up)
  - We ought to make all roms live in qemu_ram_alloc()'d memory and we 
ought to change that api to contain contexts, this will make sure rom 
live migration works properly.

The best approach I can think of is to introduce an nvram mechanism.  A 
tar file probably work really well.  If a user doesn't supply an 
explicit -nvram, we could create a temporary file and delete it.  If the 
nvram is empty, we populate it with whatever the appropriate roms are 
for the machine type.

I would also suggest that we support the guest updating roms on its own 
(through fw_cfg).  I can think of a number of reasons for this.  For 
instance, why shouldn't a guest be able to update the gPXE associated 
with the network card?  The code runs entirely in the guest so there's 
no harm to the host.  Allow a guest to do this sort of thing takes 
pressure off of the management system so particularly in an environment 
like a cloud, I think this could prove very useful.

It could be possible to add an option to -nvram to make it re-read roms 
from disk every reboot.  I really think this is a bad idea though, I'd 
like to hear more people comment on it but it's certainly technically 
feasible.

Regards,

Anthony Liguori
> --
> 			Gleb.
>    

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.
  2009-12-21 20:16                                             ` Sebastian Herbszt
@ 2009-12-22  7:58                                               ` Gleb Natapov
  2009-12-22 14:57                                                 ` Anthony Liguori
  0 siblings, 1 reply; 84+ messages in thread
From: Gleb Natapov @ 2009-12-22  7:58 UTC (permalink / raw)
  To: Sebastian Herbszt; +Cc: Kevin O'Connor, Gerd Hoffmann, qemu-devel

On Mon, Dec 21, 2009 at 09:16:17PM +0100, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
> >On Mon, Dec 21, 2009 at 08:39:03PM +0100, Sebastian Herbszt wrote:
> >>Anthony Liguori wrote:
> >>>On 12/21/2009 12:24 PM, Sebastian Herbszt wrote:
> >>>>As stated before i don't like the idea of automagically
> >>>>upgrading the firmware
> >>>>on reset, e.g. after a live migration to a newer qemu version.
> >>>>You have explained
> >>>>that qemu-kvm needs this in order to work with live migration
> >>>>and changed hw
> >>>>support because of bug fixes. Is this only needed in the kvm case?
> >>>
> >>>It's not "needed", it's desired.  The same case can be made for
> >>>real hardware (automated firmware updates).
> >>
> >>Tho on real hardware those updates are initiated by someone and not
> >>automagic.
> >>
> >Because on real hardware it is impossible to do it differently may be?
> >My cable TV provider upgrades FW on my set-top-box automatically.
> 
> Your cable TV provider does likely also control what beside the FW (if anything)
> runs on your set-top-box. So he can verify the FW upgrade doesn't break anything
> in the field. That pre-deployment verification is not possible in non closed
> environments.
> 
Yet it doesn't stop HW manufacturers to require FW update as the first
step of their support procedure. They don't do it automatically only
because they can't.

> >>>>Does any OS (Windows?) depend on the tables the bios creates
> >>>>(e.g. smbios)
> >>>>for licensing? It would be ugly if Windows wants you to
> >>>>re-activate after a reboot
> >>>>following a migration to newer qemu version and therefore
> >>>>possibly changed tables
> >>>>due to newer bios.
> >>>
> >>>Yes, and this is a good point.  ACPI table changes can absolutely
> >>>cause re-activation.  If we migrate from 0.12 -> 0.13 and make
> >>>major changes to the ACPI tables in 0.13, then it's very likely
> >>>that will result in problems for Windows guests.
> >>
> >>Another problem could be on guest resume from S3 after migration if the
> >>bios or acpi tables change.
> >On resume from S3 BIOS doesn't recreate ACPI tables. ACPI tables are not
> >part of a BIOS image and in fact OS can reuse memory ACPI tables reside
> >in. So such problem definitely does not exist.
> 
> If the OS recycles the whole memory which holds the ACPI tables i am not sure how
> the BIOS will find the firmware_waking_vector. Maybe the OS can only use the memory
> which holds the DSDT?
OS can reuse memory marked as "ACPI data" in e820 map. BIOS can put
firmware_waking_vector pointer into reserved memory or "ACPI NVS"

>                       Anyway, will the guest even resume from S3 if the hw changed
> on migration and the bios doesn't know how to init it?
Probably not, so we need to use new BIOS that knows how to init HW.

--
			Gleb.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-20 15:20             ` Avi Kivity
  2009-12-20 15:31               ` Anthony Liguori
@ 2009-12-22 13:04               ` Paul Brook
  2009-12-22 13:09                 ` Avi Kivity
  2009-12-22 15:11                 ` Anthony Liguori
  1 sibling, 2 replies; 84+ messages in thread
From: Paul Brook @ 2009-12-22 13:04 UTC (permalink / raw)
  To: qemu-devel; +Cc: Gleb Natapov, Avi Kivity, Gerd Hoffmann

> > We should just qemu_ram_alloc() that memory regardless of whether we
> > every map it into the guest.  Since roms can be large, we want to send
> > their contents over during the live part of migration.  If we use
> > qemu_ram_alloc(), we get that for free.
> 
> Currently live migration uses ram_addrs, so this would work.  But
> ram_addrs have no meaning in the guest and thus depend on qemu
> implementation details.  IMO we should switch live migration to use
> guest physical addresses, which would require a different migration
> implementation for roms.  Most of it can be shared with ram, though.

Ram allocations should be associated with a device. The VMState stuff this 
should make this fairly straightforward.

Guest address space mappings are a completely separate issue. The device 
should be migrating the mappings (directly or via a PCI BAR) as part of its 
state migration. The ram regions might not be mapped into guest address space 
at all.

Paul

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-22 13:04               ` Paul Brook
@ 2009-12-22 13:09                 ` Avi Kivity
  2009-12-22 15:11                 ` Anthony Liguori
  1 sibling, 0 replies; 84+ messages in thread
From: Avi Kivity @ 2009-12-22 13:09 UTC (permalink / raw)
  To: Paul Brook; +Cc: Gleb Natapov, qemu-devel, Gerd Hoffmann

On 12/22/2009 03:04 PM, Paul Brook wrote:
>>> We should just qemu_ram_alloc() that memory regardless of whether we
>>> every map it into the guest.  Since roms can be large, we want to send
>>> their contents over during the live part of migration.  If we use
>>> qemu_ram_alloc(), we get that for free.
>>>        
>> Currently live migration uses ram_addrs, so this would work.  But
>> ram_addrs have no meaning in the guest and thus depend on qemu
>> implementation details.  IMO we should switch live migration to use
>> guest physical addresses, which would require a different migration
>> implementation for roms.  Most of it can be shared with ram, though.
>>      
> Ram allocations should be associated with a device. The VMState stuff this
> should make this fairly straightforward.
>
> Guest address space mappings are a completely separate issue. The device
> should be migrating the mappings (directly or via a PCI BAR) as part of its
> state migration. The ram regions might not be mapped into guest address space
> at all.
>    

Yes, this is essentially Anthony's reply (which I agree with).

-- 
error compiling committee.c: too many arguments to function

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.
  2009-12-22  7:58                                               ` Gleb Natapov
@ 2009-12-22 14:57                                                 ` Anthony Liguori
  0 siblings, 0 replies; 84+ messages in thread
From: Anthony Liguori @ 2009-12-22 14:57 UTC (permalink / raw)
  To: Gleb Natapov
  Cc: qemu-devel, Kevin O'Connor, Gerd Hoffmann, Sebastian Herbszt

On 12/22/2009 01:58 AM, Gleb Natapov wrote:
>> Your cable TV provider does likely also control what beside the FW (if anything)
>> runs on your set-top-box. So he can verify the FW upgrade doesn't break anything
>> in the field. That pre-deployment verification is not possible in non closed
>> environments.
>>
>>      
> Yet it doesn't stop HW manufacturers to require FW update as the first
> step of their support procedure. They don't do it automatically only
> because they can't.
>    

Let's put correctness aside for a moment.

Right now, if you replace the contents of pc-bios while you have a guest 
running, heck, even if you rm -rf, the guest will continue functioning 
until you do a hard power off.

Changing this behavior feels like a regression to me.  It really seems 
to me like it makes things a lot more brittle.

The only benefit I can see is that you'll use a new rom after migration 
after the first reset.  Maybe that's desirable behavior although I'm not 
sure.

I'd feel a lot better about something that read the real rom contents at 
start-up, and then replaced migrated roms after reset or something like 
that.  That gives us the use-case without making qemu depend on 
rereading things while it's running.

Regards,

Anthony Liguori

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-22 13:04               ` Paul Brook
  2009-12-22 13:09                 ` Avi Kivity
@ 2009-12-22 15:11                 ` Anthony Liguori
  2009-12-22 15:54                   ` Paul Brook
  1 sibling, 1 reply; 84+ messages in thread
From: Anthony Liguori @ 2009-12-22 15:11 UTC (permalink / raw)
  To: Paul Brook, qemu-devel, Avi Kivity

On 12/22/2009 07:04 AM, Paul Brook wrote:
>>> We should just qemu_ram_alloc() that memory regardless of whether we
>>> every map it into the guest.  Since roms can be large, we want to send
>>> their contents over during the live part of migration.  If we use
>>> qemu_ram_alloc(), we get that for free.
>>>        
>> Currently live migration uses ram_addrs, so this would work.  But
>> ram_addrs have no meaning in the guest and thus depend on qemu
>> implementation details.  IMO we should switch live migration to use
>> guest physical addresses, which would require a different migration
>> implementation for roms.  Most of it can be shared with ram, though.
>>      
> Ram allocations should be associated with a device. The VMState stuff this
> should make this fairly straightforward.
>    

Right, but for the sake of simplicity, you don't want to treat that ram 
any differently than main ram wrt live migration.  That's why I proposed 
adding a context id for each ram region.  That would allow us to use 
something like the qdev name + id as the context id for a ram chunk to 
get that association while still doing live ram migration of the memory.

> Guest address space mappings are a completely separate issue. The device
> should be migrating the mappings (directly or via a PCI BAR) as part of its
> state migration. The ram regions might not be mapped into guest address space
> at all.
>    

We don't migrate guest address space memory today.  We migrate anything 
that's qemu_ram_alloc()'d.  The big problem we have though is that we 
don't have any real association between the qemu_ram_alloc() results and 
what the context of the allocation was.  We assume the order of these 
allocations are fixed and that's entirely wrong.

For non-device qemu_ram_alloc()'s, we could either create essentially 
dummy ram devices or we could just special case it.

Regards,

Anthony Liguori

> Paul
>    

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-22 15:11                 ` Anthony Liguori
@ 2009-12-22 15:54                   ` Paul Brook
  2009-12-22 16:16                     ` Anthony Liguori
  0 siblings, 1 reply; 84+ messages in thread
From: Paul Brook @ 2009-12-22 15:54 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: qemu-devel, Avi Kivity

> > Ram allocations should be associated with a device. The VMState stuff
> > this should make this fairly straightforward.
> 
> Right, but for the sake of simplicity, you don't want to treat that ram
> any differently than main ram wrt live migration.  That's why I proposed
> adding a context id for each ram region.  That would allow us to use
> something like the qdev name + id as the context id for a ram chunk to
> get that association while still doing live ram migration of the memory.

IMO the best way to do this is to do it via existing VMState machinery.
We've already matched up DeviceStates so this gets us a handy unique 
identifier for every ram block. For system memory we can add a dummy device. 
Medium term we're probably going to want this anyway.

> > Guest address space mappings are a completely separate issue. The device
> > should be migrating the mappings (directly or via a PCI BAR) as part of
> > its state migration. The ram regions might not be mapped into guest
> > address space at all.
> 
> We don't migrate guest address space memory today.  We migrate anything
> that's qemu_ram_alloc()'d.  The big problem we have though is that we
> don't have any real association between the qemu_ram_alloc() results and
> what the context of the allocation was.  We assume the order of these
> allocations are fixed and that's entirely wrong.

The nice thing about the VMState approach is that the device doesn't know or 
care how the migration occurs. For bonus points it leads fairly directly to an 
object based mapping API, so we can change the implementation or migrate the 
ram to a different location without disturbing the device.

Paul

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-22 15:54                   ` Paul Brook
@ 2009-12-22 16:16                     ` Anthony Liguori
  0 siblings, 0 replies; 84+ messages in thread
From: Anthony Liguori @ 2009-12-22 16:16 UTC (permalink / raw)
  To: Paul Brook; +Cc: qemu-devel, Avi Kivity

On 12/22/2009 09:54 AM, Paul Brook wrote:
>>> Ram allocations should be associated with a device. The VMState stuff
>>> this should make this fairly straightforward.
>>>        
>> Right, but for the sake of simplicity, you don't want to treat that ram
>> any differently than main ram wrt live migration.  That's why I proposed
>> adding a context id for each ram region.  That would allow us to use
>> something like the qdev name + id as the context id for a ram chunk to
>> get that association while still doing live ram migration of the memory.
>>      
> IMO the best way to do this is to do it via existing VMState machinery.
> We've already matched up DeviceStates so this gets us a handy unique
> identifier for every ram block. For system memory we can add a dummy device.
> Medium term we're probably going to want this anyway.
>    

Okay, I understand and agree.

I think the way this would work is that we would have a ram_addr type 
for VMState that would be an actual ram allocation and size.  
qemu_ram_alloc() would not need to take a context.  ram live migration 
would walk the list of registered VMState entries searching for anything 
that had a ram_addr type and would add that to the ram migration.

For system ram, we need dummy devices.

I think we probably ought to integrate VMState into qdev first though.  
I think that makes everything a bit more managable.

>>> Guest address space mappings are a completely separate issue. The device
>>> should be migrating the mappings (directly or via a PCI BAR) as part of
>>> its state migration. The ram regions might not be mapped into guest
>>> address space at all.
>>>        
>> We don't migrate guest address space memory today.  We migrate anything
>> that's qemu_ram_alloc()'d.  The big problem we have though is that we
>> don't have any real association between the qemu_ram_alloc() results and
>> what the context of the allocation was.  We assume the order of these
>> allocations are fixed and that's entirely wrong.
>>      
> The nice thing about the VMState approach is that the device doesn't know or
> care how the migration occurs. For bonus points it leads fairly directly to an
> object based mapping API, so we can change the implementation or migrate the
> ram to a different location without disturbing the device.
>    

Yeah, I like it.

Regards,

Anthony Liguori

> Paul
>    

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] Re: Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.
  2009-12-21 23:54                                         ` Anthony Liguori
@ 2009-12-22 20:50                                           ` Sebastian Herbszt
  0 siblings, 0 replies; 84+ messages in thread
From: Sebastian Herbszt @ 2009-12-22 20:50 UTC (permalink / raw)
  To: Anthony Liguori, Gleb Natapov
  Cc: Kevin O'Connor, Gerd Hoffmann, qemu-devel

Anthony Liguori wrote:
> On 12/21/2009 01:43 PM, Gleb Natapov wrote:
>> Please stop thinking so :) Especially about "user driven upgrades".
>> Why combine disadvantages of vitalization with pain of physical HW
>> management? Or may be next step will be to require uploading of CPU
>> microcode to take advantage of KVM/tcg bug fixes?
>>    
> 
> I think your real argument boils down to that we can be better than real 
> hardware therefore we should.  I actually agree with you for 90% of 
> users.  Let me summarize where I'm at.
> 
>  - We are currently horribly broken with respect to how we handle roms 
> particularly with respect to backwards compatibility
>  - We must support running older roms on newer qemu at least within a 
> stable series (because of live migration)
>  - We need a mechanism to include roms specific to a machine type
>  - Probably by default, we want new roms to be used by guests at some 
> well defined time (either first reset or first power-down/start-up)

Start-up sounds good.

>  - We ought to make all roms live in qemu_ram_alloc()'d memory and we 
> ought to change that api to contain contexts, this will make sure rom 
> live migration works properly.
> 
> The best approach I can think of is to introduce an nvram mechanism.  A 
> tar file probably work really well.  If a user doesn't supply an 
> explicit -nvram, we could create a temporary file and delete it.  If the 
> nvram is empty, we populate it with whatever the appropriate roms are 
> for the machine type.
> 
> I would also suggest that we support the guest updating roms on its own 
> (through fw_cfg).  I can think of a number of reasons for this.  For 
> instance, why shouldn't a guest be able to update the gPXE associated 
> with the network card?  The code runs entirely in the guest so there's 
> no harm to the host.

You mean the nvram file on the host or in memory? Will there be a size limit?

> Allow a guest to do this sort of thing takes 
> pressure off of the management system so particularly in an environment 
> like a cloud, I think this could prove very useful.

It might not be desired and make support efforts harder. Could have security
implications too.

> It could be possible to add an option to -nvram to make it re-read roms 
> from disk every reboot.  I really think this is a bad idea though, I'd 
> like to hear more people comment on it but it's certainly technically 
> feasible.

- Sebastian

^ permalink raw reply	[flat|nested] 84+ messages in thread
* [Qemu-devel] [RFC] New naming rules for GPXE romfiles
  2009-12-18 11:01 ` [Qemu-devel] [PATCH 2/8] pci romfiles: add property, add default to PCIDeviceInfo Gerd Hoffmann
@ 2010-01-11 21:18   ` Stefan Weil
  2010-01-11 21:34     ` Anthony Liguori
  2010-01-12 10:23     ` Kevin Wolf
  0 siblings, 2 replies; 84+ messages in thread
From: Stefan Weil @ 2010-01-11 21:18 UTC (permalink / raw)
  Cc: qemu-devel

The current names of GPXE romfiles are something like
pxe-e1000.bin, pxe-ne2k_pci.bin, pxe-rtl8139.bin.

This was adequate when these names were computed
by a simple rule using the device name.

Today, an ethernet device can be associated to any
romfile name.

Etherboot's Rom-o-Matic (which creates qemu's romfiles)
creates names like gpxe-0.9.9-80861209.rom.

I don't think it would be good to use etherboot's names
because they contain the gpxe version (0.9.9) which
might change.

But a modified name without the gpxe version like
gpxe-80861209.rom would have some advantages:

* gpxe* is better than pxe* because the files contain
  a gPXE boot ROM - not a proprietary PXE ROM.

* The romfiles are ROM files, not undefined binaries,
  so *.rom looks better than *.bin.

* For drivers like eepro100.c which implement several devices,
  a naming rule based on PCI device and vendor id (80861209)
  is better than a rule based on device names:
  devices with same ids can share the same romfile.

* Transforming an etherboot romfile name to a qemu romfile name
  is simple when all you have to do is to remove the version.
  This would also simplify pc-bios/README.

The proposed new names should be used for new romfiles.
Optionally, the existing romfiles could be renamed.

Please tell me what you think of these suggestions.

Regards
Stefan Weil

PS. Mixing ROM data for different hosts in one directory
(as it is done today) could be improved, too:

* Separate directories for different hosts.
* Include the host in the romfile name (as it is done
  for the openbios roms).
* pc-bios was historically correct but is no longer adequate.

As far as I remember, there had already been some discussion
on these points some time ago.

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] [RFC] New naming rules for GPXE romfiles
  2010-01-11 21:18   ` [Qemu-devel] [RFC] New naming rules for GPXE romfiles Stefan Weil
@ 2010-01-11 21:34     ` Anthony Liguori
  2010-01-12 10:23     ` Kevin Wolf
  1 sibling, 0 replies; 84+ messages in thread
From: Anthony Liguori @ 2010-01-11 21:34 UTC (permalink / raw)
  To: Stefan Weil; +Cc: qemu-devel

On 01/11/2010 03:18 PM, Stefan Weil wrote:
> The current names of GPXE romfiles are something like
> pxe-e1000.bin, pxe-ne2k_pci.bin, pxe-rtl8139.bin.
>
> This was adequate when these names were computed
> by a simple rule using the device name.
>
> Today, an ethernet device can be associated to any
> romfile name.
>
> Etherboot's Rom-o-Matic (which creates qemu's romfiles)
> creates names like gpxe-0.9.9-80861209.rom.
>
> I don't think it would be good to use etherboot's names
> because they contain the gpxe version (0.9.9) which
> might change.
>
> But a modified name without the gpxe version like
> gpxe-80861209.rom would have some advantages:
>
> * gpxe* is better than pxe* because the files contain
>    a gPXE boot ROM - not a proprietary PXE ROM.
>
> * The romfiles are ROM files, not undefined binaries,
>    so *.rom looks better than *.bin.
>
> * For drivers like eepro100.c which implement several devices,
>    a naming rule based on PCI device and vendor id (80861209)
>    is better than a rule based on device names:
>    devices with same ids can share the same romfile.
>
> * Transforming an etherboot romfile name to a qemu romfile name
>    is simple when all you have to do is to remove the version.
>    This would also simplify pc-bios/README.
>
> The proposed new names should be used for new romfiles.
> Optionally, the existing romfiles could be renamed.
>
> Please tell me what you think of these suggestions.
>    

I don't feel strongly either way.

Regards,

Anthony Liguori

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
  2009-12-20 15:33                 ` Gleb Natapov
  2009-12-20 15:39                   ` Anthony Liguori
@ 2010-01-12  4:48                   ` Jamie Lokier
  1 sibling, 0 replies; 84+ messages in thread
From: Jamie Lokier @ 2010-01-12  4:48 UTC (permalink / raw)
  To: Gleb Natapov; +Cc: TAKEDA, toshiya, Gerd Hoffmann, qemu-devel

Gleb Natapov wrote:
> On Sun, Dec 20, 2009 at 09:28:34AM -0600, Anthony Liguori wrote:
> > Gleb Natapov wrote:
> > >On Sun, Dec 20, 2009 at 09:11:18AM -0600, Anthony Liguori wrote:
> > >>Gleb Natapov wrote:
> > >>>On Sun, Dec 20, 2009 at 08:58:40AM -0600, Anthony Liguori wrote:
> > >>>>No.  You have to physically shut down and start up again.  That's
> > >>>>the right semantics IMHO.
> > >>>>
> > >>>Reset is equivalent (or should be) to shut down and start up again.
> > >>Not at all.  Reset can happen in a lot of different ways, some that
> > >We support only one way of reset: hard reset. It equivalent to full
> > >HW power cycling. ACPI spec define ACPI reset as equivalent to HW power
> > >cycling too BTW (see 4.7.3.6).
> > 
> > For every system periphereal?
>
> To cite ACPI spec : "From an OSPM perspective, asserting the reset mechanism
> is the logical equivalent to power cycling the machine."
> 
> > For instance, memory contents
> > survive a reset whereas they won't survive a hard power down.
>
> We cannot rely on memory content after such reset.

Some software expects it.  But the worst situation is when it's
"mostly reliable", i.e. works normally but unreliable if migration
occurs during the reset cycle.  It should either be reliable, or if
that is not intended, the memory should be wiped on reset to be sure
nobody is running guests which depend on it.  (They might not even know).

> > More importantly though, what's the use-case here?
> > 
> Use-case for what? This just what need to be done for correct HW
> emulation.

Reminder about x86 HW emulation; recent message:

http://www.mail-archive.com/qemu-devel@nongnu.org/msg22676.html

TAKEDA, toshiya wrote:
> Anthony Liguori wrote:
> >Hi,
> >
> >Why is this needed verses qemu_system_reset()?
> 
> PC-98 has the ioport to reset only cpu (don't reset other periferals) 
> and I need qemu_cpu_reset() to emulate thios port.
> 
> This port was used to return to real mode from protect mode by resetting cpu.
> It was added for 80286, but was used on PC-98 with 80386 and later.
> (For example for checking of over 1mb memory in hardware
> initialization bios.)
> 
> Thanks,
> TAKEDA, toshiya

That is, PC-98 emulation requires a CPU-only reset that retains memory
contents and does not reset peripherals.  It has an I/O port
explicitly for it.

Regular x86 PCs also require this under some circumstances, for the
same reasons: To run 80286 MS-DOS software (on a later CPU of course
:-) that switches from protected mode to real mode by triggering a
hardware reset.  It does not reset the peripherals and memory contents
are reliable, except possibly for some regions that the BIOS may affect.

I assume this was one of the things meant in Anthony's qemu 0.12
release announcment:

>>> [please test...]
>>> - exotic x86 guests that may interact with the BIOS in special ways

But I don't really understand

  - what strange things are being implemented with ROMs changing on
    boot and during migration
  - how it depends in some intricate way on ACPI tables and option ROMS
    and migration and qemu upgrades all at once
  - those are things which the "exotic" guests don't care about
  - memory is preserved, isn't it, when qemu resets, even though it is
    called "not reliable", meaning that test guests will run fine with
    it while having some hidden bug waiting to happen under a rare
    conjunction of qemu's circumstances - is that right?

So I don't know quite what to test to confirm or deny bugs in
emulation of things that exotic x86 guests depend on.

-- Jamie

^ permalink raw reply	[flat|nested] 84+ messages in thread
* Re: [Qemu-devel] [RFC] New naming rules for GPXE romfiles
  2010-01-11 21:18   ` [Qemu-devel] [RFC] New naming rules for GPXE romfiles Stefan Weil
  2010-01-11 21:34     ` Anthony Liguori
@ 2010-01-12 10:23     ` Kevin Wolf
  1 sibling, 0 replies; 84+ messages in thread
From: Kevin Wolf @ 2010-01-12 10:23 UTC (permalink / raw)
  To: Stefan Weil; +Cc: qemu-devel

Am 11.01.2010 22:18, schrieb Stefan Weil:
> The current names of GPXE romfiles are something like
> pxe-e1000.bin, pxe-ne2k_pci.bin, pxe-rtl8139.bin.
> 
> This was adequate when these names were computed
> by a simple rule using the device name.
> 
> Today, an ethernet device can be associated to any
> romfile name.
> 
> Etherboot's Rom-o-Matic (which creates qemu's romfiles)
> creates names like gpxe-0.9.9-80861209.rom.
> 
> I don't think it would be good to use etherboot's names
> because they contain the gpxe version (0.9.9) which
> might change.
> 
> But a modified name without the gpxe version like
> gpxe-80861209.rom would have some advantages:
> 
> * gpxe* is better than pxe* because the files contain
>   a gPXE boot ROM - not a proprietary PXE ROM.
> 
> * The romfiles are ROM files, not undefined binaries,
>   so *.rom looks better than *.bin.
> 
> * For drivers like eepro100.c which implement several devices,
>   a naming rule based on PCI device and vendor id (80861209)
>   is better than a rule based on device names:
>   devices with same ids can share the same romfile.

I dislike this part of your suggestion. Everyone knows what a pcnet is,
but I guess most people don't know its PCI device/vendor ID. So it would
add files that most people can't associate with anything specific. Maybe
you could name your files gpxe-eepro100-vendor_dev.rom and just leave
vendor_dev out for devices with just one ID?

I'm fine with the other suggestions, though.

Kevin

^ permalink raw reply	[flat|nested] 84+ messages in thread
end of thread, other threads:[~2010-01-12 10:25 UTC | newest]

Thread overview: 84+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-12-18 11:01 [Qemu-devel] [PATCH 0/8] option rom loading overhaul Gerd Hoffmann
2009-12-18 11:01 ` [Qemu-devel] [PATCH 1/8] Support PCI based option rom loading Gerd Hoffmann
2009-12-19 10:57   ` Blue Swirl
2009-12-20 15:34     ` Anthony Liguori
2009-12-20 17:02       ` Blue Swirl
2009-12-20 17:18         ` Alexander Graf
2009-12-20 17:55           ` Anthony Liguori
2009-12-20 18:01             ` Alexander Graf
2009-12-20 18:24               ` Andreas Färber
2009-12-20 18:53                 ` Blue Swirl
2009-12-20 21:24                   ` Benjamin Herrenschmidt
2009-12-20 21:23               ` Benjamin Herrenschmidt
2009-12-18 11:01 ` [Qemu-devel] [PATCH 2/8] pci romfiles: add property, add default to PCIDeviceInfo Gerd Hoffmann
2010-01-11 21:18   ` [Qemu-devel] [RFC] New naming rules for GPXE romfiles Stefan Weil
2010-01-11 21:34     ` Anthony Liguori
2010-01-12 10:23     ` Kevin Wolf
2009-12-18 11:01 ` [Qemu-devel] [PATCH 3/8] fw_cfg: make calls typesafe Gerd Hoffmann
2009-12-18 11:01 ` [Qemu-devel] [PATCH 4/8] fw_cfg: add API for file transfer Gerd Hoffmann
2009-12-19 12:06   ` Blue Swirl
2009-12-20  8:42   ` [Qemu-devel] Re: [SeaBIOS] " Gleb Natapov
2009-12-18 11:01 ` [Qemu-devel] [PATCH 5/8] roms: use new fw_cfg file xfer support Gerd Hoffmann
2009-12-20  8:45   ` [Qemu-devel] Re: [SeaBIOS] " Gleb Natapov
2009-12-18 11:01 ` [Qemu-devel] [PATCH 6/8] roms: remove option rom packing logic Gerd Hoffmann
2009-12-18 11:01 ` [Qemu-devel] [PATCH 7/8] updated seabios binary for testing convinience Gerd Hoffmann
2009-12-18 11:01 ` [Qemu-devel] [PATCH 8/8] debug: enable bios messages Gerd Hoffmann
2009-12-18 14:35 ` [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul Anthony Liguori
2009-12-18 16:34   ` Gerd Hoffmann
2009-12-18 16:42     ` Anthony Liguori
2009-12-18 17:03       ` Gerd Hoffmann
2009-12-18 17:12         ` Anthony Liguori
2009-12-19  1:48           ` Kevin O'Connor
2009-12-19  3:07             ` Anthony Liguori
2009-12-18 17:14         ` Anthony Liguori
2009-12-18 18:04           ` Gerd Hoffmann
2009-12-18 19:41         ` Sebastian Herbszt
2009-12-18 19:53           ` Anthony Liguori
2009-12-18 20:10             ` Sebastian Herbszt
2009-12-20  8:38 ` Gleb Natapov
2009-12-20 14:43   ` Anthony Liguori
2009-12-20 14:52     ` Gleb Natapov
2009-12-20 14:58       ` Anthony Liguori
2009-12-20 15:07         ` Gleb Natapov
2009-12-20 15:11           ` Anthony Liguori
2009-12-20 15:20             ` Avi Kivity
2009-12-20 15:31               ` Anthony Liguori
2009-12-20 15:35                 ` Avi Kivity
2009-12-22 13:04               ` Paul Brook
2009-12-22 13:09                 ` Avi Kivity
2009-12-22 15:11                 ` Anthony Liguori
2009-12-22 15:54                   ` Paul Brook
2009-12-22 16:16                     ` Anthony Liguori
2009-12-20 15:23             ` Gleb Natapov
2009-12-20 15:28               ` Anthony Liguori
2009-12-20 15:33                 ` Gleb Natapov
2009-12-20 15:39                   ` Anthony Liguori
2009-12-20 15:52                     ` Gleb Natapov
2009-12-20 16:08                       ` Blue Swirl
2009-12-20 16:15                         ` Gleb Natapov
2009-12-20 16:23                           ` Blue Swirl
2009-12-20 17:48                       ` Anthony Liguori
2009-12-21  1:59                         ` Kevin O'Connor
2009-12-21  7:32                           ` Gleb Natapov
2009-12-21 16:40                             ` Anthony Liguori
2009-12-21 16:43                               ` Gleb Natapov
2009-12-21 17:26                                 ` Anthony Liguori
2009-12-21 17:43                                   ` Gleb Natapov
2009-12-21 18:24                                     ` [Qemu-devel] Re: Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul Sebastian Herbszt
2009-12-21 18:36                                       ` Gleb Natapov
2009-12-21 19:28                                         ` Sebastian Herbszt
2009-12-21 19:57                                           ` Gleb Natapov
2009-12-21 19:17                                       ` [Qemu-devel] " Anthony Liguori
2009-12-21 19:39                                         ` Sebastian Herbszt
2009-12-21 19:53                                           ` Gleb Natapov
2009-12-21 20:16                                             ` Sebastian Herbszt
2009-12-22  7:58                                               ` Gleb Natapov
2009-12-22 14:57                                                 ` Anthony Liguori
2009-12-21 19:48                                         ` Gleb Natapov
2009-12-21 19:13                                     ` [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul Anthony Liguori
2009-12-21 19:43                                       ` Gleb Natapov
2009-12-21 23:54                                         ` Anthony Liguori
2009-12-22 20:50                                           ` [Qemu-devel] Re: Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul Sebastian Herbszt
2009-12-21  7:40                         ` [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul Gleb Natapov
2009-12-21 17:27                           ` Michael S. Tsirkin
2010-01-12  4:48                   ` Jamie Lokier

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).