help
2014-08-12 23:11 GMT+08:00 <qemu-devel-requ...@nongnu.org>: > Send Qemu-devel mailing list submissions to > qemu-devel@nongnu.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.nongnu.org/mailman/listinfo/qemu-devel > or, via email, send a message with subject or body 'help' to > qemu-devel-requ...@nongnu.org > > You can reach the person managing the list at > qemu-devel-ow...@nongnu.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Qemu-devel digest..." > > > Today's Topics: > > 1. [PATCH] block.curl: adding 'curltimeout' option > (Daniel Henrique Barboza) > 2. [PATCH] pc: Get rid of pci-info leftovers (Markus Armbruster) > 3. [Bug 1353947] Re: Hypervisor with QEMU-2.0/libvirtd 1.2.2 > stack when launching VM with CirrOS or Ubuntu 12.04 (Eyal Perry) > 4. Re: [PATCH 00/12] target-ppc: Linux-User Mode Bug Fixes for > Power (Riku Voipio) > 5. Re: [RFC PATCH 09/10] spapr_pci_vfio: Enable DDW > (Alexey Kardashevskiy) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 12 Aug 2014 11:35:25 -0300 > From: Daniel Henrique Barboza <danie...@linux.vnet.ibm.com> > To: Qemu Devel <qemu-devel@nongnu.org> > Cc: Kevin Wolf <kw...@redhat.com>, Daniel Henrique Barboza > <danie...@linux.vnet.ibm.com>, Stefan Hajnoczi < > stefa...@redhat.com> > Subject: [Qemu-devel] [PATCH] block.curl: adding 'curltimeout' option > Message-ID: > <1407854125-25068-1-git-send-email-danie...@linux.vnet.ibm.com> > > The curl hardcoded timeout (5 seconds) sometimes is not long > enough depending on the remote server configuration and network > traffic. The user should be able to set how much long he is > willing to wait for the connection. > > Adding a new option to set this timeout gives the user this > flexibility. The previous default timeout of 5 seconds will be > used if this option is not present. > > Signed-off-by: Daniel Henrique Barboza <danie...@linux.vnet.ibm.com> > --- > block/curl.c | 13 ++++++++++++- > qemu-options.hx | 10 ++++++++-- > 2 files changed, 20 insertions(+), 3 deletions(-) > > diff --git a/block/curl.c b/block/curl.c > index 79ff2f1..a9e43f1 100644 > --- a/block/curl.c > +++ b/block/curl.c > @@ -63,6 +63,7 @@ static CURLMcode __curl_multi_socket_action(CURLM > *multi_handle, > #define CURL_NUM_ACB 8 > #define SECTOR_SIZE 512 > #define READ_AHEAD_DEFAULT (256 * 1024) > +#define CURL_TIMEOUT_DEFAULT 5 > > #define FIND_RET_NONE 0 > #define FIND_RET_OK 1 > @@ -71,6 +72,7 @@ static CURLMcode __curl_multi_socket_action(CURLM > *multi_handle, > #define CURL_BLOCK_OPT_URL "url" > #define CURL_BLOCK_OPT_READAHEAD "readahead" > #define CURL_BLOCK_OPT_SSLVERIFY "sslverify" > +#define CURL_BLOCK_OPT_TIMEOUT "curltimeout" > > struct BDRVCURLState; > > @@ -109,6 +111,7 @@ typedef struct BDRVCURLState { > char *url; > size_t readahead_size; > bool sslverify; > + int curltimeout; > bool accept_range; > AioContext *aio_context; > } BDRVCURLState; > @@ -382,7 +385,7 @@ static CURLState *curl_init_state(BDRVCURLState *s) > curl_easy_setopt(state->curl, CURLOPT_URL, s->url); > curl_easy_setopt(state->curl, CURLOPT_SSL_VERIFYPEER, > (long) s->sslverify); > - curl_easy_setopt(state->curl, CURLOPT_TIMEOUT, 5); > + curl_easy_setopt(state->curl, CURLOPT_TIMEOUT, s->curltimeout); > curl_easy_setopt(state->curl, CURLOPT_WRITEFUNCTION, > (void *)curl_read_cb); > curl_easy_setopt(state->curl, CURLOPT_WRITEDATA, (void *)state); > @@ -489,6 +492,11 @@ static QemuOptsList runtime_opts = { > .type = QEMU_OPT_BOOL, > .help = "Verify SSL certificate" > }, > + { > + .name = CURL_BLOCK_OPT_TIMEOUT, > + .type = QEMU_OPT_NUMBER, > + .help = "Curl timeout" > + }, > { /* end of list */ } > }, > }; > @@ -525,6 +533,9 @@ static int curl_open(BlockDriverState *bs, QDict > *options, int flags, > goto out_noclean; > } > > + s->curltimeout = qemu_opt_get_number(opts, CURL_BLOCK_OPT_TIMEOUT, > + CURL_TIMEOUT_DEFAULT); > + > s->sslverify = qemu_opt_get_bool(opts, CURL_BLOCK_OPT_SSLVERIFY, > true); > > file = qemu_opt_get(opts, CURL_BLOCK_OPT_URL); > diff --git a/qemu-options.hx b/qemu-options.hx > index 96516c1..36f5c3d 100644 > --- a/qemu-options.hx > +++ b/qemu-options.hx > @@ -2351,6 +2351,11 @@ multiple of 512 bytes. It defaults to 256k. > @item sslverify > Whether to verify the remote server's certificate when connecting over > SSL. It > can have the value 'on' or 'off'. It defaults to 'on'. > + > +@item curltimeout > +Set the timeout in seconds of the CURL connection. This timeout is the > time > +that CURL waits for a response from the remote server to get the size of > the > +image to be downloaded. If not set, the default timeout of 5 seconds is > used. > @end table > > Note that when passing options to qemu explicitly, @option{driver} is the > value > @@ -2372,9 +2377,10 @@ qemu-system-x86_64 -drive > file=/tmp/Fedora-x86_64-20-20131211.1-sda.qcow2,copy-o > @end example > > Example: boot from an image stored on a VMware vSphere server with a > self-signed > -certificate using a local overlay for writes and a readahead of 64k > +certificate using a local overlay for writes, a readahead of 64k and a > +curltimeout of 10 seconds. > @example > -qemu-img create -f qcow2 -o backing_file='json:@{"file.driver":"https",, > "file.url":"https://user:password@@ > vsphere.example.com/folder/test/test-flat.vmdk?dcPath=Datacenter&dsName=datastore1",, > "file.sslverify":"off",, "file.readahead":"64k"@}' /tmp/test.qcow2 > +qemu-img create -f qcow2 -o backing_file='json:@{"file.driver":"https",, > "file.url":"https://user:password@@ > vsphere.example.com/folder/test/test-flat.vmdk?dcPath=Datacenter&dsName=datastore1",, > "file.sslverify":"off",, "file.readahead":"64k",, > "file.curltimeout":"10"@}' /tmp/test.qcow2 > > qemu-system-x86_64 -drive file=/tmp/test.qcow2 > @end example > -- > 1.8.3.1 > > > > > ------------------------------ > > Message: 2 > Date: Tue, 12 Aug 2014 16:40:17 +0200 > From: Markus Armbruster <arm...@redhat.com> > To: qemu-devel@nongnu.org > Cc: aligu...@amazon.com, m...@redhat.com > Subject: [Qemu-devel] [PATCH] pc: Get rid of pci-info leftovers > Message-ID: <1407854417-32071-1-git-send-email-arm...@redhat.com> > > pc_fw_cfg_guest_info() never does anything, because has_pci_info is > always false. > > Introduced in commit f8c457b "pc: pass PCI hole ranges to Guests", > disabled in commit 9604f70 "pc: disable pci-info for 1.6", and hasn't > been enabled since. Obviously a dead end. Get of it. > > Signed-off-by: Markus Armbruster <arm...@redhat.com> > --- > hw/i386/pc.c | 30 ------------------------------ > hw/i386/pc_piix.c | 4 ---- > hw/i386/pc_q35.c | 3 --- > include/hw/i386/pc.h | 1 - > 4 files changed, 38 deletions(-) > > diff --git a/hw/i386/pc.c b/hw/i386/pc.c > index 9e58982..8fa8d2f 100644 > --- a/hw/i386/pc.c > +++ b/hw/i386/pc.c > @@ -1066,35 +1066,6 @@ typedef struct PcRomPciInfo { > uint64_t w64_max; > } PcRomPciInfo; > > -static void pc_fw_cfg_guest_info(PcGuestInfo *guest_info) > -{ > - PcRomPciInfo *info; > - Object *pci_info; > - bool ambiguous = false; > - > - if (!guest_info->has_pci_info || !guest_info->fw_cfg) { > - return; > - } > - pci_info = object_resolve_path_type("", TYPE_PCI_HOST_BRIDGE, > &ambiguous); > - g_assert(!ambiguous); > - if (!pci_info) { > - return; > - } > - > - info = g_malloc(sizeof *info); > - info->w32_min = cpu_to_le64(object_property_get_int(pci_info, > - PCI_HOST_PROP_PCI_HOLE_START, NULL)); > - info->w32_max = cpu_to_le64(object_property_get_int(pci_info, > - PCI_HOST_PROP_PCI_HOLE_END, NULL)); > - info->w64_min = cpu_to_le64(object_property_get_int(pci_info, > - PCI_HOST_PROP_PCI_HOLE64_START, NULL)); > - info->w64_max = cpu_to_le64(object_property_get_int(pci_info, > - PCI_HOST_PROP_PCI_HOLE64_END, NULL)); > - /* Pass PCI hole info to guest via a side channel. > - * Required so guest PCI enumeration does the right thing. */ > - fw_cfg_add_file(guest_info->fw_cfg, "etc/pci-info", info, sizeof > *info); > -} > - > typedef struct PcGuestInfoState { > PcGuestInfo info; > Notifier machine_done; > @@ -1106,7 +1077,6 @@ void pc_guest_info_machine_done(Notifier *notifier, > void *data) > PcGuestInfoState *guest_info_state = container_of(notifier, > PcGuestInfoState, > machine_done); > - pc_fw_cfg_guest_info(&guest_info_state->info); > acpi_setup(&guest_info_state->info); > } > > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c > index 4f22be8..12d8c26 100644 > --- a/hw/i386/pc_piix.c > +++ b/hw/i386/pc_piix.c > @@ -59,7 +59,6 @@ static const int ide_iobase[MAX_IDE_BUS] = { 0x1f0, > 0x170 }; > static const int ide_iobase2[MAX_IDE_BUS] = { 0x3f6, 0x376 }; > static const int ide_irq[MAX_IDE_BUS] = { 14, 15 }; > > -static bool has_pci_info; > static bool has_acpi_build = true; > static int legacy_acpi_table_size; > static bool smbios_defaults = true; > @@ -166,7 +165,6 @@ static void pc_init1(MachineState *machine, > guest_info->has_acpi_build = has_acpi_build; > guest_info->legacy_acpi_table_size = legacy_acpi_table_size; > > - guest_info->has_pci_info = has_pci_info; > guest_info->isapc_ram_fw = !pci_enabled; > guest_info->has_reserved_memory = has_reserved_memory; > > @@ -340,7 +338,6 @@ static void pc_compat_1_7(MachineState *machine) > static void pc_compat_1_6(MachineState *machine) > { > pc_compat_1_7(machine); > - has_pci_info = false; > rom_file_has_mr = false; > has_acpi_build = false; > } > @@ -422,7 +419,6 @@ static void pc_init_pci_no_kvmclock(MachineState > *machine) > > static void pc_init_isa(MachineState *machine) > { > - has_pci_info = false; > has_acpi_build = false; > smbios_defaults = false; > gigabyte_align = false; > diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c > index c39ee98..3f8a465 100644 > --- a/hw/i386/pc_q35.c > +++ b/hw/i386/pc_q35.c > @@ -49,7 +49,6 @@ > /* ICH9 AHCI has 6 ports */ > #define MAX_SATA_PORTS 6 > > -static bool has_pci_info; > static bool has_acpi_build = true; > static bool smbios_defaults = true; > static bool smbios_legacy_mode; > @@ -150,7 +149,6 @@ static void pc_q35_init(MachineState *machine) > } > > guest_info = pc_guest_info_init(below_4g_mem_size, above_4g_mem_size); > - guest_info->has_pci_info = has_pci_info; > guest_info->isapc_ram_fw = false; > guest_info->has_acpi_build = has_acpi_build; > guest_info->has_reserved_memory = has_reserved_memory; > @@ -296,7 +294,6 @@ static void pc_compat_1_7(MachineState *machine) > static void pc_compat_1_6(MachineState *machine) > { > pc_compat_1_7(machine); > - has_pci_info = false; > rom_file_has_mr = false; > has_acpi_build = false; > } > diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h > index 863eefb..7eb742d 100644 > --- a/include/hw/i386/pc.h > +++ b/include/hw/i386/pc.h > @@ -85,7 +85,6 @@ typedef struct PcPciInfo { > #define ACPI_PM_PROP_GPE0_BLK_LEN "gpe0_blk_len" > > struct PcGuestInfo { > - bool has_pci_info; > bool isapc_ram_fw; > hwaddr ram_size, ram_size_below_4g; > unsigned apic_id_limit; > -- > 1.9.3 > > > > > ------------------------------ > > Message: 3 > Date: Tue, 12 Aug 2014 14:31:32 -0000 > From: Eyal Perry <eya...@mellanox.com> > To: qemu-devel@nongnu.org > Subject: [Qemu-devel] [Bug 1353947] Re: Hypervisor with > QEMU-2.0/libvirtd 1.2.2 stack when launching VM with CirrOS or > Ubuntu > 12.04 > Message-ID: <20140812143132.17439.85360.mal...@soybean.canonical.com> > Content-Type: text/plain; charset="utf-8" > > Indeed, with qemu 1.5 we did not observed this issue at all. > Sorry, but I don't have the resources at the moment to do the bisecting. > > -- > You received this bug notification because you are a member of qemu- > devel-ml, which is subscribed to QEMU. > https://bugs.launchpad.net/bugs/1353947 > > Title: > Hypervisor with QEMU-2.0/libvirtd 1.2.2 stack when launching VM with > CirrOS or Ubuntu 12.04 > > Status in QEMU: > New > Status in ?linux? package in Ubuntu: > Confirmed > > Bug description: > The issue observed when running an hypervisor with QEMU 2.0/libvirtd > 1.2.2 > The VM network interface is attached to a PCI virtual function (SR-IOV). > > When we ran VM with guest OS CirrOS or Ubuntu 12.04 we observed an > hipervisor hang shortly after the VM is loaded > We observed the same issue with Mellanox NIC and with Intel NIC > > We?ve tried few combinations of {GuestOS}X{Hypervisor} and we got the > following findings: > When a hypervisor is running QEMU 1.5/libvirtd 1.1.1 - no issue observed > When a hypervisor is running QEMU 2.0/libvirtd 1.2.2 - CirrOS and Ubuntu > 12.04 guest OSes caused hypervisor hang > When a hypervisor is running QEMU 2.0/libvirtd 1.2.2 - CentOS 6.4 and > Ubuntu 13.10 - no issue observed > > The problematic guest OSes are with kernel versions ~3.2.y > > To manage notifications about this bug go to: > https://bugs.launchpad.net/qemu/+bug/1353947/+subscriptions > > > > ------------------------------ > > Message: 4 > Date: Tue, 12 Aug 2014 17:54:00 +0300 > From: Riku Voipio <riku.voi...@iki.fi> > To: Tom Musta <tommu...@gmail.com> > Cc: riku.voi...@linaro.org, qemu-...@nongnu.org, > qemu-devel@nongnu.org, ag...@suse.de > Subject: Re: [Qemu-devel] [PATCH 00/12] target-ppc: Linux-User Mode > Bug Fixes for Power > Message-ID: <20140812145400.ga8...@afflict.kos.to> > Content-Type: text/plain; charset=us-ascii > > Hi, > > On Mon, Aug 04, 2014 at 11:45:27AM -0500, Tom Musta wrote: > > This series of patches is the result of executing the Linux Test Program > > (LTP) System Call bucket (https://github.com/linux-test-project/ltp) > > on the 64 bit big and little endian linux user mode targets for Power. > > > > Some of the changes are not technically unique to Power, but are > effectively > > so. For example, Power may be the only runtime that uses the ipc system > call > > as a hub for other system calls (semctl, semop, ...). > > Thanks for the series - Peter had some comments on a dew of them - would > you have time to address them and send a v2 series soonish? Then I can > include them in my next pull request already. > > Riku > > > The series is dependent on my previous patch series that adds signal > handler > > support on PPC64 ( > http://lists.nongnu.org/archive/html/qemu-ppc/2014-06/msg00802.html). > > That series has gone into Alex's ppcnext branch for QEMU 2.2. > > > > Tom Musta (12): > > linux-user: PPC64 semid_ds Doesnt Include _unused1 and _unused2 > > linux-user: Dereference Pointer Argument to ipc/semctl Sys Call > > linux-user: Properly Handle semun Structure In Cross-Endian > > Situations > > linux-user: Make ipc syscall's third argument an abi_long > > linux-user: Conditionally Pass Attribute Pointer to mq_open() > > linux-user: Detect Negative Message Sizes in msgsnd System Call > > linux-user: Handle NULL argument to sched_{get,set}param > > linux-user: Detect fault in sched_rr_get_interval > > linux-user: Minimum Sig Handler Stack Size for PPC64 ELF V2 > > linux-user: clock_nanosleep errno Handling on PPC > > linux-user: Support target-to-host translation of mlockall argument > > linux-user: writev Partial Writes > > > > linux-user/signal.c | 12 +++++- > > linux-user/syscall.c | 113 > ++++++++++++++++++++++++++++++++++++++++++-------- > > 2 files changed, 107 insertions(+), 18 deletions(-) > > > > > > ------------------------------ > > Message: 5 > Date: Wed, 13 Aug 2014 01:10:39 +1000 > From: Alexey Kardashevskiy <a...@ozlabs.ru> > To: Alexander Graf <ag...@suse.de>, qemu-devel@nongnu.org > Cc: Alex Williamson <alex.william...@redhat.com>, qemu-...@nongnu.org > Subject: Re: [Qemu-devel] [RFC PATCH 09/10] spapr_pci_vfio: Enable DDW > Message-ID: <53ea2e6f.6060...@ozlabs.ru> > Content-Type: text/plain; charset=koi8-r > > On 08/12/2014 07:37 PM, Alexander Graf wrote: > > > > On 12.08.14 02:03, Alexey Kardashevskiy wrote: > >> On 08/12/2014 03:30 AM, Alexander Graf wrote: > >>> On 11.08.14 17:01, Alexey Kardashevskiy wrote: > >>>> On 08/11/2014 10:02 PM, Alexander Graf wrote: > >>>>> On 31.07.14 11:34, Alexey Kardashevskiy wrote: > >>>>>> This implements DDW for VFIO. Host kernel support is required for > this. > >>>>>> > >>>>>> Signed-off-by: Alexey Kardashevskiy <a...@ozlabs.ru> > >>>>>> --- > >>>>>> hw/ppc/spapr_pci_vfio.c | 75 > >>>>>> +++++++++++++++++++++++++++++++++++++++++++++++++ > >>>>>> 1 file changed, 75 insertions(+) > >>>>>> > >>>>>> diff --git a/hw/ppc/spapr_pci_vfio.c b/hw/ppc/spapr_pci_vfio.c > >>>>>> index d3bddf2..dc443e2 100644 > >>>>>> --- a/hw/ppc/spapr_pci_vfio.c > >>>>>> +++ b/hw/ppc/spapr_pci_vfio.c > >>>>>> @@ -69,6 +69,77 @@ static void > >>>>>> spapr_phb_vfio_finish_realize(sPAPRPHBState *sphb, Error **errp) > >>>>>> /* Register default 32bit DMA window */ > >>>>>> memory_region_add_subregion(&sphb->iommu_root, > tcet->bus_offset, > >>>>>> spapr_tce_get_iommu(tcet)); > >>>>>> + > >>>>>> + sphb->ddw_supported = !!(info.flags & > >>>>>> VFIO_IOMMU_SPAPR_TCE_FLAG_DDW); > >>>>>> +} > >>>>>> + > >>>>>> +static int spapr_pci_vfio_ddw_query(sPAPRPHBState *sphb, > >>>>>> + uint32_t *windows_available, > >>>>>> + uint32_t *page_size_mask) > >>>>>> +{ > >>>>>> + sPAPRPHBVFIOState *svphb = SPAPR_PCI_VFIO_HOST_BRIDGE(sphb); > >>>>>> + struct vfio_iommu_spapr_tce_query query = { .argsz = > >>>>>> sizeof(query) }; > >>>>>> + int ret; > >>>>>> + > >>>>>> + ret = vfio_container_ioctl(&sphb->iommu_as, > svphb->iommugroupid, > >>>>>> + VFIO_IOMMU_SPAPR_TCE_QUERY, &query); > >>>>>> + if (ret) { > >>>>>> + return ret; > >>>>>> + } > >>>>>> + > >>>>>> + *windows_available = query.windows_available; > >>>>>> + *page_size_mask = query.page_size_mask; > >>>>>> + > >>>>>> + return ret; > >>>>>> +} > >>>>>> + > >>>>>> +static int spapr_pci_vfio_ddw_create(sPAPRPHBState *sphb, uint32_t > >>>>>> page_shift, > >>>>>> + uint32_t window_shift, > uint32_t > >>>>>> liobn, > >>>>>> + sPAPRTCETable **ptcet) > >>>>>> +{ > >>>>>> + sPAPRPHBVFIOState *svphb = SPAPR_PCI_VFIO_HOST_BRIDGE(sphb); > >>>>>> + struct vfio_iommu_spapr_tce_create create = { > >>>>>> + .argsz = sizeof(create), > >>>>>> + .page_shift = page_shift, > >>>>>> + .window_shift = window_shift, > >>>>>> + .start_addr = 0 > >>>>>> + }; > >>>>>> + int ret; > >>>>>> + > >>>>>> + ret = vfio_container_ioctl(&sphb->iommu_as, > svphb->iommugroupid, > >>>>>> + VFIO_IOMMU_SPAPR_TCE_CREATE, > &create); > >>>>>> + if (ret) { > >>>>>> + return ret; > >>>>>> + } > >>>>>> + > >>>>>> + *ptcet = spapr_tce_new_table(DEVICE(sphb), liobn, > >>>>>> create.start_addr, > >>>>>> + page_shift, 1 << (window_shift - > >>>>>> page_shift), > >>>>> I spot a 1 without ULL again - this time it might work out ok, but > please > >>>>> just always use ULL when you pass around addresses. > >>>> My bad. I keep forgetting this, I'll adjust my own checkpatch.py :) > >>>> > >>>> > >>>>> Please walk me though the abstraction levels on what each page size > >>>>> honoration means. If I use THP, what page size granularity can I use > for > >>>>> TCE entries? > >>>> [RFC PATCH 06/10] spapr_rtas: Add Dynamic DMA windows (DDW) RTAS calls > >>>> support > >>>> > >>>> + const struct { int shift; uint32_t mask; } masks[] = { > >>>> + { 12, DDW_PGSIZE_4K }, > >>>> + { 16, DDW_PGSIZE_64K }, > >>>> + { 24, DDW_PGSIZE_16M }, > >>>> + { 25, DDW_PGSIZE_32M }, > >>>> + { 26, DDW_PGSIZE_64M }, > >>>> + { 27, DDW_PGSIZE_128M }, > >>>> + { 28, DDW_PGSIZE_256M }, > >>>> + { 34, DDW_PGSIZE_16G }, > >>>> + }; > >>>> > >>>> > >>>> Supported page sizes are returned by the host kernel via "query". For > 16MB > >>>> pages, page shift will return > DDW_PGSIZE_4K|DDW_PGSIZE_64K|DDW_PGSIZE_16M. > >>>> Or I did not understand the question... > >>> Why do we care about the sizes? Anything bigger than what we support > should > >>> always work, no? What happens if the guest creates a 16MB map but my > pages > >>> are 4kb mapped? Wouldn't the same logic be able to deal with 16G pages? > >> It is DMA memory, if I split "virtual" 16M page to a bunch of real 4K > >> pages, I have to make sure these 16M are continuous - there will be one > TCE > >> entry for it and no more translations besides IOMMU. What do I miss now? > > > > Who does the shadow translation where? Does it exist at all? > > IOMMU? I am not sure I am following you... This IOMMU will look as direct > DMA for the guest but the real IOMMU table is sparse and it is populated > via a bunch of H_PUT_TCE calls as the default small window. > > There is a direct mapping in the host called "bypass window" but it is not > used here as sPAPR does not define that for paravirtualization. > > > -- > Alexey > > > > ------------------------------ > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/qemu-devel > > > End of Qemu-devel Digest, Vol 137, Issue 360 > ******************************************** >
