|
| From: | Moer Cos |
| Subject: | Re: [Qemu-devel] Qemu-devel Digest, Vol 137, Issue 360 |
| Date: | Tue, 12 Aug 2014 23:21:28 +0800 |
Send Qemu-devel mailing list submissions to
address@hidden
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
address@hidden
You can reach the person managing the list at
address@hidden
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 <address@hidden>
To: Qemu Devel <address@hidden>
Cc: Kevin Wolf <address@hidden>, Daniel Henrique Barboza
<address@hidden>, Stefan Hajnoczi <address@hidden>
Subject: [Qemu-devel] [PATCH] block.curl: adding 'curltimeout' option
Message-ID:
<address@hidden>
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 <address@hidden>
---
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.
address@hidden 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'.
+
address@hidden 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.
address@hidden 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
address@hidden 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.
address@hidden
-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
address@hidden example
--
1.8.3.1
------------------------------
Message: 2
Date: Tue, 12 Aug 2014 16:40:17 +0200
From: Markus Armbruster <address@hidden>
To: address@hidden
Cc: address@hidden, address@hidden
Subject: [Qemu-devel] [PATCH] pc: Get rid of pci-info leftovers
Message-ID: <address@hidden>
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 <address@hidden>
---
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 <address@hidden>
To: address@hidden
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: <address@hidden>
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 <address@hidden>
To: Tom Musta <address@hidden>
Cc: address@hidden, address@hidden,
address@hidden, address@hidden
Subject: Re: [Qemu-devel] [PATCH 00/12] target-ppc: Linux-User Mode
Bug Fixes for Power
Message-ID: <address@hidden>
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 <address@hidden>
To: Alexander Graf <address@hidden>, address@hidden
Cc: Alex Williamson <address@hidden>, address@hidden
Subject: Re: [Qemu-devel] [RFC PATCH 09/10] spapr_pci_vfio: Enable DDW
Message-ID: <address@hidden>
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 <address@hidden>
>>>>>> ---
>>>>>> 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
address@hidden
https://lists.nongnu.org/mailman/listinfo/qemu-devel
End of Qemu-devel Digest, Vol 137, Issue 360
********************************************
| [Prev in Thread] | Current Thread | [Next in Thread] |