* Re: [Qemu-devel] Qemu-devel Digest, Vol 137, Issue 360
[not found] <mailman.112838.1407856267.1146.qemu-devel@nongnu.org>
@ 2014-08-12 15:21 ` Moer Cos
2014-08-12 15:37 ` Eric Blake
0 siblings, 1 reply; 2+ messages in thread
From: Moer Cos @ 2014-08-12 15:21 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 22251 bytes --]
help
2014-08-12 23:11 GMT+08:00 <qemu-devel-request@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-request@nongnu.org
>
> You can reach the person managing the list at
> qemu-devel-owner@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 <danielhb@linux.vnet.ibm.com>
> To: Qemu Devel <qemu-devel@nongnu.org>
> Cc: Kevin Wolf <kwolf@redhat.com>, Daniel Henrique Barboza
> <danielhb@linux.vnet.ibm.com>, Stefan Hajnoczi <
> stefanha@redhat.com>
> Subject: [Qemu-devel] [PATCH] block.curl: adding 'curltimeout' option
> Message-ID:
> <1407854125-25068-1-git-send-email-danielhb@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 <danielhb@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 <armbru@redhat.com>
> To: qemu-devel@nongnu.org
> Cc: aliguori@amazon.com, mst@redhat.com
> Subject: [Qemu-devel] [PATCH] pc: Get rid of pci-info leftovers
> Message-ID: <1407854417-32071-1-git-send-email-armbru@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 <armbru@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 <eyalpe@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.malone@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.voipio@iki.fi>
> To: Tom Musta <tommusta@gmail.com>
> Cc: riku.voipio@linaro.org, qemu-ppc@nongnu.org,
> qemu-devel@nongnu.org, agraf@suse.de
> Subject: Re: [Qemu-devel] [PATCH 00/12] target-ppc: Linux-User Mode
> Bug Fixes for Power
> Message-ID: <20140812145400.GA8413@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 <aik@ozlabs.ru>
> To: Alexander Graf <agraf@suse.de>, qemu-devel@nongnu.org
> Cc: Alex Williamson <alex.williamson@redhat.com>, qemu-ppc@nongnu.org
> Subject: Re: [Qemu-devel] [RFC PATCH 09/10] spapr_pci_vfio: Enable DDW
> Message-ID: <53EA2E6F.6060002@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 <aik@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
> ********************************************
>
[-- Attachment #2: Type: text/html, Size: 29877 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread