Re: [PATCH] qdev: not add devices to bus in reverse order
On 1/18/24 20:07, Igor Mammedov wrote:
On Thu, 18 Jan 2024 14:48:50 +0800
Kai wrote:
On 1/18/24 01:31, Peter Maydell wrote:
(cc'd the people listed for this file in MAINTAINERS)
On Tue, 9 Jan 2024 at 13:53, Kai Kang wrote:
When this section of source codes were added via commit:
* 02e2da45c4 Add common BusState
it added devices to bus with LIST_INSERT_HEAD() which operated on the
single direction list. It didn't have something like LIST_INSERT_TAIL()
at that time and kept that way when turned to QTAILQ.
Then it causes the fist device in qemu command line inserted at the end
of the bus child link list. And when realize them, the first device will
be the last one to be realized.
Replace QTAILQ_INSERT_HEAD_RCU() with QTAILQ_INSERT_TAIL_RCU() to make
sure that devices are added to bus with the sequence in the command
line.
What are the problems being caused by the the list items being added
in reverse order? Your commit message doesn't say what specific
bug or problem it's trying to fix.
The problem I met was just as I asked for for help in the maillist on
Dec 18, 2023.
The indexes of serial isa devices changes with the commit dcdbfaafe90a
since qemu 6.2.0.
Before the commit, it creates devices literally with "1" & "2":
@@ -1252,8 +1222,6 @@ static void build_isa_devices_aml(Aml *table)
aml_append(scope, build_fdc_device_aml(fdc));
}
aml_append(scope, build_lpt_device_aml());
- build_com_device_aml(scope, 1);
- build_com_device_aml(scope, 2);
After apply the commit, it uses the 'aml builder' way and the devices
are handled in reverse way.
Then the indexes are reversed. It affects guest os such as freebsd. When
run `pstat -t` on freebsd
with qemu, the sequence of the output is not right.
root@freebsd:~ # pstat -t
LINE INQ CAN LIN LOW OUTQ USE LOW COL SESS PGID STATE
ttyu2 0 0 0 0 0 0 0 0 0 0 IC
ttyu3 0 0 0 0 0 0 0 0 0 0 IC
ttyu1 0 0 0 0 0 0 0 0 0 0 IC
ttyu0 1920 0 0 192 1984 0 199 0 664 668 ICOi
It is expected with ascend order which keeps the same behavior with
older version qemu.
Hi Peter & Igor,
Thanks for your reply.
this problem description should be in commit message.
Will do next time.
As for fixing it I'd wouldn't touch bus order as Peter already noted
it has high chances to break behavior elsewhere.
current state of COM naming:
1: QEMU 6.1 all machine types: COM1 { uid: 1, irq: 4}, COM2 { uid: 2, irq:
3}
2: QEMU 6.2+ all machine types: COM1 { uid: 2, irq: 4}, COM1 { uid: 1, irq:
3}
all of above in default case where user doesn't supply 'index' explicitly.
With 'index' provided explicitly old case #1 might break due to
hardcoded resource values in former build_com_device_aml().
#2 (current code) doesn't have issues with resource values
when explicit 'index' is used (which can be a possible workaround)
How to assign explicit 'index' in the command line? I don't figure it
out the option for it.
So we essentially have changed enumeration for 6.1 and older
machine types in incompatible way with QEMU-6.2+ builds.
(and that in it's turn breaks exiting VM config when it
is started on QEMU-6.2+)
Kai,
Does above sum-up the issue you are encountering?
Yes, it does.
Thanks,
Kai
Regards,
Kai
In general this kind of patch is something I'm very cautious about,
because it seems very likely that various bits of the code where
order does matter will currently be expecting (and working around)
the reverse-order behaviour, because that's what has been done by
bus_add_child() for the last 20-plus years. (As one concrete example,
see the big comment at the top of create_virtio_devices() in
hw/arm/virt.c. There are probably others where we didn't comment
on the ordering but just assume it.)
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 43d863b0c5..5e2ff43715 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -89,7 +89,7 @@ static void bus_add_child(BusState *bus, DeviceState *child)
kid->child = child;
object_ref(OBJECT(kid->child));
-QTAILQ_INSERT_HEAD_RCU(>children, kid, sibling);
+QTAILQ_INSERT_TAIL_RCU(>children, kid, sibling);
/* This transfers ownership of kid->child to the property. */
snprintf(name, sizeof(name), "child[%d]", kid->index);
thanks
-- PMM
--
Kai Kang
Wind River Linux
Re: [PATCH] qdev: not add devices to bus in reverse order
On 1/18/24 01:31, Peter Maydell wrote: (cc'd the people listed for this file in MAINTAINERS) On Tue, 9 Jan 2024 at 13:53, Kai Kang wrote: When this section of source codes were added via commit: * 02e2da45c4 Add common BusState it added devices to bus with LIST_INSERT_HEAD() which operated on the single direction list. It didn't have something like LIST_INSERT_TAIL() at that time and kept that way when turned to QTAILQ. Then it causes the fist device in qemu command line inserted at the end of the bus child link list. And when realize them, the first device will be the last one to be realized. Replace QTAILQ_INSERT_HEAD_RCU() with QTAILQ_INSERT_TAIL_RCU() to make sure that devices are added to bus with the sequence in the command line. What are the problems being caused by the the list items being added in reverse order? Your commit message doesn't say what specific bug or problem it's trying to fix. The problem I met was just as I asked for for help in the maillist on Dec 18, 2023. The indexes of serial isa devices changes with the commit dcdbfaafe90a since qemu 6.2.0. Before the commit, it creates devices literally with "1" & "2": @@ -1252,8 +1222,6 @@ static void build_isa_devices_aml(Aml *table) aml_append(scope, build_fdc_device_aml(fdc)); } aml_append(scope, build_lpt_device_aml()); - build_com_device_aml(scope, 1); - build_com_device_aml(scope, 2); After apply the commit, it uses the 'aml builder' way and the devices are handled in reverse way. Then the indexes are reversed. It affects guest os such as freebsd. When run `pstat -t` on freebsd with qemu, the sequence of the output is not right. root@freebsd:~ # pstat -t LINE INQ CAN LIN LOW OUTQ USE LOW COL SESS PGID STATE ttyu2 0 0 0 0 0 0 0 0 0 0 IC ttyu3 0 0 0 0 0 0 0 0 0 0 IC ttyu1 0 0 0 0 0 0 0 0 0 0 IC ttyu0 1920 0 0 192 1984 0 199 0 664 668 ICOi It is expected with ascend order which keeps the same behavior with older version qemu. Regards, Kai In general this kind of patch is something I'm very cautious about, because it seems very likely that various bits of the code where order does matter will currently be expecting (and working around) the reverse-order behaviour, because that's what has been done by bus_add_child() for the last 20-plus years. (As one concrete example, see the big comment at the top of create_virtio_devices() in hw/arm/virt.c. There are probably others where we didn't comment on the ordering but just assume it.) diff --git a/hw/core/qdev.c b/hw/core/qdev.c index 43d863b0c5..5e2ff43715 100644 --- a/hw/core/qdev.c +++ b/hw/core/qdev.c @@ -89,7 +89,7 @@ static void bus_add_child(BusState *bus, DeviceState *child) kid->child = child; object_ref(OBJECT(kid->child)); -QTAILQ_INSERT_HEAD_RCU(>children, kid, sibling); +QTAILQ_INSERT_TAIL_RCU(>children, kid, sibling); /* This transfers ownership of kid->child to the property. */ snprintf(name, sizeof(name), "child[%d]", kid->index); thanks -- PMM -- Kai Kang Wind River Linux
Re: [PATCH] qdev: not add devices to bus in reverse order
On 1/9/24 17:52, kai.k...@windriver.com wrote: From: Kai Kang When this section of source codes were added via commit: * 02e2da45c4 Add common BusState it added devices to bus with LIST_INSERT_HEAD() which operated on the single direction list. It didn't have something like LIST_INSERT_TAIL() at that time and kept that way when turned to QTAILQ. Then it causes the fist device in qemu command line inserted at the end of the bus child link list. And when realize them, the first device will be the last one to be realized. Replace QTAILQ_INSERT_HEAD_RCU() with QTAILQ_INSERT_TAIL_RCU() to make sure that devices are added to bus with the sequence in the command line. Ping. Signed-off-by: Kai Kang --- hw/core/qdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/core/qdev.c b/hw/core/qdev.c index 43d863b0c5..5e2ff43715 100644 --- a/hw/core/qdev.c +++ b/hw/core/qdev.c @@ -89,7 +89,7 @@ static void bus_add_child(BusState *bus, DeviceState *child) kid->child = child; object_ref(OBJECT(kid->child)); -QTAILQ_INSERT_HEAD_RCU(>children, kid, sibling); +QTAILQ_INSERT_TAIL_RCU(>children, kid, sibling); /* This transfers ownership of kid->child to the property. */ snprintf(name, sizeof(name), "child[%d]", kid->index); -- Kai Kang Wind River Linux
[PATCH] qdev: not add devices to bus in reverse order
When this section of source codes were added via commit: * 02e2da45c4 Add common BusState it added devices to bus with LIST_INSERT_HEAD() which operated on the single direction list. It didn't have something like LIST_INSERT_TAIL() at that time and kept that way when turned to QTAILQ. Then it causes the fist device in qemu command line inserted at the end of the bus child link list. And when realize them, the first device will be the last one to be realized. Replace QTAILQ_INSERT_HEAD_RCU() with QTAILQ_INSERT_TAIL_RCU() to make sure that devices are added to bus with the sequence in the command line. Signed-off-by: Kai Kang --- hw/core/qdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/core/qdev.c b/hw/core/qdev.c index 43d863b0c5..5e2ff43715 100644 --- a/hw/core/qdev.c +++ b/hw/core/qdev.c @@ -89,7 +89,7 @@ static void bus_add_child(BusState *bus, DeviceState *child) kid->child = child; object_ref(OBJECT(kid->child)); -QTAILQ_INSERT_HEAD_RCU(>children, kid, sibling); +QTAILQ_INSERT_TAIL_RCU(>children, kid, sibling); /* This transfers ownership of kid->child to the property. */ snprintf(name, sizeof(name), "child[%d]", kid->index); -- 2.34.1
isa serial char devices created with reverse order since qemu 6.2.0
Hi, I am working on qemu 6.2.0 for isa serial char device in hw/char/serial-isa.c. It once creates 2 ports with "1" and "2" literally. But with the following commit commit dcdbfaafe90a5e6e172368b2aa5500a9ca192e49 Author: Gerd Hoffmann Date: Fri May 15 17:04:10 2020 +0200 acpi: move aml builder code for serial device The code uses the isa_serial_io array to figure what the device uid is. Side effect is that acpi antries are not limited to port 1+2 any more, we'll also get entries for ports 3+4. they are created in reverse order with 4,3,2,1. With the following command, # qemu-system-x86_64 -enable-kvm -S -cpu Conroe -m 2048 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0,index=0 -chardev tty,id=charserial1,path=/dev/ttyS1 -device isa-serial,chardev=charserial1,id=serial1,index=1 It calls the realize function serial_isa_realizefn() with indexes "0" and "1". But calls serial_isa_build_aml() with 1 and 0. I didn't figure out the root cause. Which part of source codes should I focus on next please? Or fortunately someone just knows the root cause. Thanks a lot. -- Kai Kang Wind River Linux
Re: [PATCH v3] target/i386: Change wrong XFRM value
On Thu, 2023-04-06 at 02:40 -0400, Yang Zhong wrote:
> The previous patch wrongly replaced FEAT_XSAVE_XCR0_{LO|HI} with
> FEAT_XSAVE_XSS_{LO|HI} in CPUID(EAX=12,ECX=1):{ECX,EDX}, which made
> SGX enclave only supported SSE and x87 feature(xfrm=0x3).
I don't particularly like the sentence's second half, and looks it's better to
also call out "wrong XFRM value in SGX CPUID leaf" in the patch title.
Anyway ...
>
> Fixes: 301e90675c3f ("target/i386: Enable support for XSAVES based features")
>
> Signed-off-by: Yang Zhong
> Reviewed-by: Yang Weijiang
...
Reviewed-by: Kai Huang
> ---
> target/i386/cpu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 6576287e5b..f083ff4335 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -5718,8 +5718,8 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
> uint32_t count,
> } else {
> *eax &= env->features[FEAT_SGX_12_1_EAX];
> *ebx &= 0; /* ebx reserve */
> -*ecx &= env->features[FEAT_XSAVE_XSS_LO];
> -*edx &= env->features[FEAT_XSAVE_XSS_HI];
> +*ecx &= env->features[FEAT_XSAVE_XCR0_LO];
> +*edx &= env->features[FEAT_XSAVE_XCR0_HI];
>
> /* FP and SSE are always allowed regardless of XSAVE/XCR0. */
> *ecx |= XSTATE_FP_MASK | XSTATE_SSE_MASK;
Re: [PATCH v10 1/9] mm: Introduce memfd_restricted system call to create restricted user memory
On Mon, 2023-01-23 at 15:03 +0100, Vlastimil Babka wrote:
> On 12/22/22 01:37, Huang, Kai wrote:
> > > > I argue that this page pinning (or page migration prevention) is not
> > > > tied to where the page comes from, instead related to how the page will
> > > > be used. Whether the page is restrictedmem backed or GUP() backed, once
> > > > it's used by current version of TDX then the page pinning is needed. So
> > > > such page migration prevention is really TDX thing, even not KVM generic
> > > > thing (that's why I think we don't need change the existing logic of
> > > > kvm_release_pfn_clean()).
> > > >
> > This essentially boils down to who "owns" page migration handling, and
> > sadly,
> > page migration is kinda "owned" by the core-kernel, i.e. KVM cannot handle
> > page
> > migration by itself -- it's just a passive receiver.
> >
> > For normal pages, page migration is totally done by the core-kernel (i.e. it
> > unmaps page from VMA, allocates a new page, and uses migrate_pape() or
> > a_ops-
> > > migrate_page() to actually migrate the page).
> > In the sense of TDX, conceptually it should be done in the same way. The
> > more
> > important thing is: yes KVM can use get_page() to prevent page migration,
> > but
> > when KVM wants to support it, KVM cannot just remove get_page(), as the
> > core-
> > kernel will still just do migrate_page() which won't work for TDX (given
> > restricted_memfd doesn't have a_ops->migrate_page() implemented).
> >
> > So I think the restricted_memfd filesystem should own page migration
> > handling,
> > (i.e. by implementing a_ops->migrate_page() to either just reject page
> > migration
> > or somehow support it).
>
> While this thread seems to be settled on refcounts already,
>
I am not sure but will let Sean/Paolo to decide.
> just wanted
> to point out that it wouldn't be ideal to prevent migrations by
> a_ops->migrate_page() rejecting them. It would mean cputime wasted (i.e.
> by memory compaction) by isolating the pages for migration and then
> releasing them after the callback rejects it (at least we wouldn't waste
> time creating and undoing migration entries in the userspace page tables
> as there's no mmap). Elevated refcount on the other hand is detected
> very early in compaction so no isolation is attempted, so from that
> aspect it's optimal.
I am probably missing something, but IIUC the checking of refcount happens at
very last stage of page migration too, for instance:
migrate_folio(...) ->
migrate_folio_extra(..., 0 /* extra_count */) ->
folio_migrate_mapping(...).
And it is folio_migrate_mapping() who does the actual compare with the refcount,
which is at very late stage too:
int folio_migrate_mapping(struct address_space *mapping,
struct folio *newfolio, struct folio *folio, int extra_count)
{
...
int expected_count = folio_expected_refs(mapping, folio) + extra_count;
if (!mapping) {
/* Anonymous page without mapping */
if (folio_ref_count(folio) != expected_count)
return -EAGAIN;
return MIGRATEPAGE_SUCCESS;
}
if (!folio_ref_freeze(folio, expected_count)) {
xas_unlock_irq();
return -EAGAIN;
}
...
}
Re: [PATCH v10 1/9] mm: Introduce memfd_restricted system call to create restricted user memory
On Thu, 2022-12-22 at 18:15 +, Sean Christopherson wrote: > On Wed, Dec 21, 2022, Chao Peng wrote: > > On Tue, Dec 20, 2022 at 08:33:05AM +, Huang, Kai wrote: > > > On Tue, 2022-12-20 at 15:22 +0800, Chao Peng wrote: > > > > On Mon, Dec 19, 2022 at 08:48:10AM +, Huang, Kai wrote: > > > > > On Mon, 2022-12-19 at 15:53 +0800, Chao Peng wrote: > > > But for non-restricted-mem case, it is correct for KVM to decrease page's > > > refcount after setting up mapping in the secondary mmu, otherwise the > > > page will > > > be pinned by KVM for normal VM (since KVM uses GUP to get the page). > > > > That's true. Actually even true for restrictedmem case, most likely we > > will still need the kvm_release_pfn_clean() for KVM generic code. On one > > side, other restrictedmem users like pKVM may not require page pinning > > at all. On the other side, see below. > > > > > > > > So what we are expecting is: for KVM if the page comes from restricted > > > mem, then > > > KVM cannot decrease the refcount, otherwise for normal page via GUP KVM > > > should. > > No, requiring the user (KVM) to guard against lack of support for page > migration > in restricted mem is a terrible API. It's totally fine for restricted mem to > not > support page migration until there's a use case, but punting the problem to > KVM > is not acceptable. Restricted mem itself doesn't yet support page migration, > e.g. explosions would occur even if KVM wanted to allow migration since there > is > no notification to invalidate existing mappings. > > Yes totally agree (I also replied separately).
Re: [PATCH v10 1/9] mm: Introduce memfd_restricted system call to create restricted user memory
On Wed, 2022-12-21 at 21:39 +0800, Chao Peng wrote: > > On Tue, Dec 20, 2022 at 08:33:05AM +, Huang, Kai wrote: > > > > On Tue, 2022-12-20 at 15:22 +0800, Chao Peng wrote: > > > > > > On Mon, Dec 19, 2022 at 08:48:10AM +, Huang, Kai wrote: > > > > > > > > On Mon, 2022-12-19 at 15:53 +0800, Chao Peng wrote: > > > > > > > > > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > > > > > > > > > + > > > > > > > > > > > > > > + /* > > > > > > > > > > > > > > +* These pages are currently unmovable so don't > > > > > > > > > > > > > > place them into > > > > > > > > > > > > > > movable > > > > > > > > > > > > > > +* pageblocks (e.g. CMA and ZONE_MOVABLE). > > > > > > > > > > > > > > +*/ > > > > > > > > > > > > > > + mapping = memfd->f_mapping; > > > > > > > > > > > > > > + mapping_set_unevictable(mapping); > > > > > > > > > > > > > > + mapping_set_gfp_mask(mapping, > > > > > > > > > > > > > > + mapping_gfp_mask(mapping) > > > > > > > > > > > > > > & ~__GFP_MOVABLE); > > > > > > > > > > > > > > > > > > > > > > > > But, IIUC removing __GFP_MOVABLE flag here only makes > > > > > > > > > > > > page allocation from > > > > > > > > > > > > non- > > > > > > > > > > > > movable zones, but doesn't necessarily prevent page > > > > > > > > > > > > from being migrated. My > > > > > > > > > > > > first glance is you need to implement either > > > > > > > > > > > > a_ops->migrate_folio() or just > > > > > > > > > > > > get_page() after faulting in the page to prevent. > > > > > > > > > > > > > > > > > > > > The current api restrictedmem_get_page() already does this, > > > > > > > > > > after the > > > > > > > > > > caller calling it, it holds a reference to the page. The > > > > > > > > > > caller then > > > > > > > > > > decides when to call put_page() appropriately. > > > > > > > > > > > > > > > > I tried to dig some history. Perhaps I am missing something, > > > > > > > > but it seems Kirill > > > > > > > > said in v9 that this code doesn't prevent page migration, and > > > > > > > > we need to > > > > > > > > increase page refcount in restrictedmem_get_page(): > > > > > > > > > > > > > > > > https://lore.kernel.org/linux-mm/20221129112139.usp6dqhbih47q...@box.shutemov.name/ > > > > > > > > > > > > > > > > But looking at this series it seems restrictedmem_get_page() in > > > > > > > > this v10 is > > > > > > > > identical to the one in v9 (except v10 uses 'folio' instead of > > > > > > > > 'page')? > > > > > > > > > > > > restrictedmem_get_page() increases page refcount several versions > > > > > > ago so > > > > > > no change in v10 is needed. You probably missed my reply: > > > > > > > > > > > > https://lore.kernel.org/linux-mm/20221129135844.ga902...@chaop.bj.intel.com/ > > > > > > > > But for non-restricted-mem case, it is correct for KVM to decrease > > > > page's > > > > refcount after setting up mapping in the secondary mmu, otherwise the > > > > page will > > > > be pinned by KVM for normal VM (since KVM uses GUP to get the page). > > > > That's true. Actually even true for restrictedmem case, most likely we > > will still need the kvm_release_pfn_clean() for KVM generic code. On one > > side, other restrictedmem users like pKVM may not require page pi
Re: [PATCH v10 1/9] mm: Introduce memfd_restricted system call to create restricted user memory
On Tue, 2022-12-20 at 15:22 +0800, Chao Peng wrote: > On Mon, Dec 19, 2022 at 08:48:10AM +, Huang, Kai wrote: > > On Mon, 2022-12-19 at 15:53 +0800, Chao Peng wrote: > > > > > > > > [...] > > > > > > > > > + > > > > > + /* > > > > > + * These pages are currently unmovable so don't place them into > > > > > movable > > > > > + * pageblocks (e.g. CMA and ZONE_MOVABLE). > > > > > + */ > > > > > + mapping = memfd->f_mapping; > > > > > + mapping_set_unevictable(mapping); > > > > > + mapping_set_gfp_mask(mapping, > > > > > + mapping_gfp_mask(mapping) & > > > > > ~__GFP_MOVABLE); > > > > > > > > But, IIUC removing __GFP_MOVABLE flag here only makes page allocation > > > > from > > > > non- > > > > movable zones, but doesn't necessarily prevent page from being > > > > migrated. My > > > > first glance is you need to implement either a_ops->migrate_folio() or > > > > just > > > > get_page() after faulting in the page to prevent. > > > > > > The current api restrictedmem_get_page() already does this, after the > > > caller calling it, it holds a reference to the page. The caller then > > > decides when to call put_page() appropriately. > > > > I tried to dig some history. Perhaps I am missing something, but it seems > > Kirill > > said in v9 that this code doesn't prevent page migration, and we need to > > increase page refcount in restrictedmem_get_page(): > > > > https://lore.kernel.org/linux-mm/20221129112139.usp6dqhbih47q...@box.shutemov.name/ > > > > But looking at this series it seems restrictedmem_get_page() in this v10 is > > identical to the one in v9 (except v10 uses 'folio' instead of 'page')? > > restrictedmem_get_page() increases page refcount several versions ago so > no change in v10 is needed. You probably missed my reply: > > https://lore.kernel.org/linux-mm/20221129135844.ga902...@chaop.bj.intel.com/ But for non-restricted-mem case, it is correct for KVM to decrease page's refcount after setting up mapping in the secondary mmu, otherwise the page will be pinned by KVM for normal VM (since KVM uses GUP to get the page). So what we are expecting is: for KVM if the page comes from restricted mem, then KVM cannot decrease the refcount, otherwise for normal page via GUP KVM should. > > The current solution is clear: unless we have better approach, we will > let restrictedmem user (KVM in this case) to hold the refcount to > prevent page migration. > OK. Will leave to others :)
Re: [PATCH v10 1/9] mm: Introduce memfd_restricted system call to create restricted user memory
On Mon, 2022-12-19 at 15:53 +0800, Chao Peng wrote: > > > > [...] > > > > > + > > > + /* > > > + * These pages are currently unmovable so don't place them into > > > movable > > > + * pageblocks (e.g. CMA and ZONE_MOVABLE). > > > + */ > > > + mapping = memfd->f_mapping; > > > + mapping_set_unevictable(mapping); > > > + mapping_set_gfp_mask(mapping, > > > + mapping_gfp_mask(mapping) & ~__GFP_MOVABLE); > > > > But, IIUC removing __GFP_MOVABLE flag here only makes page allocation from > > non- > > movable zones, but doesn't necessarily prevent page from being migrated. My > > first glance is you need to implement either a_ops->migrate_folio() or just > > get_page() after faulting in the page to prevent. > > The current api restrictedmem_get_page() already does this, after the > caller calling it, it holds a reference to the page. The caller then > decides when to call put_page() appropriately. I tried to dig some history. Perhaps I am missing something, but it seems Kirill said in v9 that this code doesn't prevent page migration, and we need to increase page refcount in restrictedmem_get_page(): https://lore.kernel.org/linux-mm/20221129112139.usp6dqhbih47q...@box.shutemov.name/ But looking at this series it seems restrictedmem_get_page() in this v10 is identical to the one in v9 (except v10 uses 'folio' instead of 'page')? Anyway if this is not fixed, then it should be fixed. Otherwise, a comment at the place where page refcount is increased will be helpful to help people understand page migration is actually prevented.
Re: [PATCH v10 6/9] KVM: Unmap existing mappings when change the memory attributes
On Fri, 2022-12-02 at 14:13 +0800, Chao Peng wrote: > > - /* flags is currently not used. */ > + /* 'flags' is currently not used. */ > if (attrs->flags) > return -EINVAL; Unintended code change.
Re: [PATCH v10 1/9] mm: Introduce memfd_restricted system call to create restricted user memory
> > memfd_restricted() itself is implemented as a shim layer on top of real > memory file systems (currently tmpfs). Pages in restrictedmem are marked > as unmovable and unevictable, this is required for current confidential > usage. But in future this might be changed. > > I didn't dig full histroy, but I interpret this as we don't support page migration and swapping for restricted memfd for now. IMHO "page marked as unmovable" can be confused with PageMovable(), which is a different thing from this series. It's better to just say something like "those pages cannot be migrated and swapped". [...] > + > + /* > + * These pages are currently unmovable so don't place them into movable > + * pageblocks (e.g. CMA and ZONE_MOVABLE). > + */ > + mapping = memfd->f_mapping; > + mapping_set_unevictable(mapping); > + mapping_set_gfp_mask(mapping, > + mapping_gfp_mask(mapping) & ~__GFP_MOVABLE); But, IIUC removing __GFP_MOVABLE flag here only makes page allocation from non- movable zones, but doesn't necessarily prevent page from being migrated. My first glance is you need to implement either a_ops->migrate_folio() or just get_page() after faulting in the page to prevent. So I think the comment also needs improvement -- IMHO we can just call out currently those pages cannot be migrated and swapped, which is clearer (and the latter justifies mapping_set_unevictable() clearly).
[PATCH] target/i386: Add SGX aex-notify and EDECCSSA support
The new SGX Asynchronous Exit (AEX) notification mechanism (AEX-notify)
allows one enclave to receive a notification in the ERESUME after the
enclave exit due to an AEX. EDECCSSA is a new SGX user leaf function
(ENCLU[EDECCSSA]) to facilitate the AEX notification handling.
Whether the hardware supports to create enclave with AEX-notify support
is enumerated via CPUID.(EAX=0x12,ECX=0x1):EAX[10]. The new EDECCSSA
user leaf function is enumerated via CPUID.(EAX=0x12,ECX=0x0):EAX[11].
Add support to allow to expose the new SGX AEX-notify feature and the
new EDECCSSA user leaf function to KVM guest.
Link:
https://lore.kernel.org/lkml/166760360549.4906.809756297092548496.tip-bot2@tip-bot2/
Link:
https://lore.kernel.org/lkml/166760360934.4906.2427175408052308969.tip-bot2@tip-bot2/
Reviewed-by: Yang Zhong
Signed-off-by: Kai Huang
---
target/i386/cpu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 22b681ca37dd..51f212cef50d 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -1233,7 +1233,7 @@ FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
.feat_names = {
"sgx1", "sgx2", NULL, NULL,
NULL, NULL, NULL, NULL,
-NULL, NULL, NULL, NULL,
+NULL, NULL, NULL, "sgx-edeccssa",
NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL,
@@ -1273,7 +1273,7 @@ FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
.feat_names = {
NULL, "sgx-debug", "sgx-mode64", NULL,
"sgx-provisionkey", "sgx-tokenkey", NULL, "sgx-kss",
-NULL, NULL, NULL, NULL,
+NULL, NULL, "sgx-aex-notify", NULL,
NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL,
base-commit: 466e81ff12013d026e2d0154266fce82bce2ee9b
--
2.38.1
Re: [PATCH] target/i386: Switch back XFRM value
On Thu, 2022-10-13 at 02:23 -0400, Yang Zhong wrote: > > > enclave only supported SSE and x87 feature(xfrm=0x3). > > > > Is this true? Perhaps I am missing something, but it seems env- > > > features[FEAT_XSAVE_XCR0_LO] only includes LBR bit, which is bit 15. > > We printed the XFRM value from SGX SDK to find this issue. I don't know how you added the print, but the exact value that set to SGX CPUID is irrelevant, as it is wrong anyway. The value can also differ when you run on different machines, etc. IMHO in changelog we just need to point out the fact that the XSAVE enabling patch wrongly messed up with SGX CPUID and this patch fixes that.
Re: [PATCH] target/i386: Switch back XFRM value
On Wed, 2022-10-12 at 04:26 -0400, Yang Zhong wrote:
> The previous patch wrongly replaced FEAT_XSAVE_XCR0_{LO|HI} with
> FEAT_XSAVE_XSS_{LO|HI} in CPUID(EAX=12,ECX=1):ECX, which made SGX
^
Nit: both ECX and EDX are wrongly set, but not only ECX.
> enclave only supported SSE and x87 feature(xfrm=0x3).
Is this true? Perhaps I am missing something, but it seems env-
>features[FEAT_XSAVE_XCR0_LO] only includes LBR bit, which is bit 15.
/* Calculate XSAVE components based on the configured CPU feature flags */
static void x86_cpu_enable_xsave_components(X86CPU *cpu)
{
...
env->features[FEAT_XSAVE_XSS_LO] = mask & CPUID_XSTATE_XSS_MASK;
...
}
/* CPUID feature bits available in XSS */
#define CPUID_XSTATE_XSS_MASK(XSTATE_ARCH_LBR_MASK)
>
> Fixes: 301e90675c3f ("target/i386: Enable support for XSAVES based features")
>
> Signed-off-by: Yang Zhong
> ---
> target/i386/cpu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index ad623d91e4..19aaed877b 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -5584,8 +5584,8 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
> uint32_t count,
> } else {
> *eax &= env->features[FEAT_SGX_12_1_EAX];
> *ebx &= 0; /* ebx reserve */
> -*ecx &= env->features[FEAT_XSAVE_XSS_LO];
> -*edx &= env->features[FEAT_XSAVE_XSS_HI];
> +*ecx &= env->features[FEAT_XSAVE_XCR0_LO];
> +*edx &= env->features[FEAT_XSAVE_XCR0_HI];
>
> /* FP and SSE are always allowed regardless of XSAVE/XCR0. */
> *ecx |= XSTATE_FP_MASK | XSTATE_SSE_MASK;
The code looks good:
Reviewed-by: Kai Huang
Re: [RESEND PATCH 13/32] linux-headers: Add placeholder for KVM_CAP_SGX_ATTRIBUTE
On Fri, 2021-04-30 at 14:24 +0800, Yang Zhong wrote:
> From: Sean Christopherson
>
> KVM_CAP_SGX_ATTRIBUTE is a proposed capability for Intel SGX that can be
> used by userspace to enable privileged attributes, e.g. access to the
> PROVISIONKEY.
>
> Signed-off-by: Sean Christopherson
> Signed-off-by: Yang Zhong
> ---
> linux-headers/linux/kvm.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
> index 020b62a619..0961b03007 100644
> --- a/linux-headers/linux/kvm.h
> +++ b/linux-headers/linux/kvm.h
> @@ -1056,6 +1056,7 @@ struct kvm_ppc_resize_hpt {
> #define KVM_CAP_ENFORCE_PV_FEATURE_CPUID 190
> #define KVM_CAP_SYS_HYPERV_CPUID 191
> #define KVM_CAP_DIRTY_LOG_RING 192
> +#define KVM_CAP_SGX_ATTRIBUTE 195
>
>
This hasn't been updated to 196.
Btw, should we just copy the latest kvm.h from linux kernel? 193-195 are
missing if only
define KVM_CAP_SGX_ATTRIBUTE here.
Re: [PATCH 13/32] linux-headers: Add placeholder for KVM_CAP_SGX_ATTRIBUTE
On Mon, 2021-04-19 at 18:01 +0800, Yang Zhong wrote:
> From: Sean Christopherson
>
> KVM_CAP_SGX_ATTRIBUTE is a proposed capability for Intel SGX that can be
> used by userspace to enable privileged attributes, e.g. access to the
> PROVISIONKEY.
>
> Signed-off-by: Sean Christopherson
> Signed-off-by: Yang Zhong
> ---
> linux-headers/linux/kvm.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
> index 020b62a619..0961b03007 100644
> --- a/linux-headers/linux/kvm.h
> +++ b/linux-headers/linux/kvm.h
> @@ -1056,6 +1056,7 @@ struct kvm_ppc_resize_hpt {
> #define KVM_CAP_ENFORCE_PV_FEATURE_CPUID 190
> #define KVM_CAP_SYS_HYPERV_CPUID 191
> #define KVM_CAP_DIRTY_LOG_RING 192
> +#define KVM_CAP_SGX_ATTRIBUTE 195
>
>
This needs to be changed to 196, since KVM SGX code has changed to 196.
Re: [RFC] cpu_map: Remove pconfig from Icelake-Server CPU model
On Mon, 2019-09-30 at 17:16 +0200, Paolo Bonzini wrote: > On 30/09/19 16:31, Hu, Robert wrote: > > > This might be a problem if there are plans to eventually make KVM support > > > pconfig, though. Paolo, Robert, are there plans to support pconfig in KVM > > > in the > > > future? > > [Robert Hoo] > > Thanks Eduardo for efforts in resolving this issue, introduced from my > > Icelake CPU > > model patch. > > I've no idea about PCONFIG's detail and plan. Let me sync with Huang, Kai > > and answer > > you soon. > > It's really, really unlikely. It's possible that some future processor > overloads PCONFIG in such a way that it will become virtualizable, but > not IceLake. I agree. Not Icelake. Thanks, -Kai > > Would it make sense for libvirt to treat absent CPU flags as "default > off" during migration, so that it can leave out the flag in the command > line if it's off? If it's on, libvirt would pass pconfig=on as usual. > This is a variant of [2], but more generally applicable: > > > [2] However starting a domain with Icelake-Server so that it can be > > migrated or saved/restored on QEMU in 3.1.1 and 4.0.0 would be > > impossible. This can be solved by a different hack, which would drop > > pconfig=off from QEMU command line. > > Paolo
Re: [PATCH] x86: Add CPUID KVM support for new instruction WBNOINVD
On Mon, 2019-09-30 at 12:23 -0700, Jim Mattson wrote: > On Mon, Sep 30, 2019 at 10:54 AM Eduardo Habkost wrote: > > CCing qemu-devel. > > > > On Tue, Sep 24, 2019 at 01:30:04PM -0700, Jim Mattson wrote: > > > On Wed, Dec 19, 2018 at 1:02 PM Paolo Bonzini wrote: > > > > On 19/12/18 18:39, Jim Mattson wrote: > > > > > Is this an instruction that kvm has to be able to emulate before it > > > > > can enumerate its existence? > > > > > > > > It doesn't have any operands, so no. > > > > > > > > Paolo > > > > > > > > > On Wed, Dec 19, 2018 at 5:51 AM Robert Hoo > > > > > wrote: > > > > > > Signed-off-by: Robert Hoo > > > > > > --- > > > > > > arch/x86/include/asm/cpufeatures.h | 1 + > > > > > > arch/x86/kvm/cpuid.c | 2 +- > > > > > > 2 files changed, 2 insertions(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/arch/x86/include/asm/cpufeatures.h > > > > > > b/arch/x86/include/asm/cpufeatures.h > > > > > > index 28c4a50..932b19f 100644 > > > > > > --- a/arch/x86/include/asm/cpufeatures.h > > > > > > +++ b/arch/x86/include/asm/cpufeatures.h > > > > > > @@ -280,6 +280,7 @@ > > > > > > /* AMD-defined CPU features, CPUID level 0x8008 (EBX), word 13 > > > > > > */ > > > > > > #define X86_FEATURE_CLZERO (13*32+ 0) /* CLZERO > > > > > > instruction */ > > > > > > #define X86_FEATURE_IRPERF (13*32+ 1) /* Instructions > > > > > > Retired Count */ > > > > > > +#define X86_FEATURE_WBNOINVD (13*32+ 9) /* Writeback and > > > > > > Don't invalid cache */ > > > > > > #define X86_FEATURE_XSAVEERPTR (13*32+ 2) /* Always > > > > > > save/restore FP error pointers */ > > > > > > #define X86_FEATURE_AMD_IBPB (13*32+12) /* "" Indirect > > > > > > Branch Prediction Barrier */ > > > > > > #define X86_FEATURE_AMD_IBRS (13*32+14) /* "" Indirect > > > > > > Branch Restricted Speculation */ > > > > > > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c > > > > > > index cc6dd65..763e115 100644 > > > > > > --- a/arch/x86/kvm/cpuid.c > > > > > > +++ b/arch/x86/kvm/cpuid.c > > > > > > @@ -380,7 +380,7 @@ static inline int __do_cpuid_ent(struct > > > > > > kvm_cpuid_entry2 *entry, u32 function, > > > > > > > > > > > > /* cpuid 0x8008.ebx */ > > > > > > const u32 kvm_cpuid_8000_0008_ebx_x86_features = > > > > > > - F(AMD_IBPB) | F(AMD_IBRS) | F(AMD_SSBD) | > > > > > > F(VIRT_SSBD) | > > > > > > + F(WBNOINVD) | F(AMD_IBPB) | F(AMD_IBRS) | > > > > > > F(AMD_SSBD) | F(VIRT_SSBD) | > > > > > > F(AMD_SSB_NO) | F(AMD_STIBP); > > > > > > > > > > > > /* cpuid 0xC001.edx */ > > > > > > -- > > > > > > 1.8.3.1 > > > > > > > > > > > > What is the point of enumerating support for WBNOINVD if kvm is going > > > to implement it as WBINVD? > > > > I expect GET_SUPPORTED_CPUID to return WBNOINVD, because it > > indicates to userspace what is supported by KVM. Are there any > > expectations that GET_SUPPORTED_CPUID will also dictate what is > > enabled by default in some cases? > > > > In either case, your question applies to QEMU: why do we want > > WBNOINVD to be enabled by "-cpu host" by default and be part of > > QEMU's Icelake-* CPU model definitions? > > I had only looked at the SVM implementation of WBNOINVD, which is > exactly the same as the SVM implementation of WBINVD. So, the question > is, "why enumerate WBNOINVD if its implementation is exactly the same > as WBINVD?" > > WBNOINVD appears to be only partially documented in Intel document > 319433-037, "Intel® Architecture Instruction Set Extensions and Future > Features Programming Reference." In particular, there is no > documentation regarding the instruction's behavior in VMX non-root > mode. Does WBNOINVD cause a VM-exit when the VM-execution control, > "WBINVD exiting," is set? If so, does it have the same VM-exit reason > as WBINVD (54), or a different one? If it does have the same VM-exit > reason (a la SVM), how does one distinguish a WBINVD VM-exit from a > WBNOINVD VM-exit? If one can't distinguish (a la SVM), then it would > seem that the VMX implementation also implements WBNOINVD as WBINVD. > If that's the case, the question for VMX is the same as for SVM. Unfortunately WBNOINVD interaction with VMX has not been made to public yet. I am reaching out internally to see when it can be done. I agree it may not be necessary to expose WBNOINVD if its implementation is exactly the same as WBINVD, but it also doesn't have any harm, right? Thanks, -Kai
[Qemu-devel] [Bug 1772165] Re: arm raspi2/raspi3 emulation has no USB support
Hi! I've googled: "usb" "designware" "otg" "datasheet" I think this is the kernel driver for this device: https://github.com/torvalds/linux/tree/master/drivers/usb/dwc3 Maybe it should be possible to use this as a reference? Maybe try to redirect the proprietary drivers system calls? I don't know... I've also found theses docs, which explains the device a little bit: http://www.infradead.org/~mchehab/kernel_docs_pdf/driver-api.pdf https://media.digikey.com/pdf/Data%20Sheets/Austriamicrosystems%20PDFs/AS3524.pdf https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/arria-10/a10_54018.pdf Thanks. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1772165 Title: arm raspi2/raspi3 emulation has no USB support Status in QEMU: Confirmed Bug description: Using Qemu 2.12.0 on ArchLinux. Trying to emulate arm device with `qemu-system-arm` and attach usb device for unput using ` -usb -device usb-host,bus=001,vendorid=0x1d6b,productid=0x0002 ` # lsusb returns Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 014: ID 13d3:3487 IMC Networks Bus 001 Device 004: ID 0457:11af Silicon Integrated Systems Corp. Bus 001 Device 003: ID 0bda:57e6 Realtek Semiconductor Corp. Bus 001 Device 002: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub # qemu returns qemu-system-arm: -device usb-host,bus=001,vendorid=0x1d6b,productid=0x0002: Bus '001' not found Tried with connecting external usb keyboard but that didn't seem to work either. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1772165/+subscriptions
[Qemu-devel] [Bug 1834399] [NEW] AArch64: branch out of range
Public bug reported:
I build lib32-qemu which is a multilib variant for mips o32 on project
Yocto with qemumips64. It finally runs command and fails:
mips-wrsmllib32-linux-gcc -meb -mabi=32 -mhard-float -fstack-protector-strong
-Wformat -Wformat-security -Werror=format-security
--sysroot=/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/lib32-recipe-sysroot
-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/lib32-recipe-sysroot/usr/include/pixman-1
-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/qemu-4.0.0/dtc/libfdt
-pthread
-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/lib32-recipe-sysroot/usr/include/glib-2.0
-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/lib32-recipe-sysroot/usr/lib/glib-2.0/include
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Og -g
-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/qemu-4.0.0/capstone/include
-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/qemu-4.0.0/tests
-DCAPSTONE_USE_SYS_DYN_MEM -DCAPSTONE_HAS_ARM -DCAPSTONE_HAS_ARM64
-DCAPSTONE_HAS_POWERPC -DCAPSTONE_HAS_X86
-c arch/AArch64/AArch64InstPrinter.c -o
/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/build/capstone/obj/arch/AArch64/AArch64InstPrinter.o
And error messages:
{standard input}: Assembler messages:
{standard input}:38045: Error: branch out of range
{standard input}:38269: Error: branch out of range
{standard input}:38493: Error: branch out of range
{standard input}:38717: Error: branch out of range
{standard input}:38941: Error: branch out of range
{standard input}:39165: Error: branch out of range
{standard input}:39389: Error: branch out of range
{standard input}:39613: Error: branch out of range
{standard input}:39728: Error: branch out of range
{standard input}:39990: Error: branch out of range
{standard input}:40252: Error: branch out of range
{standard input}:40514: Error: branch out of range
{standard input}:40776: Error: branch out of range
{standard input}:41038: Error: branch out of range
The gcc version is 9.1. I have verified that gcc 8.3 works. And there is no
error when remove option '-Og' with gcc 9.1.
I am not sure whether it is a defect of gcc 9.1 or capstone. Should it
be fixed in capstone? Thanks.
** Affects: capstone
Importance: Undecided
Status: New
** Project changed: qemu => capstone
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1834399
Title:
AArch64: branch out of range
Status in Capstone:
New
Bug description:
I build lib32-qemu which is a multilib variant for mips o32 on project
Yocto with qemumips64. It finally runs command and fails:
mips-wrsmllib32-linux-gcc -meb -mabi=32 -mhard-float
-fstack-protector-strong -Wformat -Wformat-security -Werror=format-security
--sysroot=/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/lib32-recipe-sysroot
-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/lib32-recipe-sysroot/usr/include/pixman-1
-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/qemu-4.0.0/dtc/libfdt
-pthread
-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/lib32-recipe-sysroot/usr/include/glib-2.0
-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/lib32-recipe-sysroot/usr/lib/glib-2.0/include
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Og -g
-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/qemu-4.0.0/capstone/include
-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/qemu-4.0.0/tests
-DCAPSTONE_USE_SYS_DYN_MEM -DCAPSTONE_HAS_ARM -DCAPSTONE_HAS_ARM64
-DCAPSTONE_HAS_POWERPC -DCAPSTONE_HAS_X86
-c arch/AArch64/AArch64InstPrinter.c -o
/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/build/capstone/obj/arch/AArch64/AArch64InstPrinter.o
And error messages:
{standard input}: Assembler messages:
{standard input}:38045: Error: branch out of range
{standard input}:38269: Error: branch out of range
{standard input}:38493: Error: branch out of range
{standard input}:38717: Error: branch out of range
{standard input}:38941: Error: branch out of range
{standard input}:39165: Error: branch out of range
{standard input}:39389: Error: branch out of range
{standard input}:39613: Error: branch out of range
{standard input}:39728: Error: branch out
Re: [Qemu-devel] kvm bug in __rmap_clear_dirty during live migration
Thanks! Thanks, -Kai On 3/14/2017 5:57 AM, Paolo Bonzini wrote: On 13/03/2017 15:58, fangying wrote: Hi, Huang Kai After weeks of intensive testing, we think the problem is solved and this issue can be closed. Thanks for the update. We got to the same conclusion. Paolo
Re: [Qemu-devel] kvm bug in __rmap_clear_dirty during live migration
On 2/25/2017 2:44 PM, Herongguang (Stephen) wrote: On 2017/2/24 23:14, Paolo Bonzini wrote: On 24/02/2017 16:10, Chris Friesen wrote: On 02/23/2017 08:23 PM, Herongguang (Stephen) wrote: On 2017/2/22 22:43, Paolo Bonzini wrote: Hopefully Gaohuai and Rongguang can help with this too. Paolo Yes, we are looking into and testing this. I think this can result in any memory corruption, if VM1 writes its PML buffer into VM2’s VMCS (since sched_in/sched_out notifier of VM1 is not registered yet), then VM1 is destroyed (hence its PML buffer is freed back to kernel), after that, VM2 starts migration, so CPU logs VM2’s dirty GFNS into a freed memory, results in any memory corruption. As its severity, this commit (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4e59516a12a6ef6dcb660cb3a3f70c64bd60cfec) is eligible to back port to kernel stable. Are we expecting that fix to resolve the original issue, or is it a separate issue that needs fixing in stable? It should be the original issue. Paolo . Yes, I agree, though we are still testing. Hi Stephen, Sorry for late reply. I was taking the whole week off last week. How's the test going? Thanks, -Kai
[Qemu-devel] [Bug 1658634] Re: Can't get correct display with latest QEMU and OVMF BIOS
It works well on my side with the patch. Thanks! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1658634 Title: Can't get correct display with latest QEMU and OVMF BIOS Status in QEMU: Confirmed Bug description: I tried to install a Ubuntu 16.04.1 Desktop 64bits with latest QEMU and OVMF UEFI BIOS, however I can't get correct display output with default vga configuration (-vga std). However, qemu works with a couple of different configurations: 1. "-vga cirrus" + "-bios OVMF.fd": works 2. "-vga std" + non-UEFI bios: works The same error with QEMU 2.8.0 release. Everything works well on 2.7.0/1. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1658634/+subscriptions
Re: [Qemu-devel] [Bug 1658634] Re: Can't get correct display with latest QEMU and OVMF BIOS
Splash screen and UEFI shell were displayed correctly. Grub2 menu and Ubuntu login screen also appeared, however the display didn't seem right. I got very blurry output. [image: Inline image 1] With QEMU 2.7.0 and the same OVMF.fd, everything works well. Please let me know if anything is not clear. Thanks, Kai On Mon, Jan 23, 2017 at 4:50 AM, Laszlo Ersek (Red Hat) <ler...@redhat.com> wrote: > (1) What phase of the guest do you get invalid video output in? Do you > see the TianoCore splash screen? Does the grub2 menu appear? > > (2) I cannot reproduce the issue (with a different guest OS anyway); I > just tried QEMU (at d1c82f7cc344) and OVMF (built from edk2 at > 7cf59c854f35), with stdvga; this combo works fine. > > (3) Can you bisect QEMU from 2.7 through 2.8, using the same OVMF > binary? > > (4) Side point: please *never* use "-bios OVMF.fd"; use two pflash chips > instead. Libvirt (strongly recommended) will do this for you. > > Thanks. > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1658634 > > Title: > Can't get correct display with latest QEMU and OVMF BIOS > > Status in QEMU: > New > > Bug description: > I tried to install a Ubuntu 16.04.1 Desktop 64bits with latest QEMU and > OVMF UEFI BIOS, however I can't get correct display output with default vga > configuration (-vga std). However, qemu works with a couple of different > configurations: > 1. "-vga cirrus" + "-bios OVMF.fd": works > 2. "-vga std" + non-UEFI bios: works > > The same error with QEMU 2.8.0 release. Everything works well on > 2.7.0/1. > > To manage notifications about this bug go to: > https://bugs.launchpad.net/qemu/+bug/1658634/+subscriptions > ** Attachment added: "image.png" https://bugs.launchpad.net/bugs/1658634/+attachment/4808338/+files/image.png -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1658634 Title: Can't get correct display with latest QEMU and OVMF BIOS Status in QEMU: New Bug description: I tried to install a Ubuntu 16.04.1 Desktop 64bits with latest QEMU and OVMF UEFI BIOS, however I can't get correct display output with default vga configuration (-vga std). However, qemu works with a couple of different configurations: 1. "-vga cirrus" + "-bios OVMF.fd": works 2. "-vga std" + non-UEFI bios: works The same error with QEMU 2.8.0 release. Everything works well on 2.7.0/1. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1658634/+subscriptions
[Qemu-devel] [Bug 1658634] [NEW] Can't get correct display with latest QEMU and OVMF BIOS
Public bug reported: I tried to install a Ubuntu 16.04.1 Desktop 64bits with latest QEMU and OVMF UEFI BIOS, however I can't get correct display output with default vga configuration (-vga std). However, qemu works with a couple of different configurations: 1. "-vga cirrus" + "-bios OVMF.fd": works 2. "-vga std" + non-UEFI bios: works The same error with QEMU 2.8.0 release. Everything works well on 2.7.0/1. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1658634 Title: Can't get correct display with latest QEMU and OVMF BIOS Status in QEMU: New Bug description: I tried to install a Ubuntu 16.04.1 Desktop 64bits with latest QEMU and OVMF UEFI BIOS, however I can't get correct display output with default vga configuration (-vga std). However, qemu works with a couple of different configurations: 1. "-vga cirrus" + "-bios OVMF.fd": works 2. "-vga std" + non-UEFI bios: works The same error with QEMU 2.8.0 release. Everything works well on 2.7.0/1. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1658634/+subscriptions
[Qemu-devel] [Bug 1614609] [NEW] alphabetical order of monitor options
Public bug reported: Looking for the 'continue'/'resume' option I found this order that was not quite 'alphabetical'. It had me overlook the 'cont' option at glance. Which is just a little impractical. ... boot_set bootdevice -- define new values for the boot device list change device filename [format [read-only-mode]] -- change a removable medium, optional format chardev-add args -- add chardev chardev-remove id -- remove chardev client_migrate_info protocol hostname port tls-port cert-subject -- set migration information for remote display closefd closefd name -- close a file descriptor previously passed via SCM rights commit device|all -- commit changes to the disk images (if -snapshot is used) or backing files cpu index -- set the default CPU cpu-add id -- add cpu c|cont -- resume emulation delvm tag|id -- delete a VM snapshot from its tag or id ... I tested this list with 'sort' just to make sure and make a point: $ cat Desktop/order-orig.txt boot_set change chardev-add chardev-remove client_migrate_info closefd commit cpu cpu-add c|cont delvm $ cat Desktop/order-orig.txt | sort boot_set c|cont change chardev-add chardev-remove client_migrate_info closefd commit cpu cpu-add delvm $ ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1614609 Title: alphabetical order of monitor options Status in QEMU: New Bug description: Looking for the 'continue'/'resume' option I found this order that was not quite 'alphabetical'. It had me overlook the 'cont' option at glance. Which is just a little impractical. ... boot_set bootdevice -- define new values for the boot device list change device filename [format [read-only-mode]] -- change a removable medium, optional format chardev-add args -- add chardev chardev-remove id -- remove chardev client_migrate_info protocol hostname port tls-port cert-subject -- set migration information for remote display closefd closefd name -- close a file descriptor previously passed via SCM rights commit device|all -- commit changes to the disk images (if -snapshot is used) or backing files cpu index -- set the default CPU cpu-add id -- add cpu c|cont -- resume emulation delvm tag|id -- delete a VM snapshot from its tag or id ... I tested this list with 'sort' just to make sure and make a point: $ cat Desktop/order-orig.txt boot_set change chardev-add chardev-remove client_migrate_info closefd commit cpu cpu-add c|cont delvm $ cat Desktop/order-orig.txt | sort boot_set c|cont change chardev-add chardev-remove client_migrate_info closefd commit cpu cpu-add delvm $ To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1614609/+subscriptions
[Qemu-devel] [Bug 1614521] [NEW] -display accepts "none[a-z, 0-9]*" instead of 'none'
Public bug reported: When using the '-display' option the parameter 'none' is not the only string that causes the behaviour of 'none'. I can use '-display noneMICKEYMOUSE' and still have the none behaviour. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1614521 Title: -display accepts "none[a-z,0-9]*" instead of 'none' Status in QEMU: New Bug description: When using the '-display' option the parameter 'none' is not the only string that causes the behaviour of 'none'. I can use '-display noneMICKEYMOUSE' and still have the none behaviour. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1614521/+subscriptions
[Qemu-devel] [Bug 1297218] Re: guest hangs after live migration due to tsc jump
Hello Chris, Steps taken to test the proposed package: 1) enabled trusty-proposed 2) installed qemu-system-arm qemu-system-common qemu-system-misc qemu-system-x86 qemu-user version 2.0.0+dfsg-2ubuntu1.25 3) again on a second trusty14.04 server 4) migrate 41 running VM's (uptimes vary between 1 and 142 days) between 2 upgraded hosts, several times. Result: I haven't observed any problems after 168 live migrations. Hypervisor OS: ubuntu 14.04 (trusty): ceph: 0.94.7-1trusty qemu: 2.0.0+dfsg-2ubuntu1.25 linux: 3.13.0.92.99 libvirt: 1.2.2-0ubuntu13.1.17 VMs are a mix of debian-jessie and debian-wheezy. ** Tags added: verification-done -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1297218 Title: guest hangs after live migration due to tsc jump Status in QEMU: New Status in glusterfs package in Ubuntu: Invalid Status in qemu package in Ubuntu: Fix Released Status in glusterfs source package in Trusty: Confirmed Status in qemu source package in Trusty: Fix Committed Bug description: = SRU Justification: 1. Impact: guests hang after live migration with 100% cpu 2. Upstream fix: a set of four patches fix this upstream 3. Stable fix: we have a backport of the four patches into a single patch. 4. Test case: try a set of migrations of different VMS (it is unfortunately not 100% reproducible) 5. Regression potential: the patch is not trivial, however the lp:qa-regression-tests testsuite passed 100% with this package. = We have two identical Ubuntu servers running libvirt/kvm/qemu, sharing a Gluster filesystem. Guests can be live migrated between them. However, live migration often leads to the guest being stuck at 100% for a while. In that case, the dmesg output for such a guest will show (once it recovers): Clocksource tsc unstable (delta = 662463064082 ns). In this particular example, a guest was migrated and only after 11 minutes (662 seconds) did it become responsive again. It seems that newly booted guests doe not suffer from this problem, these can be migrated back and forth at will. After a day or so, the problem becomes apparent. It also seems that migrating from server A to server B causes much more problems than going from B back to A. If necessary, I can do more measurements to qualify these observations. The VM servers run Ubuntu 13.04 with these packages: Kernel: 3.8.0-35-generic x86_64 Libvirt: 1.0.2 Qemu: 1.4.0 Gluster-fs: 3.4.2 (libvirt access the images via the filesystem, not using libgfapi yet as the Ubuntu libvirt is not linked against libgfapi). The interconnect between both machines (both for migration and gluster) is 10GbE. Both servers are synced to NTP and well within 1ms form one another. Guests are either Ubuntu 13.04 or 13.10. On the guests, the current_clocksource is kvm-clock. The XML definition of the guests only contains: Now as far as I've read in the documentation of kvm-clock, it specifically supports live migrations, so I'm a bit surprised at these problems. There isn't all that much information to find on these issue, although I have found postings by others that seem to have run into the same issues, but without a solution. --- ApportVersion: 2.14.1-0ubuntu3 Architecture: amd64 DistroRelease: Ubuntu 14.04 Package: libvirt (not installed) ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-3.13.0-24-generic root=UUID=1b0c3c6d-a9b8-4e84-b076-117ae267d178 ro console=ttyS1,115200n8 BOOTIF=01-00-25-90-75-b5-c8 ProcVersionSignature: Ubuntu 3.13.0-24.47-generic 3.13.9 Tags: trusty apparmor apparmor apparmor apparmor apparmor Uname: Linux 3.13.0-24-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True modified.conffile..etc.default.libvirt.bin: [modified] modified.conffile..etc.libvirt.libvirtd.conf: [modified] modified.conffile..etc.libvirt.qemu.conf: [modified] modified.conffile..etc.libvirt.qemu.networks.default.xml: [deleted] mtime.conffile..etc.default.libvirt.bin: 2014-05-12T19:07:40.020662 mtime.conffile..etc.libvirt.libvirtd.conf: 2014-05-13T14:40:25.894837 mtime.conffile..etc.libvirt.qemu.conf: 2014-05-12T18:58:27.885506 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1297218/+subscriptions
[Qemu-devel] [Bug 1297218] Re: guest hangs after live migration due to tsc jump
We have four identical Ubuntu servers running libvirt/kvm/qemu, with access to CEPH rbd filesystems. Guests can be live migrated between them. However, live migration leads in ~30% of the cases to guests being stuck at 100%. Only a few times we had the patience to wait, and upon logging in our passwords were said to be expired; thus we couldn't log in. This happened mostly to long running VM's, but not all of them; this makes debugging hard. These servers run ubuntu 14.04 (trusty): ceph:0.94.7-1trusty qemu:2.0.0+dfsg-2ubuntu1.22 linux: 3.13.0.88.94 libvirt: 1.2.2-0ubuntu13.1.16 Is this what you request? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1297218 Title: guest hangs after live migration due to tsc jump Status in QEMU: New Status in glusterfs package in Ubuntu: Invalid Status in qemu package in Ubuntu: Fix Released Status in glusterfs source package in Trusty: Confirmed Status in qemu source package in Trusty: Confirmed Bug description: We have two identical Ubuntu servers running libvirt/kvm/qemu, sharing a Gluster filesystem. Guests can be live migrated between them. However, live migration often leads to the guest being stuck at 100% for a while. In that case, the dmesg output for such a guest will show (once it recovers): Clocksource tsc unstable (delta = 662463064082 ns). In this particular example, a guest was migrated and only after 11 minutes (662 seconds) did it become responsive again. It seems that newly booted guests doe not suffer from this problem, these can be migrated back and forth at will. After a day or so, the problem becomes apparent. It also seems that migrating from server A to server B causes much more problems than going from B back to A. If necessary, I can do more measurements to qualify these observations. The VM servers run Ubuntu 13.04 with these packages: Kernel: 3.8.0-35-generic x86_64 Libvirt: 1.0.2 Qemu: 1.4.0 Gluster-fs: 3.4.2 (libvirt access the images via the filesystem, not using libgfapi yet as the Ubuntu libvirt is not linked against libgfapi). The interconnect between both machines (both for migration and gluster) is 10GbE. Both servers are synced to NTP and well within 1ms form one another. Guests are either Ubuntu 13.04 or 13.10. On the guests, the current_clocksource is kvm-clock. The XML definition of the guests only contains: Now as far as I've read in the documentation of kvm-clock, it specifically supports live migrations, so I'm a bit surprised at these problems. There isn't all that much information to find on these issue, although I have found postings by others that seem to have run into the same issues, but without a solution. --- ApportVersion: 2.14.1-0ubuntu3 Architecture: amd64 DistroRelease: Ubuntu 14.04 Package: libvirt (not installed) ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-3.13.0-24-generic root=UUID=1b0c3c6d-a9b8-4e84-b076-117ae267d178 ro console=ttyS1,115200n8 BOOTIF=01-00-25-90-75-b5-c8 ProcVersionSignature: Ubuntu 3.13.0-24.47-generic 3.13.9 Tags: trusty apparmor apparmor apparmor apparmor apparmor Uname: Linux 3.13.0-24-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True modified.conffile..etc.default.libvirt.bin: [modified] modified.conffile..etc.libvirt.libvirtd.conf: [modified] modified.conffile..etc.libvirt.qemu.conf: [modified] modified.conffile..etc.libvirt.qemu.networks.default.xml: [deleted] mtime.conffile..etc.default.libvirt.bin: 2014-05-12T19:07:40.020662 mtime.conffile..etc.libvirt.libvirtd.conf: 2014-05-13T14:40:25.894837 mtime.conffile..etc.libvirt.qemu.conf: 2014-05-12T18:58:27.885506 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1297218/+subscriptions
[Qemu-devel] [Bug 1297218] Re: guest hangs after live migration due to tsc jump
I can reasonably assume that this solved my problem. I've live migrated 41 VM's 5 times between 2 hypervisors without the 100% cpu problem appearing. My production servers run 2.0.0+dfsg-2ubuntu1.22, and still observe the same problem. Attached is the patch that I created with quilt in debian/patches; This one mirrors the 4 patches that are listed in the debian bugreport[1]. The patch should apply cleanly with qemu 2.0.0+dfsg-2ubuntu1.24 (from trusty-security). Let's hope others can benefit from an ubuntu update :) [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786789 ** Patch added: "backport-fixtime.patch" https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1297218/+attachment/469/+files/backport-fixtime.patch -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1297218 Title: guest hangs after live migration due to tsc jump Status in QEMU: New Status in glusterfs package in Ubuntu: Invalid Status in qemu package in Ubuntu: Fix Released Status in glusterfs source package in Trusty: Confirmed Status in qemu source package in Trusty: Confirmed Bug description: We have two identical Ubuntu servers running libvirt/kvm/qemu, sharing a Gluster filesystem. Guests can be live migrated between them. However, live migration often leads to the guest being stuck at 100% for a while. In that case, the dmesg output for such a guest will show (once it recovers): Clocksource tsc unstable (delta = 662463064082 ns). In this particular example, a guest was migrated and only after 11 minutes (662 seconds) did it become responsive again. It seems that newly booted guests doe not suffer from this problem, these can be migrated back and forth at will. After a day or so, the problem becomes apparent. It also seems that migrating from server A to server B causes much more problems than going from B back to A. If necessary, I can do more measurements to qualify these observations. The VM servers run Ubuntu 13.04 with these packages: Kernel: 3.8.0-35-generic x86_64 Libvirt: 1.0.2 Qemu: 1.4.0 Gluster-fs: 3.4.2 (libvirt access the images via the filesystem, not using libgfapi yet as the Ubuntu libvirt is not linked against libgfapi). The interconnect between both machines (both for migration and gluster) is 10GbE. Both servers are synced to NTP and well within 1ms form one another. Guests are either Ubuntu 13.04 or 13.10. On the guests, the current_clocksource is kvm-clock. The XML definition of the guests only contains: Now as far as I've read in the documentation of kvm-clock, it specifically supports live migrations, so I'm a bit surprised at these problems. There isn't all that much information to find on these issue, although I have found postings by others that seem to have run into the same issues, but without a solution. --- ApportVersion: 2.14.1-0ubuntu3 Architecture: amd64 DistroRelease: Ubuntu 14.04 Package: libvirt (not installed) ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-3.13.0-24-generic root=UUID=1b0c3c6d-a9b8-4e84-b076-117ae267d178 ro console=ttyS1,115200n8 BOOTIF=01-00-25-90-75-b5-c8 ProcVersionSignature: Ubuntu 3.13.0-24.47-generic 3.13.9 Tags: trusty apparmor apparmor apparmor apparmor apparmor Uname: Linux 3.13.0-24-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True modified.conffile..etc.default.libvirt.bin: [modified] modified.conffile..etc.libvirt.libvirtd.conf: [modified] modified.conffile..etc.libvirt.qemu.conf: [modified] modified.conffile..etc.libvirt.qemu.networks.default.xml: [deleted] mtime.conffile..etc.default.libvirt.bin: 2014-05-12T19:07:40.020662 mtime.conffile..etc.libvirt.libvirtd.conf: 2014-05-13T14:40:25.894837 mtime.conffile..etc.libvirt.qemu.conf: 2014-05-12T18:58:27.885506 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1297218/+subscriptions
[Qemu-devel] [Bug 1297218] Re: guest hangs after live migration due to tsc jump
That patch does not apply cleanly on qemu (2.0.0+dfsg, from trusty). There are changes in "kvmclock_pre_save" and "kvmclock_post_save", there's only "kvmclock_vm_state_change" in 2.0.0. Peeking at the 4 referenced patches on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786789 the code changes are "about the same", so I'll concatenate those 4 and build that. Thanks, -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1297218 Title: guest hangs after live migration due to tsc jump Status in QEMU: New Status in glusterfs package in Ubuntu: Invalid Status in qemu package in Ubuntu: Fix Released Status in glusterfs source package in Trusty: Confirmed Status in qemu source package in Trusty: Confirmed Bug description: We have two identical Ubuntu servers running libvirt/kvm/qemu, sharing a Gluster filesystem. Guests can be live migrated between them. However, live migration often leads to the guest being stuck at 100% for a while. In that case, the dmesg output for such a guest will show (once it recovers): Clocksource tsc unstable (delta = 662463064082 ns). In this particular example, a guest was migrated and only after 11 minutes (662 seconds) did it become responsive again. It seems that newly booted guests doe not suffer from this problem, these can be migrated back and forth at will. After a day or so, the problem becomes apparent. It also seems that migrating from server A to server B causes much more problems than going from B back to A. If necessary, I can do more measurements to qualify these observations. The VM servers run Ubuntu 13.04 with these packages: Kernel: 3.8.0-35-generic x86_64 Libvirt: 1.0.2 Qemu: 1.4.0 Gluster-fs: 3.4.2 (libvirt access the images via the filesystem, not using libgfapi yet as the Ubuntu libvirt is not linked against libgfapi). The interconnect between both machines (both for migration and gluster) is 10GbE. Both servers are synced to NTP and well within 1ms form one another. Guests are either Ubuntu 13.04 or 13.10. On the guests, the current_clocksource is kvm-clock. The XML definition of the guests only contains: Now as far as I've read in the documentation of kvm-clock, it specifically supports live migrations, so I'm a bit surprised at these problems. There isn't all that much information to find on these issue, although I have found postings by others that seem to have run into the same issues, but without a solution. --- ApportVersion: 2.14.1-0ubuntu3 Architecture: amd64 DistroRelease: Ubuntu 14.04 Package: libvirt (not installed) ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-3.13.0-24-generic root=UUID=1b0c3c6d-a9b8-4e84-b076-117ae267d178 ro console=ttyS1,115200n8 BOOTIF=01-00-25-90-75-b5-c8 ProcVersionSignature: Ubuntu 3.13.0-24.47-generic 3.13.9 Tags: trusty apparmor apparmor apparmor apparmor apparmor Uname: Linux 3.13.0-24-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True modified.conffile..etc.default.libvirt.bin: [modified] modified.conffile..etc.libvirt.libvirtd.conf: [modified] modified.conffile..etc.libvirt.qemu.conf: [modified] modified.conffile..etc.libvirt.qemu.networks.default.xml: [deleted] mtime.conffile..etc.default.libvirt.bin: 2014-05-12T19:07:40.020662 mtime.conffile..etc.libvirt.libvirtd.conf: 2014-05-13T14:40:25.894837 mtime.conffile..etc.libvirt.qemu.conf: 2014-05-12T18:58:27.885506 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1297218/+subscriptions
[Qemu-devel] [Bug 1297218] Re: guest hangs after live migration due to tsc jump
@serge, I'd be happy to test each of the patches, but considering the length of this page I'd like an exact link to a patch and/or patches that need to be tested, and against which version (trusty-security i suppose?). -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1297218 Title: guest hangs after live migration due to tsc jump Status in QEMU: New Status in glusterfs package in Ubuntu: Invalid Status in qemu package in Ubuntu: Fix Released Status in glusterfs source package in Trusty: Confirmed Status in qemu source package in Trusty: Confirmed Bug description: We have two identical Ubuntu servers running libvirt/kvm/qemu, sharing a Gluster filesystem. Guests can be live migrated between them. However, live migration often leads to the guest being stuck at 100% for a while. In that case, the dmesg output for such a guest will show (once it recovers): Clocksource tsc unstable (delta = 662463064082 ns). In this particular example, a guest was migrated and only after 11 minutes (662 seconds) did it become responsive again. It seems that newly booted guests doe not suffer from this problem, these can be migrated back and forth at will. After a day or so, the problem becomes apparent. It also seems that migrating from server A to server B causes much more problems than going from B back to A. If necessary, I can do more measurements to qualify these observations. The VM servers run Ubuntu 13.04 with these packages: Kernel: 3.8.0-35-generic x86_64 Libvirt: 1.0.2 Qemu: 1.4.0 Gluster-fs: 3.4.2 (libvirt access the images via the filesystem, not using libgfapi yet as the Ubuntu libvirt is not linked against libgfapi). The interconnect between both machines (both for migration and gluster) is 10GbE. Both servers are synced to NTP and well within 1ms form one another. Guests are either Ubuntu 13.04 or 13.10. On the guests, the current_clocksource is kvm-clock. The XML definition of the guests only contains: Now as far as I've read in the documentation of kvm-clock, it specifically supports live migrations, so I'm a bit surprised at these problems. There isn't all that much information to find on these issue, although I have found postings by others that seem to have run into the same issues, but without a solution. --- ApportVersion: 2.14.1-0ubuntu3 Architecture: amd64 DistroRelease: Ubuntu 14.04 Package: libvirt (not installed) ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-3.13.0-24-generic root=UUID=1b0c3c6d-a9b8-4e84-b076-117ae267d178 ro console=ttyS1,115200n8 BOOTIF=01-00-25-90-75-b5-c8 ProcVersionSignature: Ubuntu 3.13.0-24.47-generic 3.13.9 Tags: trusty apparmor apparmor apparmor apparmor apparmor Uname: Linux 3.13.0-24-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True modified.conffile..etc.default.libvirt.bin: [modified] modified.conffile..etc.libvirt.libvirtd.conf: [modified] modified.conffile..etc.libvirt.qemu.conf: [modified] modified.conffile..etc.libvirt.qemu.networks.default.xml: [deleted] mtime.conffile..etc.default.libvirt.bin: 2014-05-12T19:07:40.020662 mtime.conffile..etc.libvirt.libvirtd.conf: 2014-05-13T14:40:25.894837 mtime.conffile..etc.libvirt.qemu.conf: 2014-05-12T18:58:27.885506 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1297218/+subscriptions
Re: [Qemu-devel] [PATCH v3 1/3] IOMMU: add VTD_CAP_CM to vIOMMU capability exposed to guest
On 6/8/2016 6:46 AM, Alex Williamson wrote:
On Tue, 7 Jun 2016 17:21:06 +1200
"Huang, Kai" <kai.hu...@linux.intel.com> wrote:
On 6/7/2016 3:58 PM, Alex Williamson wrote:
On Tue, 7 Jun 2016 11:20:32 +0800
Peter Xu <pet...@redhat.com> wrote:
On Mon, Jun 06, 2016 at 11:02:11AM -0600, Alex Williamson wrote:
On Mon, 6 Jun 2016 21:43:17 +0800
Peter Xu <pet...@redhat.com> wrote:
On Mon, Jun 06, 2016 at 07:11:41AM -0600, Alex Williamson wrote:
On Mon, 6 Jun 2016 13:04:07 +0800
Peter Xu <pet...@redhat.com> wrote:
[...]
Besides the reason that there might have guests that do not support
CM=1, will there be performance considerations? When user's
configuration does not require CM capability (e.g., generic VM
configuration, without VFIO), shall we allow user to disable the CM
bit so that we can have better IOMMU performance (avoid extra and
useless invalidations)?
With Alexey's proposed patch to have callback ops when the iommu
notifier list adds its first entry and removes its last, any of the
additional overhead to generate notifies when nobody is listening can
be avoided. These same callbacks would be the ones that need to
generate a hw_error if a notifier is added while running in CM=0.
Not familar with Alexey's patch
https://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg00079.html
Thanks for the pointer. :)
, but is that for VFIO only?
vfio is currently the only user of the iommu notifier, but the
interface is generic, which is how it should (must) be.
Yes.
I mean, if
we configured CMbit=1, guest kernel will send invalidation request
every time it creates new entries (context entries, or iotlb
entries). Even without VFIO notifiers, guest need to trap into QEMU
and process the invalidation requests. This is avoidable if we are not
using VFIO devices at all (so no need to maintain any mappings),
right?
CM=1 only defines that not-present and invalid entries can be cached,
any changes to existing entries requires an invalidation regardless of
CM. What you're looking for sounds more like ECAP.C:
Yes, but I guess what I was talking about is CM bit but not ECAP.C.
When we clear/replace one context entry, guest kernel will definitely
send one context entry invalidation to QEMU:
static void domain_context_clear_one(struct intel_iommu *iommu, u8 bus, u8
devfn)
{
if (!iommu)
return;
clear_context_table(iommu, bus, devfn);
iommu->flush.flush_context(iommu, 0, 0, 0,
DMA_CCMD_GLOBAL_INVL);
iommu->flush.flush_iotlb(iommu, 0, 0, 0, DMA_TLB_GLOBAL_FLUSH);
}
... While if we are creating a new one (like attaching a new VFIO
device?), it's an optional behavior depending on whether CM bit is
set:
static int domain_context_mapping_one(struct dmar_domain *domain,
struct intel_iommu *iommu,
u8 bus, u8 devfn)
{
...
/*
* It's a non-present to present mapping. If hardware doesn't cache
* non-present entry we only need to flush the write-buffer. If the
* _does_ cache non-present entries, then it does so in the special
* domain #0, which we have to flush:
*/
if (cap_caching_mode(iommu->cap)) {
iommu->flush.flush_context(iommu, 0,
(((u16)bus) << 8) | devfn,
DMA_CCMD_MASK_NOBIT,
DMA_CCMD_DEVICE_INVL);
iommu->flush.flush_iotlb(iommu, did, 0, 0, DMA_TLB_DSI_FLUSH);
} else {
iommu_flush_write_buffer(iommu);
}
...
}
Only if cap_caching_mode() is set (which is bit 7, the CM bit), we
will send these invalidations. What I meant is that, we should allow
user to specify the CM bit, so that when we are not using VFIO
devices, we can skip the above flush_content() and flush_iotlb()
etc... So, besides the truth that we have some guests do not support
CM bit (like Jailhouse), performance might be another consideration
point that we should allow user to specify the CM bit themselfs.
I'm dubious of this, IOMMU drivers are already aware that hardware
flushes are expensive and do batching to optimize it. The queued
invalidation mechanism itself is meant to allow asynchronous
invalidations. QEMU invalidating a virtual IOMMU might very well be
faster than hardware.
Do batching doesn't mean we can eliminate the IOTLB flush for mappings
from non-present to present, in case of CM=1, while in case CM=0 those
IOTLB flush are not necessary, just like the code above shows. Therefore
generally speaking CM=0 should have better performance than CM=1, even
for Qemu's vIOMMU.
In my understanding the purpose of exposing CM=1 is to force guest do
IOTLB flush for each mapping change (including from non-present to
present) so Qemu is able to
Re: [Qemu-devel] [PATCH v3 1/3] IOMMU: add VTD_CAP_CM to vIOMMU capability exposed to guest
g vfio assigned devices and vIOMMU work together, and unfortunately this cannot work on other vendor's IOMMU without CM bit, such as AMD's IOMMU. So what's the requirements of making vfio assigned devices and vIOMMU work together? I think it should be more helpful to implement a more generic solution to monitor and emulate guest vIOMMU's page table, rather than simply exposing CM=1 to guest, as it only works on intel IOMMU. And what do you mean asynchronous invalidations? I think the iova of the changed mappings cannot be used until the mappings are invalidated. It doesn't matter whether the invalidation is done via QI or register. Thanks, -Kai C: Page-walk Coherency This field indicates if hardware access to the root, context, extended-context and interrupt-remap tables, and second-level paging structures for requests-without PASID, are coherent (snooped) or not. • 0: Indicates hardware accesses to remapping structures are non-coherent. • 1: Indicates hardware accesses to remapping structures are coherent. Without both CM=0 and C=0, our only virtualization mechanism for maintaining a hardware cache coherent with the guest view of the iommu would be to shadow all of the VT-d structures. For purely emulated devices, maybe we can get away with that, but I doubt the current ghashes used for the iotlb are prepared for it. Actually I haven't noticed this bit yet. I see that this will decide whether guest kernel need to send specific clflush() when modifying IOMMU PTEs, but shouldn't we flush the memory cache always so that we can sure IOMMU can see the same memory data as CPU does? I think it would be a question of how much the g_hash code really buys us in the VT-d code, it might be faster to do a lookup each time if it means fewer flushes. Those hashes are useless overhead for assigned devices, so maybe we can avoid them when we only have assigned devices ;) Thanks, Alex
Re: [Qemu-devel] [PATCH] target-i386: add Skylake-Client cpu mode
Hi Guangrong,
How about also add SGX to Skylake?
Thanks,
-Kai
On 4/27/2016 8:13 PM, Xiao Guangrong wrote:
From: Eduardo Habkost <ehabk...@redhat.com>
Introduce Skylake-Client cpu mode which inherits the features from
Broadwell and supports some additional features that are: MPX,
XSAVEC, XSAVES and XGETBV1
Note:
1. As XSAVES is disabled in upstream linux kernel by commit e88221c50
(x86/fpu: Disable XSAVES* support for now), QEMU will complain about
"warning: host doesn't support requested feature: CPUID.0DH:EAX.xsaves [bit 3]"
2. We will post out the patch introducing Skylake-Server mode once it
has been verified on a Skylake Sever machine
[ Xiao: largely based on Eduardo's work, introduce Skylake-Client and
Skylake-Server cpu modes separately. ]
Signed-off-by: Eduardo Habkost <ehabk...@redhat.com>
Signed-off-by: Xiao Guangrong <guangrong.x...@linux.intel.com>
---
target-i386/cpu.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index ddae932..2f2c647 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1228,6 +1228,45 @@ static X86CPUDefinition builtin_x86_defs[] = {
.model_id = "Intel Core Processor (Broadwell)",
},
{
+.name = "Skylake-Client",
+.level = 0xd,
+.vendor = CPUID_VENDOR_INTEL,
+.family = 6,
+.model = 94,
+.stepping = 3,
+.features[FEAT_1_EDX] =
+CPUID_VME | CPUID_SSE2 | CPUID_SSE | CPUID_FXSR | CPUID_MMX |
+CPUID_CLFLUSH | CPUID_PSE36 | CPUID_PAT | CPUID_CMOV | CPUID_MCA |
+CPUID_PGE | CPUID_MTRR | CPUID_SEP | CPUID_APIC | CPUID_CX8 |
+CPUID_MCE | CPUID_PAE | CPUID_MSR | CPUID_TSC | CPUID_PSE |
+CPUID_DE | CPUID_FP87,
+.features[FEAT_1_ECX] =
+CPUID_EXT_AVX | CPUID_EXT_XSAVE | CPUID_EXT_AES |
+CPUID_EXT_POPCNT | CPUID_EXT_X2APIC | CPUID_EXT_SSE42 |
+CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 |
+CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3 |
+CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_FMA | CPUID_EXT_MOVBE |
+CPUID_EXT_PCID | CPUID_EXT_F16C | CPUID_EXT_RDRAND,
+.features[FEAT_8000_0001_EDX] =
+CPUID_EXT2_LM | CPUID_EXT2_RDTSCP | CPUID_EXT2_NX |
+CPUID_EXT2_SYSCALL,
+.features[FEAT_8000_0001_ECX] =
+CPUID_EXT3_ABM | CPUID_EXT3_LAHF_LM | CPUID_EXT3_3DNOWPREFETCH,
+.features[FEAT_7_0_EBX] =
+CPUID_7_0_EBX_FSGSBASE | CPUID_7_0_EBX_BMI1 |
+CPUID_7_0_EBX_HLE | CPUID_7_0_EBX_AVX2 | CPUID_7_0_EBX_SMEP |
+CPUID_7_0_EBX_BMI2 | CPUID_7_0_EBX_ERMS | CPUID_7_0_EBX_INVPCID |
+CPUID_7_0_EBX_RTM | CPUID_7_0_EBX_RDSEED | CPUID_7_0_EBX_ADX |
+CPUID_7_0_EBX_SMAP | CPUID_7_0_EBX_MPX,
+.features[FEAT_XSAVE] =
+CPUID_XSAVE_XSAVEOPT | CPUID_XSAVE_XSAVEC | CPUID_XSAVE_XSAVES |
+CPUID_XSAVE_XGETBV1,
+.features[FEAT_6_EAX] =
+CPUID_6_EAX_ARAT,
+.xlevel = 0x8008,
+.model_id = "Intel Core Processor (Skylake)",
+},
+{
.name = "Opteron_G1",
.level = 5,
.vendor = CPUID_VENDOR_AMD,
[Qemu-devel] HTTP access to QEMU Git repositories
Hello, is it possible to enable Git-over-HTTP on git.qemu.org ? http://git.qemu.org/?p=dtc.git;a=summary The summary page shows http://git.qemu.org/git/dtc.git but, $ curl http://git.qemu.org/git/dtc.git 301 Moved Permanently Moved Permanently The document has moved http://git.qemu.org/git/dtc.git/ ">here. Apache/2.2.14 (Ubuntu) Server at git.qemu.org Port 80 I'd like to access to QEMU Git repositories through HTTP proxy which blocks the Git port 9418/TCP. Best regards, Kai 野田 開 <noda...@gmail.com>
Re: [Qemu-devel] HTTP access to QEMU Git repositories
Those auxiliary repositories referenced by git-submodule, such as dtc.git in my last email, are only available on git.qemu.org. Regards, Kai 野田 開 <noda...@gmail.com> 2015-12-10 0:24 GMT+08:00 Laszlo Ersek <ler...@redhat.com>: > On 12/09/15 17:09, Kai Noda wrote: > > Hello, is it possible to enable Git-over-HTTP on git.qemu.org > > <http://git.qemu.org> ? > > > > http://git.qemu.org/?p=dtc.git;a=summary > > The summary page shows http://git.qemu.org/git/dtc.git but, > > > > $ curl http://git.qemu.org/git/dtc.git > > > > > > 301 Moved Permanently > > > > Moved Permanently > > The document has moved > href="http://git.qemu.org/git/dtc.git/;>here. > > > > Apache/2.2.14 (Ubuntu) Server at git.qemu.org > > <http://git.qemu.org> Port 80 > > > > > > I'd like to access to QEMU Git repositories through HTTP proxy which > > blocks the Git port 9418/TCP. > > The official QEMU mirror appears to be on github; you can clone it from > <https://github.com/qemu/qemu.git>. > > Thanks > Laszlo > > > > > Best regards, > > Kai > > > > 野田 開 <noda...@gmail.com <mailto:noda...@gmail.com>> > >
[Qemu-devel] [Bug 1516203] Re: qemu-system-x86_64 crashed with SIGSEGV in SDL_BlitCopy()
No time to debug, invaliding... ** Changed in: qemu (Ubuntu) Status: Incomplete => Invalid ** Information type changed from Public to Private -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1516203 Title: qemu-system-x86_64 crashed with SIGSEGV in SDL_BlitCopy() Status in QEMU: New Status in qemu package in Ubuntu: Invalid Bug description: with -device virtio-vga -cdrom ubuntu-15.10-desktop-amd64.iso ProblemType: Crash DistroRelease: Ubuntu 16.04 Package: qemu-system-x86 1:2.4+dfsg-4ubuntu2 ProcVersionSignature: Ubuntu 4.3.0-0.6-generic 4.3.0 Uname: Linux 4.3.0-0-generic x86_64 ApportVersion: 2.19.2-0ubuntu6 Architecture: amd64 CurrentDesktop: Unity Date: Sat Nov 14 05:05:25 2015 EcryptfsInUse: Yes ExecutablePath: /usr/bin/qemu-system-x86_64 InstallationDate: Installed on 2012-12-22 (1056 days ago) InstallationMedia: Ubuntu 12.04.1 LTS "Precise Pangolin" - Release amd64 (20120823.1) KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND kvm-irqfd-clean S< 0 0 497 2 0.0 [kvm-irqfd-clean] MachineType: Hewlett-Packard HP Elite 7300 Series MT ProcCmdline: qemu-system-x86_64 -machine ubuntu,accel=kvm -m 1024 -device virtio-vga -cdrom ubuntu-15.10-desktop-amd64.iso ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.3.0-0-generic root=UUID=8905185c-9d82-498c-970c-6fdb9ee07c45 ro quiet splash zswap.enabled=1 crashkernel=384M-:128M vt.handoff=7 SegvAnalysis: Segfault happened at: 0x7fecce94624f:movq (%rax),%mm0 PC (0x7fecce94624f) ok source "(%rax)" (0x7fecb5f0e010) not located in a known VMA region (needed readable region)! destination "%mm0" ok SegvReason: reading unknown VMA Signal: 11 SourcePackage: qemu StacktraceTop: ?? () from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0 ?? () from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0 SDL_LowerBlit () from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0 SDL_UpperBlit () from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0 ?? () Title: qemu-system-x86_64 crashed with SIGSEGV in SDL_LowerBlit() UpgradeStatus: Upgraded to xenial on 2013-06-19 (877 days ago) UserGroups: adm cdrom dip gnunet kismet kvm libvirtd lpadmin plugdev sambashare sbuild sudo dmi.bios.date: 05/18/2011 dmi.bios.vendor: AMI dmi.bios.version: 7.05 dmi.board.name: 2AB5 dmi.board.vendor: PEGATRON CORPORATION dmi.board.version: 1.01 dmi.chassis.asset.tag: CZC126149V dmi.chassis.type: 3 dmi.chassis.vendor: Hewlett-Packard dmi.modalias: dmi:bvnAMI:bvr7.05:bd05/18/2011:svnHewlett-Packard:pnHPElite7300SeriesMT:pvr1.01:rvnPEGATRONCORPORATION:rn2AB5:rvr1.01:cvnHewlett-Packard:ct3:cvr: dmi.product.name: HP Elite 7300 Series MT dmi.product.version: 1.01 dmi.sys.vendor: Hewlett-Packard To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1516203/+subscriptions
[Qemu-devel] [Bug 1516203] Re: qemu-system-x86_64 crashed with SIGSEGV in SDL_BlitCopy()
ProcCmdline: qemu-system-x86_64 -machine ubuntu,accel=kvm -m 1024 -device virtio-vga -cdrom ubuntu-15.10-desktop-amd64.iso -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1516203 Title: qemu-system-x86_64 crashed with SIGSEGV in SDL_BlitCopy() Status in QEMU: New Status in qemu package in Ubuntu: New Bug description: with -device virtio-vga -cdrom ubuntu-15.10-desktop-amd64.iso ProblemType: Crash DistroRelease: Ubuntu 16.04 Package: qemu-system-x86 1:2.4+dfsg-4ubuntu2 ProcVersionSignature: Ubuntu 4.3.0-0.6-generic 4.3.0 Uname: Linux 4.3.0-0-generic x86_64 ApportVersion: 2.19.2-0ubuntu6 Architecture: amd64 CurrentDesktop: Unity Date: Sat Nov 14 05:05:25 2015 EcryptfsInUse: Yes ExecutablePath: /usr/bin/qemu-system-x86_64 InstallationDate: Installed on 2012-12-22 (1056 days ago) InstallationMedia: Ubuntu 12.04.1 LTS "Precise Pangolin" - Release amd64 (20120823.1) KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND kvm-irqfd-clean S< 0 0 497 2 0.0 [kvm-irqfd-clean] MachineType: Hewlett-Packard HP Elite 7300 Series MT ProcCmdline: qemu-system-x86_64 -machine ubuntu,accel=kvm -m 1024 -device virtio-vga -cdrom ubuntu-15.10-desktop-amd64.iso ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.3.0-0-generic root=UUID=8905185c-9d82-498c-970c-6fdb9ee07c45 ro quiet splash zswap.enabled=1 crashkernel=384M-:128M vt.handoff=7 SegvAnalysis: Segfault happened at: 0x7fecce94624f:movq (%rax),%mm0 PC (0x7fecce94624f) ok source "(%rax)" (0x7fecb5f0e010) not located in a known VMA region (needed readable region)! destination "%mm0" ok SegvReason: reading unknown VMA Signal: 11 SourcePackage: qemu StacktraceTop: ?? () from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0 ?? () from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0 SDL_LowerBlit () from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0 SDL_UpperBlit () from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0 ?? () Title: qemu-system-x86_64 crashed with SIGSEGV in SDL_LowerBlit() UpgradeStatus: Upgraded to xenial on 2013-06-19 (877 days ago) UserGroups: adm cdrom dip gnunet kismet kvm libvirtd lpadmin plugdev sambashare sbuild sudo dmi.bios.date: 05/18/2011 dmi.bios.vendor: AMI dmi.bios.version: 7.05 dmi.board.name: 2AB5 dmi.board.vendor: PEGATRON CORPORATION dmi.board.version: 1.01 dmi.chassis.asset.tag: CZC126149V dmi.chassis.type: 3 dmi.chassis.vendor: Hewlett-Packard dmi.modalias: dmi:bvnAMI:bvr7.05:bd05/18/2011:svnHewlett-Packard:pnHPElite7300SeriesMT:pvr1.01:rvnPEGATRONCORPORATION:rn2AB5:rvr1.01:cvnHewlett-Packard:ct3:cvr: dmi.product.name: HP Elite 7300 Series MT dmi.product.version: 1.01 dmi.sys.vendor: Hewlett-Packard To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1516203/+subscriptions
[Qemu-devel] [Bug 1327608] [NEW] monitor socked path is cut a 105 characters
Public bug reported: Starting a VM like so: /usr/bin/qemu-system-x86_64 -machine accel=kvm -monitor unix:/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/lv- gentoosummerschool/gentoo-summerschool/gentoo- summerschool.img.monitor,server,nowait -name gentoo-summerschool -chardev socket,id=monitor,path=/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J /vg-virt/lv-gentoosummerschool/gentoo- summerschool/monitor.sock,server,nowait -monitor chardev:monitor -chardev socket,id=serial0,path=/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J /vg-virt/lv-gentoosummerschool/gentoo- summerschool/console.sock,server,nowait -serial chardev:serial0 -enable- kvm -cpu kvm64 -smp 2 -netdev tap,id=net0,script=/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J /vg-virt/lv-gentoosummerschool/gentoo-summerschool/qemu-ifup.bash -device e1000,netdev=net0,mac=00:00:00:00:00:02 -drive id=disk,file=/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg- virt/lv-gentoosummerschool/gentoo-summerschool/gentoo- summerschool.img,if=none -device ahci,id=ahci -device ide- drive,drive=disk,bus=ahci.0 -m 2048 -vga qxl -spice port=2002,addr=192.168.4.2,password=NO-thats-not-my-pwd -device virtio- serial-pci -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev spicevmc,id=spicechannel0,name=vdagent The path: unix:/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/lv- gentoosummerschool/gentoo-summerschool/gentoo-summerschool.img.monitor ...is cut like so when I try to shutdown: pink ~ # echo system_powerdown | socat - UNIX-CONNECT:/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/lv-gentoosummerschool/gentoo-summerschool/gentoo-summerschool.img.monitor 2014/06/08 06:39:01 socat[2344] E connect(3, AF=1 /srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/lv-gentoosummerschool/gentoo-summerschoo, 110): No such file or directory pink ~ # It does work with a sorter path like: pink ~ # echo system_powerdown | socat - UNIX-CONNECT:'/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/my.img.monitor' QEMU 1.5.3 monitor - type 'help' for more information (qemu) system_powerdown (qemu) pink ~ # ** Affects: qemu Importance: Undecided Status: New ** Tags: acpi monitor shutdown -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1327608 Title: monitor socked path is cut a 105 characters Status in QEMU: New Bug description: Starting a VM like so: /usr/bin/qemu-system-x86_64 -machine accel=kvm -monitor unix:/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt /lv-gentoosummerschool/gentoo-summerschool/gentoo- summerschool.img.monitor,server,nowait -name gentoo-summerschool -chardev socket,id=monitor,path=/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J /vg-virt/lv-gentoosummerschool/gentoo- summerschool/monitor.sock,server,nowait -monitor chardev:monitor -chardev socket,id=serial0,path=/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J /vg-virt/lv-gentoosummerschool/gentoo- summerschool/console.sock,server,nowait -serial chardev:serial0 -enable-kvm -cpu kvm64 -smp 2 -netdev tap,id=net0,script=/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J /vg-virt/lv-gentoosummerschool/gentoo-summerschool/qemu-ifup.bash -device e1000,netdev=net0,mac=00:00:00:00:00:02 -drive id=disk,file=/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J /vg-virt/lv-gentoosummerschool/gentoo-summerschool/gentoo- summerschool.img,if=none -device ahci,id=ahci -device ide- drive,drive=disk,bus=ahci.0 -m 2048 -vga qxl -spice port=2002,addr=192.168.4.2,password=NO-thats-not-my-pwd -device virtio-serial-pci -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev spicevmc,id=spicechannel0,name=vdagent The path: unix:/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt /lv-gentoosummerschool/gentoo-summerschool/gentoo- summerschool.img.monitor ...is cut like so when I try to shutdown: pink ~ # echo system_powerdown | socat - UNIX-CONNECT:/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/lv-gentoosummerschool/gentoo-summerschool/gentoo-summerschool.img.monitor 2014/06/08 06:39:01 socat[2344] E connect(3, AF=1 /srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/lv-gentoosummerschool/gentoo-summerschoo, 110): No such file or directory pink ~ # It does work with a sorter path like: pink ~ # echo system_powerdown | socat - UNIX-CONNECT:'/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/my.img.monitor' QEMU 1.5.3 monitor - type 'help' for more information (qemu) system_powerdown (qemu) pink ~ # To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1327608/+subscriptions
Re: [Qemu-devel] [PULL 7/7] vfio: fix mapping of MSIX bar
On Sat, Jan 18, 2014 at 3:25 AM, Alex Williamson
alex.william...@redhat.com wrote:
From: Alexey Kardashevskiy a...@ozlabs.ru
VFIO virtualizes MSIX table for the guest but not mapping the part of
a BAR which contains an MSIX table. Since vfio_mmap_bar() mmaps chunks
before and after the MSIX table, they have to be aligned to the host
page size which may be TARGET_PAGE_MASK (4K) or 64K in case of PPC64.
This fixes boundaries calculations to use the real host page size.
Without the patch, the chunk before MSIX table may overlap with the MSIX
table and mmap will fail in the host kernel. The result will be serious
slowdown as the whole BAR will be emulated by QEMU.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
hw/misc/vfio.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/misc/vfio.c b/hw/misc/vfio.c
index 432547c..8a1f1a1 100644
--- a/hw/misc/vfio.c
+++ b/hw/misc/vfio.c
@@ -2544,7 +2544,7 @@ static void vfio_map_bar(VFIODevice *vdev, int nr)
* potentially insert a direct-mapped subregion before and after it.
*/
if (vdev-msix vdev-msix-table_bar == nr) {
-size = vdev-msix-table_offset TARGET_PAGE_MASK;
+size = vdev-msix-table_offset qemu_host_page_mask;
}
strncat(name, mmap, sizeof(name) - strlen(name) - 1);
@@ -2556,8 +2556,8 @@ static void vfio_map_bar(VFIODevice *vdev, int nr)
if (vdev-msix vdev-msix-table_bar == nr) {
unsigned start;
-start = TARGET_PAGE_ALIGN(vdev-msix-table_offset +
- (vdev-msix-entries *
PCI_MSIX_ENTRY_SIZE));
+start = HOST_PAGE_ALIGN(vdev-msix-table_offset +
+(vdev-msix-entries * PCI_MSIX_ENTRY_SIZE));
Hi Alex,
I am new to vfio and qemu, and have some questions. Does MSIX have one
dedicated bar when qemu emulating the device? Looks your code maps
both the content before and after the MSIX table? If MSIX has
dedicated bar, I think we can just skip the MSIX bar, why do we need
to map the context before and after the MSIX table?
Thanks,
-Kai
size = start bar-size ? bar-size - start : 0;
strncat(name, msix-hi, sizeof(name) - strlen(name) - 1);
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PULL 7/7] vfio: fix mapping of MSIX bar
On Sun, Jan 19, 2014 at 10:11 PM, Alex Williamson
alex.william...@redhat.com wrote:
On Sun, 2014-01-19 at 22:03 +0800, Kai Huang wrote:
On Sat, Jan 18, 2014 at 3:25 AM, Alex Williamson
alex.william...@redhat.com wrote:
From: Alexey Kardashevskiy a...@ozlabs.ru
VFIO virtualizes MSIX table for the guest but not mapping the part of
a BAR which contains an MSIX table. Since vfio_mmap_bar() mmaps chunks
before and after the MSIX table, they have to be aligned to the host
page size which may be TARGET_PAGE_MASK (4K) or 64K in case of PPC64.
This fixes boundaries calculations to use the real host page size.
Without the patch, the chunk before MSIX table may overlap with the MSIX
table and mmap will fail in the host kernel. The result will be serious
slowdown as the whole BAR will be emulated by QEMU.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
hw/misc/vfio.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/misc/vfio.c b/hw/misc/vfio.c
index 432547c..8a1f1a1 100644
--- a/hw/misc/vfio.c
+++ b/hw/misc/vfio.c
@@ -2544,7 +2544,7 @@ static void vfio_map_bar(VFIODevice *vdev, int nr)
* potentially insert a direct-mapped subregion before and after it.
*/
if (vdev-msix vdev-msix-table_bar == nr) {
-size = vdev-msix-table_offset TARGET_PAGE_MASK;
+size = vdev-msix-table_offset qemu_host_page_mask;
}
strncat(name, mmap, sizeof(name) - strlen(name) - 1);
@@ -2556,8 +2556,8 @@ static void vfio_map_bar(VFIODevice *vdev, int nr)
if (vdev-msix vdev-msix-table_bar == nr) {
unsigned start;
-start = TARGET_PAGE_ALIGN(vdev-msix-table_offset +
- (vdev-msix-entries *
PCI_MSIX_ENTRY_SIZE));
+start = HOST_PAGE_ALIGN(vdev-msix-table_offset +
+(vdev-msix-entries *
PCI_MSIX_ENTRY_SIZE));
Hi Alex,
I am new to vfio and qemu, and have some questions. Does MSIX have one
dedicated bar when qemu emulating the device? Looks your code maps
both the content before and after the MSIX table? If MSIX has
dedicated bar, I think we can just skip the MSIX bar, why do we need
to map the context before and after the MSIX table?
vfio is used to pass through existing physical devices. We don't get to
define the MSI-X layout of those devices. Therefore we must be prepared
to handle any possible layout. The BAR may be dedicated to the MSI-X
table or it may also include memory mapped register space for the
device. Thanks,
Alex
This sounds reasonable. So if there's bar contains both MSIX table and
register, the register access will be trapped and emulated?
Btw, did vfio_mmap_bar consider the pedding bit array table? I don't
think they can be accessed directly by userspace either.
Thanks,
-Kai
Re: [Qemu-devel] Add support for new image type
would provide the same functionality to your customers, keep clear from legal grey areas, contribute to QEMU positively, and perhaps get some advertising for your product. Paolo I think just plain iSCSI is a more appropriate solution for our needs, as interesting as this sounds :). Again, thanks for the clarity on these issues. It's definitely a learning curve for many of us. -Kai Meyer
Re: [Qemu-devel] Add support for new image type
On 05/17/2012 01:43 PM, Paolo Bonzini wrote: Il 17/05/2012 19:53, Kai Meyer ha scritto: Morally it's wrong, but a copyright holder cannot stop you on moral grounds. Legally, you should consult a lawyer. What you say is morally wrong here is a bit ambiguous to me. Do you mean using modified versions of qemu internally at StorageCraft is morally wrong? No, it's fine. Internally you can do whatever you want. Or do you mean that a run-time linking version would not be in violation of the GPL legally, but it would be morally wrong? I cannot answer about the legal part; it's possible that it's legal but anyway you should listen to a lawyer's opinion and not mine. Anthony explained that, at least for him, it would be morally wrong. Other people's mileage may vary. Paolo It's enough for us that prominent members of the qemu community (particularly copyright holders) consider it immoral. We'll simply avoid it entirely. I think this will wrap things up for us quite nicely. Thanks again for all your help and patience.
Re: [Qemu-devel] Add support for new image type
On 05/16/2012 12:21 PM, Anthony Liguori wrote: On 05/16/2012 12:48 PM, Paolo Bonzini wrote: Il 16/05/2012 19:06, Kai Meyer ha scritto: 1) It's been suggested to me that since we have the rights to distribute our closed source shared library, there is a precedence for being able to distributed a modified version of qemu that does run-time linking against our shared library. The absence or presence of our shared library simply enables or disables support for our file format. We are happy to make available all changes to the qemu source code, but we are not in a position to re-license our shared library's source code to a compatible GPL license. This seems to be in contradiction to Paolo's statement above, so while I can't resist asking if this is possible, I don't have any realistic expectation that this is acceptable. That's really getting into grey areas. IANAL, so I cannot answer this question. It's not morally grey though. The GPL is designed to attempt to prohibit this and as a copyright holder in QEMU, I choose[1] to use the GPL specifically to prevent this. QEMU only exists because people have contributed back their improvements to the project. Not contributing back means that you are only taking from the community withing returning anything back. Only your lawyer can tell you whether this is legal or not, but it's certainly unkind. [1] I == Anthony Liguori, not IBM. I began my involvement in QEMU long before IBM paid me to be. Regards, Anthony Liguori Even though it makes it clear that I will not be able to have the tight integration with QEMU that I would like, I appreciate learning that you are a copyright holder, and intended to use the GPL to prevent what I'm trying to do. StorageCraft is new to Linux, and I am a fairly young software engineer, so our interaction with GPL software is fairly low. This has been very insightful and instructive.
Re: [Qemu-devel] Add support for new image type
On 03/01/2012 11:54 PM, Paolo Bonzini wrote: It does not matter whether it is upstream or not. When you distribute your modified QEMU binary, anyone who receives it has the right to ask you for the complete corresponding source code. I also suggest that you write a wrapper around your library that exports the contents as iSCSI or NBD. Paolo I simply can't get over how simple it was to integrate our closed-source block-wise access library with qemu, or how many uses there are from other projects like libguestfs that would automatically gain support for our format. Since we last spoke, we've been working on iSCSI, but I've also received some conflicting interpretations on the GPL. As I learn more about the GPL, it is clear that the intent is to help the owners retain as many rights as they choose to retain. In the spirit of pleasing the owners of qemu, I'd like to ask two questions. We are not interested in playing in legal grey areas, so unless there is a clear sure go for it answer, we're only too happy to comply with your wishes. 1) It's been suggested to me that since we have the rights to distribute our closed source shared library, there is a precedence for being able to distributed a modified version of qemu that does run-time linking against our shared library. The absence or presence of our shared library simply enables or disables support for our file format. We are happy to make available all changes to the qemu source code, but we are not in a position to re-license our shared library's source code to a compatible GPL license. This seems to be in contradiction to Paolo's statement above, so while I can't resist asking if this is possible, I don't have any realistic expectation that this is acceptable. 2) The GPL has provisions for you to create an exception where you have specified a controlled interface. Am I right that qemu has not added this controlled interface exception for file format access? What are your thoughts on adding this exception if it is not present? I would think that struct BlockDriver would make an excellent candidate for this. On a personal note, I am an open source enthusiast, so the last thing I would want to do is to help alienate the relationship between qemu and storagecraft. I'm not asking these questions to look for a legal corner to worm my way into, but because I love open source software, and I want to learn how to play nicely. (Plus there's that virtualization coolness factor to this solution that I can't resist.)
Re: [Qemu-devel] Add support for new image type
On 05/16/2012 11:48 AM, Paolo Bonzini wrote: Il 16/05/2012 19:06, Kai Meyer ha scritto: 1) It's been suggested to me that since we have the rights to distribute our closed source shared library, there is a precedence for being able to distributed a modified version of qemu that does run-time linking against our shared library. The absence or presence of our shared library simply enables or disables support for our file format. We are happy to make available all changes to the qemu source code, but we are not in a position to re-license our shared library's source code to a compatible GPL license. This seems to be in contradiction to Paolo's statement above, so while I can't resist asking if this is possible, I don't have any realistic expectation that this is acceptable. That's really getting into grey areas. IANAL, so I cannot answer this question. But as an aside, the GPL _does_ give you rights to distribute any modification you make to QEMU. The right questions to ask are: 1) a practical question: would the QEMU community accept that contribution? The answer here is most likely not. 2) a legal question (i.e. the question that a court would answer): what are the rights of the _recipients_ of your version (and especially of the copyright holders of QEMU)? Do they have rights to ask you for the source code to the shared library, and to receive it under the GPL? Again I cannot answer here (and I couldn't even if I were a lawyer). (Remember that however what we proposed was not just relicensing your library source code, but alternatively to rewrite it from scratch with no particular attention to performance. That would be a completely different story, probably also for your lawyers. You could also share any internal spec you have and hire someone to write the QEMU interface for you, basically a form of clean-room reverse engineering). 2) The GPL has provisions for you to create an exception where you have specified a controlled interface. Am I right that qemu has not added this controlled interface exception for file format access? What are your thoughts on adding this exception if it is not present? I would think that struct BlockDriver would make an excellent candidate for this. This would have to be applied to all files (not just block/*.c say) and agreed upon by all QEMU copyright holders. The second condition is quite obvious, the first I'll spend a few more words on. The first condition is because the code overall can be distributed as long as it fulfills all existing licenses. QEMU right now has files under BSD, GPLv2, GPLv2-or-later, LGPLv2.1-or-later and perhaps some more licenses. You can take code from individual files (or complete files) and reuse it under the license indicated in the header of that file. However, you can only distribute QEMU as a whole under the intersection of those licenses, which is GPLv2. If you add another license to the mix (GPL+controlled interface) for block/*.c, QEMU as a whole could still only be distributed under GPLv2. On a personal note, I am an open source enthusiast, so the last thing I would want to do is to help alienate the relationship between qemu and storagecraft. I'm not asking these questions to look for a legal corner to worm my way into, but because I love open source software, and I want to learn how to play nicely. (Plus there's that virtualization coolness factor to this solution that I can't resist.) Sure, personally I appreciate your honesty even though I disagree with your goal. :) Paolo I want to respect the lines that the GPL draws, and this helps clarify for me where some of those lines are. To help me better understand, what would be the terminology used for the explanation between what I would call source code licensing, and project licensing? Also, where in the code (or rather what file) can I see this distinction? It seems like something critical to be aware of, and I'd like to avoid missing something like this in the future as I give advice on what software we can use. Thanks for being patient with me. If you would help clarify a separate point, I would be grateful. As I understand it, I am able to modify qemu for my own purposes (like testing the filesystem integrity inside a backup image by using guestmount to mount it). How much of that work (source code, principles, explanations, ect) can I share, and with whom can I share it with? For instance, would qemu be opposed to a StorageCraft wiki article on How to add support for our Backup Images to qemu? And would it make a difference if it was a publicly accessible wiki vs a private wiki? I am interested in respecting the spirit and purpose of the GPL license for the qemu project. The header file for our image library is open, and we encourage our customers to do interesting things with the library. It is unfortunate for this project (and any other GPL project we may encounter) that the library itself can't be opened. -Kai Meyer
[Qemu-devel] [PATCH] qapi: g_hash_table_find() instead of GHashTableIter.
From: NODA, Kai noda...@gmail.com
GHashTableIter was first introduced in glib 2.16.
This patch removes it in favor of older g_hash_table_find()
for better compatibility with RHEL5.
---
qapi/qmp-input-visitor.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/qapi/qmp-input-visitor.c b/qapi/qmp-input-visitor.c
index 74386b9..4cdc47d 100644
--- a/qapi/qmp-input-visitor.c
+++ b/qapi/qmp-input-visitor.c
@@ -87,20 +87,29 @@ static void qmp_input_push(QmpInputVisitor *qiv, QObject
*obj, Error **errp)
qiv-nb_stack++;
}
+/** Only for qmp_input_pop. */
+static gboolean always_true(gpointer key, gpointer val, gpointer user_pkey)
+{
+*(const char **)user_pkey = (const char *)key;
+return TRUE;
+}
+
static void qmp_input_pop(QmpInputVisitor *qiv, Error **errp)
{
-GHashTableIter iter;
-gpointer key;
+assert(qiv-nb_stack 0);
-if (qiv-strict qiv-stack[qiv-nb_stack - 1].h) {
-g_hash_table_iter_init(iter, qiv-stack[qiv-nb_stack - 1].h);
-if (g_hash_table_iter_next(iter, key, NULL)) {
-error_set(errp, QERR_QMP_EXTRA_MEMBER, (char *) key);
+if (qiv-strict) {
+GHashTable * const top_ht = qiv-stack[qiv-nb_stack - 1].h;
+if (top_ht) {
+if (g_hash_table_size(top_ht)) {
+const char *key;
+g_hash_table_find(top_ht, always_true, key);
+error_set(errp, QERR_QMP_EXTRA_MEMBER, key);
+}
+g_hash_table_unref(top_ht);
}
-g_hash_table_unref(qiv-stack[qiv-nb_stack - 1].h);
}
-assert(qiv-nb_stack 0);
qiv-nb_stack--;
}
--
1.7.9.5
Re: [Qemu-devel] current git master compile fails on Debian 4.0
Hi Paolo, I've encountered the same problem as Erik on my RHEL5 machine with glib 2.12, and made a patch to replace GHashTableIter with g_hash_table_find(). https://github.com/nodakai/QEMU/commit/4a9dd009feb1d78e3566069336a0d1b9a296bd23 I think it's an almost same approach with yours, but have not tested it very carefully. Btw I found https://github.com/qemu/QEMU has not been updated for months... 2012/4/10 Paolo Bonzini pbonz...@redhat.com: Il 10/04/2012 11:18, Erik Rull ha scritto: Hi all, on the current git master, I cannot compile any more. The error is: qapi/qmp-input-visitor.c: In function 'qmp_input_pop': qapi/qmp-input-visitor.c:92: error: 'GHashTableIter' undeclared (first use in this function) qapi/qmp-input-visitor.c:92: error: (Each undeclared identifier is reported only once qapi/qmp-input-visitor.c:92: error: for each function it appears in.) qapi/qmp-input-visitor.c:92: error: expected ';' before 'iter' qapi/qmp-input-visitor.c:96: warning: implicit declaration of function 'g_hash_table_iter_init' qapi/qmp-input-visitor.c:96: warning: nested extern declaration of 'g_hash_table_iter_init' qapi/qmp-input-visitor.c:96: error: 'iter' undeclared (first use in this function) qapi/qmp-input-visitor.c:97: warning: implicit declaration of function 'g_hash_table_iter_next' qapi/qmp-input-visitor.c:97: warning: nested extern declaration of 'g_hash_table_iter_next' make: *** [qapi/qmp-input-visitor.o] Error 1 Must have appeared within the last 14 days. It's on my todo list, but if you can make a patch (see http://lists.gnu.org/archive/html/qemu-devel/2012-04/msg00097.html for some discussion) it would be quite welcome. What version of glib is in Debian 4.0? -- 野田 開 noda...@gmail.com
Re: [Qemu-devel] Add support for new image type
From: Paolo Bonzini [pbonz...@redhat.com] Sent: Thursday, March 01, 2012 11:54 PM To: Kai Meyer Cc: Anthony Liguori; Stefan Weil; qemu-devel@nongnu.org; Nate Bushman Subject: Re: Add support for new image type Il 01/03/2012 22:14, Kai Meyer ha scritto: If we can't use qemu in general use-cases (since we can't push support for our images up stream), we could still really benefit from a targeted use-cases (like a Rescue Environment.) It does not matter whether it is upstream or not. When you distribute your modified QEMU binary, anyone who receives it has the right to ask you for the complete corresponding source code. I also suggest that you write a wrapper around your library that exports the contents as iSCSI or NBD. Paolo Well, yes. I was assuming that there was potential for us to be able to distribute qemu modifications that would not require us opening up our library. The more we look at it, and some past precedence we've experienced, it looks like it's not going to happen. I think I agree that iSCSI is really our only option (legally). Too bad. The code was so simple to integrate directly into qemu. I have to give you guys kudos again for already having such a simple integration point. -Kai Meyer
Re: [Qemu-devel] Add support for new image type
On 03/01/2012 08:03 AM, Kevin Wolf wrote: Am 29.02.2012 22:52, schrieb Kai Meyer: Is it possible to extend qemu to support a new image type? I have an image type that is ready for consumption and I'm looking for the integration point between qemu and the new image format. Which image format do you want to get integrated? Have a look at block/qcow2.c to get an idea of what a qemu block driver looks like. At the bottom of the file there is a struct that contains function pointers to all exported functions, so this is usually a good place to start exploring a driver. Kevin Great, this is exactly what we're after. I work for StorageCraft, and we would like to figure out some way to allow qemu to directly consume our image-based backups. It would provide us with user-space mounting (via libguestfs) as well as booting VMs directly from Backup images. We already have a proprietary image access library that provides block-wise access to our image files. I have been able to scratch together a proof of concept already, which I am really pleased with. I see only two roadblocks for which I don't have immediate answers for. 1) Licensing Is it possible to license our contributions in such a way that we do not need to open the source code of our image access library? 2) External dependency on our image access library. We do not want to force qemu to require our image access library to be present to build. Would it be better to do a conditional build (./configure --with-spf) or a run-time check for our image access library?
Re: [Qemu-devel] Add support for new image type
On 03/01/2012 01:10 PM, Stefan Weil wrote: Am 01.03.2012 20:45, schrieb Kai Meyer: On 03/01/2012 08:03 AM, Kevin Wolf wrote: Am 29.02.2012 22:52, schrieb Kai Meyer: Is it possible to extend qemu to support a new image type? I have an image type that is ready for consumption and I'm looking for the integration point between qemu and the new image format. Which image format do you want to get integrated? Have a look at block/qcow2.c to get an idea of what a qemu block driver looks like. At the bottom of the file there is a struct that contains function pointers to all exported functions, so this is usually a good place to start exploring a driver. Kevin Great, this is exactly what we're after. I work for StorageCraft, and we would like to figure out some way to allow qemu to directly consume our image-based backups. It would provide us with user-space mounting (via libguestfs) as well as booting VMs directly from Backup images. We already have a proprietary image access library that provides block-wise access to our image files. I have been able to scratch together a proof of concept already, which I am really pleased with. I see only two roadblocks for which I don't have immediate answers for. 1) Licensing Is it possible to license our contributions in such a way that we do not need to open the source code of our image access library? This is not possible if you want to link your image access library statically. QEMU uses GPL v2. You can use a patched QEMU internally, but as soon as you want to give it to customers (or get it integrated in the official source tree), you must publish all code which is needed under an open license. It is a shared library. If your image access library is a shared library (linked at runtime), the situation is more difficult. The intention of the GPL is still that you have to publish your code (this is also what the FSF says), but there are different opinions for GPL v2. See http://en.wikipedia.org/wiki/GNU_General_Public_License for more information. My primary concern right now is if it is a reasonable course of action. I will eventually rely on our internal processes to determine how to remain in compliance with exiting licenses. http://wiki.qemu.org/License Portions of qemu (ie the qed block driver) are licensed under the LGPL. Can you help me understand the impact of licensing our contributions under the LGPL instead of GPL? I personally don't like the idea of QEMU supporting closed source shared libraries. I'm sorry to hear that, however you are being very helpful, so I appreciate that. 2) External dependency on our image access library. We do not want to force qemu to require our image access library to be present to build. Would it be better to do a conditional build (./configure --with-spf) or a run-time check for our image access library? You'll need the conditional build for those people who don't want support In addition to the conditional build, would it be appropriate (more easily accepted) if there was a run-time check for the existence of the library instead of at compile time? This would allow us to enable image access on existing systems (that are up to date) instead of requiring separate maintenance of qemu versions (ie: hosting our own distribution of qemu packages for different platforms, or requiring a rebuild on every system.) for your image type. Regards, Stefan Weil Thanks! -Kai Meyer
Re: [Qemu-devel] Add support for new image type
On 03/01/2012 01:18 PM, Stefan Weil wrote: Am 01.03.2012 21:10, schrieb Stefan Weil: Am 01.03.2012 20:45, schrieb Kai Meyer: On 03/01/2012 08:03 AM, Kevin Wolf wrote: Am 29.02.2012 22:52, schrieb Kai Meyer: Is it possible to extend qemu to support a new image type? I have an image type that is ready for consumption and I'm looking for the integration point between qemu and the new image format. Which image format do you want to get integrated? Have a look at block/qcow2.c to get an idea of what a qemu block driver looks like. At the bottom of the file there is a struct that contains function pointers to all exported functions, so this is usually a good place to start exploring a driver. Kevin Great, this is exactly what we're after. I work for StorageCraft, and we would like to figure out some way to allow qemu to directly consume our image-based backups. It would provide us with user-space mounting (via libguestfs) as well as booting VMs directly from Backup images. We already have a proprietary image access library that provides block-wise access to our image files. I have been able to scratch together a proof of concept already, which I am really pleased with. I see only two roadblocks for which I don't have immediate answers for. 1) Licensing Is it possible to license our contributions in such a way that we do not need to open the source code of our image access library? This is not possible if you want to link your image access library statically. QEMU uses GPL v2. You can use a patched QEMU internally, but as soon as you want to give it to customers (or get it integrated in the official source tree), you must publish all code which is needed under an open license. If your image access library is a shared library (linked at runtime), the situation is more difficult. The intention of the GPL is still that you have to publish your code (this is also what the FSF says), but there are different opinions for GPL v2. See http://en.wikipedia.org/wiki/GNU_General_Public_License for more information. I personally don't like the idea of QEMU supporting closed source shared libraries. 2) External dependency on our image access library. We do not want to force qemu to require our image access library to be present to build. Would it be better to do a conditional build (./configure --with-spf) or a run-time check for our image access library? You'll need the conditional build for those people who don't want support for your image type. Regards, Stefan Weil I forgot to mention a possible solution: instead of using your image access library (which is closed source), you could write new access code (maybe with reduced functionality) and publish that code under an open source license. QEMU uses this approach for some image types where we don't have the original source code (for example block/vpc.c or block/vmdk.c). Regards, Stefan Weil I haven't planned on pitching that as a solution, but I will keep it in mind.
Re: [Qemu-devel] Add support for new image type
On 03/01/2012 02:05 PM, Anthony Liguori wrote: On 03/01/2012 02:18 PM, Stefan Weil wrote: Am 01.03.2012 21:10, schrieb Stefan Weil: Am 01.03.2012 20:45, schrieb Kai Meyer: On 03/01/2012 08:03 AM, Kevin Wolf wrote: Am 29.02.2012 22:52, schrieb Kai Meyer: Is it possible to extend qemu to support a new image type? I have an image type that is ready for consumption and I'm looking for the integration point between qemu and the new image format. Which image format do you want to get integrated? Have a look at block/qcow2.c to get an idea of what a qemu block driver looks like. At the bottom of the file there is a struct that contains function pointers to all exported functions, so this is usually a good place to start exploring a driver. Kevin Great, this is exactly what we're after. I work for StorageCraft, and we would like to figure out some way to allow qemu to directly consume our image-based backups. It would provide us with user-space mounting (via libguestfs) as well as booting VMs directly from Backup images. We already have a proprietary image access library that provides block-wise access to our image files. I have been able to scratch together a proof of concept already, which I am really pleased with. I see only two roadblocks for which I don't have immediate answers for. 1) Licensing Is it possible to license our contributions in such a way that we do not need to open the source code of our image access library? This is not possible if you want to link your image access library statically. QEMU uses GPL v2. You can use a patched QEMU internally, but as soon as you want to give it to customers (or get it integrated in the official source tree), you must publish all code which is needed under an open license. If your image access library is a shared library (linked at runtime), the situation is more difficult. The intention of the GPL is still that you have to publish your code (this is also what the FSF says), but there are different opinions for GPL v2. See http://en.wikipedia.org/wiki/GNU_General_Public_License for more information. I personally don't like the idea of QEMU supporting closed source shared libraries. 2) External dependency on our image access library. We do not want to force qemu to require our image access library to be present to build. Would it be better to do a conditional build (./configure --with-spf) or a run-time check for our image access library? You'll need the conditional build for those people who don't want support for your image type. Regards, Stefan Weil I forgot to mention a possible solution: instead of using your image access library (which is closed source), you could write new access code (maybe with reduced functionality) and publish that code under an open source license. If the image access library is solely for use in a proprietary system, I would be opposed to merging it. The only real work around here is to make use of open standard like iSCSI (which is already supported natively by QEMU). Regards, Anthony Liguori Ok, pushing support upstream for our image format is looking unlikely, which is understandable. I'll hold off on doing more work then until I can hear from our legal department on whether or not we could distribute a modified version of qemu with out requiring publication of our proprietary source code. If we can't use qemu in general use-cases (since we can't push support for our images up stream), we could still really benefit from a targeted use-cases (like a Rescue Environment.) However, I should say I'm very pleased with how simple (code wise) it was to add support for the image format to qemu. -Kai Meyer
[Qemu-devel] Add support for new image type
Is it possible to extend qemu to support a new image type? I have an image type that is ready for consumption and I'm looking for the integration point between qemu and the new image format. -Kai Meyer
Re: [Qemu-devel] [PATCH v6 4/4] Add support for net bridge
On 12/19/2011 09:11 PM, Corey Bryant wrote:
The most common use of -net tap is to connect a tap device to a bridge. This
requires the use of a script and running qemu as root in order to allocate a
tap device to pass to the script.
This model is great for portability and flexibility but it's incredibly
difficult to eliminate the need to run qemu as root. The only really viable
mechanism is to use tunctl to create a tap device, attach it to a bridge as
root, and then hand that tap device to qemu. The problem with this mechanism
is that it requires administrator intervention whenever a user wants to create
a guest.
By essentially writing a helper that implements the most common qemu-ifup
script that can be safely given cap_net_admin, we can dramatically simplify
things for non-privileged users. We still support existing -net tap options
as a mechanism for advanced users and backwards compatibility.
Currently, this is very Linux centric but there's really no reason why it
couldn't be extended for other Unixes.
A typical invocation would be similar to one of the following:
qemu linux.img -net bridge -net nic,model=virtio
qemu linux.img -net tap,helper=/usr/local/libexec/qemu-bridge-helper
-net nic,model=virtio
qemu linux.img -netdev bridge,id=hn0
-device virtio-net-pci,netdev=hn0,id=nic1
qemu linux.img -netdev
tap,helper=/usr/local/libexec/qemu-bridge-helper,id=hn0
-device virtio-net-pci,netdev=hn0,id=nic1
The default bridge that we attach to is br0. The thinking is that a distro
could preconfigure such an interface to allow out-of-the-box bridged networking.
Alternatively, if a user wants to use a different bridge, a typical invocation
would be simliar to one of the following:
qemu linux.img -net bridge,br=qemubr0 -net nic,model=virtio
qemu linux.img -net
tap,helper=/usr/local/libexec/qemu-bridge-helper,br=qemubr0
-net nic,model=virtio
qemu linux.img -netdev bridge,br=qemubr0,id=hn0
-device virtio-net-pci,netdev=hn0,id=nic1
qemu linux.img -netdev
tap,helper=/usr/local/libexec/qemu-bridge-helper,br=qemubr0,id=hn0
-device virtio-net-pci,netdev=hn0,id=nic1
Signed-off-by: Anthony Liguorialigu...@us.ibm.com
Signed-off-by: Richa Marwaharmar...@linux.vnet.ibm.com
Signed-off-by: Corey Bryantcor...@linux.vnet.ibm.com
---
configure |2 +
net.c | 29 -
net.h |3 +
net/tap.c | 187 ++-
net/tap.h |3 +
qemu-options.hx | 74 ++
6 files changed, 281 insertions(+), 17 deletions(-)
diff --git a/configure b/configure
index 6ed4196..4839694 100755
--- a/configure
+++ b/configure
@@ -2905,6 +2905,8 @@ echo sysconfdir=$sysconfdir $config_host_mak
echo docdir=$docdir $config_host_mak
echo confdir=$confdir $config_host_mak
echo libexecdir=\${prefix}/libexec $config_host_mak
+echo CONFIG_QEMU_SHAREDIR=\$prefix$datasuffix\ $config_host_mak
+echo CONFIG_QEMU_HELPERDIR=\$prefix/libexec\ $config_host_mak
case $cpu in
i386|x86_64|alpha|arm|cris|hppa|ia64|lm32|m68k|microblaze|mips|mips64|ppc|ppc64|s390|s390x|sparc|sparc64|unicore32)
diff --git a/net.c b/net.c
index f7bebf8..9296224 100644
--- a/net.c
+++ b/net.c
@@ -952,6 +952,14 @@ static const struct {
.type = QEMU_OPT_STRING,
.help = script to shut down the interface,
}, {
+.name = br,
+.type = QEMU_OPT_STRING,
+.help = bridge name,
+}, {
+.name = helper,
+.type = QEMU_OPT_STRING,
+.help = command to execute to configure bridge,
+}, {
.name = sndbuf,
.type = QEMU_OPT_SIZE,
.help = send buffer limit
@@ -1049,6 +1057,23 @@ static const struct {
{ /* end of list */ }
},
},
+[NET_CLIENT_TYPE_BRIDGE] = {
+.type = bridge,
+.init = net_init_bridge,
+.desc = {
+NET_COMMON_PARAMS_DESC,
+{
+.name = br,
+.type = QEMU_OPT_STRING,
+.help = bridge name,
+}, {
+.name = helper,
+.type = QEMU_OPT_STRING,
+.help = command to execute to configure bridge,
+},
+{ /* end of list */ }
+},
+},
};
int net_client_init(Monitor *mon, QemuOpts *opts, int is_netdev)
@@ -1071,7 +1096,8 @@ int net_client_init(Monitor *mon, QemuOpts *opts, int
is_netdev)
#ifdef CONFIG_VDE
strcmp(type, vde) != 0
#endif
-strcmp(type, socket) != 0) {
+strcmp(type, socket) != 0
+strcmp(type, bridge) != 0) {
qerror_report(QERR_INVALID_PARAMETER_VALUE, type,
a netdev backend type);
Re: [Qemu-devel] [PATCH v6 4/4] Add support for net bridge
On 12/20/2011 06:02 PM, Hui Kai Ran wrote:
On 12/19/2011 09:11 PM, Corey Bryant wrote:
The most common use of -net tap is to connect a tap device to a
bridge. This
requires the use of a script and running qemu as root in order to
allocate a
tap device to pass to the script.
This model is great for portability and flexibility but it's incredibly
difficult to eliminate the need to run qemu as root. The only really
viable
mechanism is to use tunctl to create a tap device, attach it to a
bridge as
root, and then hand that tap device to qemu. The problem with this
mechanism
is that it requires administrator intervention whenever a user wants
to create
a guest.
By essentially writing a helper that implements the most common
qemu-ifup
script that can be safely given cap_net_admin, we can dramatically
simplify
things for non-privileged users. We still support existing -net tap
options
as a mechanism for advanced users and backwards compatibility.
Currently, this is very Linux centric but there's really no reason
why it
couldn't be extended for other Unixes.
A typical invocation would be similar to one of the following:
qemu linux.img -net bridge -net nic,model=virtio
qemu linux.img -net tap,helper=/usr/local/libexec/qemu-bridge-helper
-net nic,model=virtio
qemu linux.img -netdev bridge,id=hn0
-device virtio-net-pci,netdev=hn0,id=nic1
qemu linux.img -netdev
tap,helper=/usr/local/libexec/qemu-bridge-helper,id=hn0
-device virtio-net-pci,netdev=hn0,id=nic1
The default bridge that we attach to is br0. The thinking is that a
distro
could preconfigure such an interface to allow out-of-the-box bridged
networking.
Alternatively, if a user wants to use a different bridge, a typical
invocation
would be simliar to one of the following:
qemu linux.img -net bridge,br=qemubr0 -net nic,model=virtio
qemu linux.img -net
tap,helper=/usr/local/libexec/qemu-bridge-helper,br=qemubr0
-net nic,model=virtio
qemu linux.img -netdev bridge,br=qemubr0,id=hn0
-device virtio-net-pci,netdev=hn0,id=nic1
qemu linux.img -netdev
tap,helper=/usr/local/libexec/qemu-bridge-helper,br=qemubr0,id=hn0
-device virtio-net-pci,netdev=hn0,id=nic1
Signed-off-by: Anthony Liguorialigu...@us.ibm.com
Signed-off-by: Richa Marwaharmar...@linux.vnet.ibm.com
Signed-off-by: Corey Bryantcor...@linux.vnet.ibm.com
---
configure |2 +
net.c | 29 -
net.h |3 +
net/tap.c | 187
++-
net/tap.h |3 +
qemu-options.hx | 74 ++
6 files changed, 281 insertions(+), 17 deletions(-)
diff --git a/configure b/configure
index 6ed4196..4839694 100755
--- a/configure
+++ b/configure
@@ -2905,6 +2905,8 @@ echo sysconfdir=$sysconfdir $config_host_mak
echo docdir=$docdir $config_host_mak
echo confdir=$confdir $config_host_mak
echo libexecdir=\${prefix}/libexec $config_host_mak
+echo CONFIG_QEMU_SHAREDIR=\$prefix$datasuffix\ $config_host_mak
+echo CONFIG_QEMU_HELPERDIR=\$prefix/libexec\ $config_host_mak
case $cpu in
i386|x86_64|alpha|arm|cris|hppa|ia64|lm32|m68k|microblaze|mips|mips64|ppc|ppc64|s390|s390x|sparc|sparc64|unicore32)
diff --git a/net.c b/net.c
index f7bebf8..9296224 100644
--- a/net.c
+++ b/net.c
@@ -952,6 +952,14 @@ static const struct {
.type = QEMU_OPT_STRING,
.help = script to shut down the interface,
}, {
+.name = br,
+.type = QEMU_OPT_STRING,
+.help = bridge name,
+}, {
+.name = helper,
+.type = QEMU_OPT_STRING,
+.help = command to execute to configure bridge,
+}, {
.name = sndbuf,
.type = QEMU_OPT_SIZE,
.help = send buffer limit
@@ -1049,6 +1057,23 @@ static const struct {
{ /* end of list */ }
},
},
+[NET_CLIENT_TYPE_BRIDGE] = {
+.type = bridge,
+.init = net_init_bridge,
+.desc = {
+NET_COMMON_PARAMS_DESC,
+{
+.name = br,
+.type = QEMU_OPT_STRING,
+.help = bridge name,
+}, {
+.name = helper,
+.type = QEMU_OPT_STRING,
+.help = command to execute to configure bridge,
+},
+{ /* end of list */ }
+},
+},
};
int net_client_init(Monitor *mon, QemuOpts *opts, int is_netdev)
@@ -1071,7 +1096,8 @@ int net_client_init(Monitor *mon, QemuOpts
*opts, int is_netdev)
#ifdef CONFIG_VDE
strcmp(type, vde) != 0
#endif
-strcmp(type, socket) != 0) {
+strcmp(type, socket) != 0
+strcmp(type, bridge) != 0) {
qerror_report
Re: [Qemu-devel] multifunction pci virtio-blk devices
On 12/15/2011 04:18 PM, Stefan Hajnoczi wrote: On Thu, Dec 15, 2011 at 02:00:11PM +0800, Hui Kai Ran wrote: but for virtio blk device , how can i open multifunction ability? Please search the mailing list archives, Anthony has posted instructions in previous threads. Stefan I found it. thanks!
[Qemu-devel] multifunction pci virtio-blk devices
Hi, It seems that qemu now have the ability to install pci device with mutlifunction=on, such as I got a cfg file to start qemu [device ehci] driver = ich9-usb-ehci1 addr = 0d.7 multifunction = on [device ehci1] driver = ich9-usb-ehci1 addr = 0d.3 multifunction = on [device ehci2] driver = ich9-usb-ehci1 addr = 0d.4 multifunction = on [device ehci3] driver = ich9-usb-ehci1 addr = 0d.5 multifunction = on I end up with four usb controllers in one slot. but for virtio blk device , how can i open multifunction ability? Thanks.
Re: [Qemu-devel] gcc auto-omit-frame-pointer vs msvc longjmp
2011/10/24 Bob Breuer breu...@mc.net: Kai Tietz wrote: Hi, For trunk-version I have a tentative patch for this issue. On 4.6.x and older branches this doesn't work, as here we can't differenciate that easy between ms- and sysv-abi. But could somebody give this patch a try? Regards, Kai ChangeLog * config/i386/i386.c (ix86_frame_pointer_required): Enforce use of frame-pointer for 32-bit ms-abi, if setjmp is used. Index: i386.c === --- i386.c (revision 180099) +++ i386.c (working copy) @@ -8391,6 +8391,10 @@ if (SUBTARGET_FRAME_POINTER_REQUIRED) return true; + /* For older 32-bit runtimes setjmp requires valid frame-pointer. */ + if (TARGET_32BIT_MS_ABI cfun-calls_setjmp) + return true; + /* In ix86_option_override_internal, TARGET_OMIT_LEAF_FRAME_POINTER turns off the frame pointer by default. Turn it back on now if we've not got a leaf function. */ For a gcc 4.7 snapshot, this does fix the longjmp problem that I encountered. So aside from specifying -fno-omit-frame-pointer for affected files, what can be done for 4.6? Bob Well, for 4.6.x (or older) we just can use the mingw32.h header in gcc/config/i386/ and define here a subtarget-macro to indicate that. The only incompatible point here might be for Wine using the linux-compiler to build Windows related code. A possible patch for 4.6 gcc versions I attached to this mail. Regards, Kai Index: mingw32.h === --- mingw32.h (revision 180393) +++ mingw32.h (working copy) @@ -239,3 +239,8 @@ /* We should find a way to not have to update this manually. */ #define LIBGCJ_SONAME libgcj /*LIBGCC_EH_EXTN*/ -12.dll +/* For 32-bit Windows we need valid frame-pointer for function using + setjmp. */ +#define SUBTARGET_SETJMP_NEED_FRAME_POINTER \ + (!TARGET_64BIT cfun-calls_setjmp) + Index: i386.c === --- i386.c (revision 180393) +++ i386.c (working copy) @@ -8741,6 +8741,12 @@ if (SUBTARGET_FRAME_POINTER_REQUIRED) return true; +#ifdef SUBTARGET_SETJMP_NEED_FRAME_POINTER + /* For older 32-bit runtimes setjmp requires valid frame-pointer. */ + if (SUBTARGET_SETJMP_NEED_FRAME_POINTER) +return true; +#endif + /* In ix86_option_override_internal, TARGET_OMIT_LEAF_FRAME_POINTER turns off the frame pointer by default. Turn it back on now if we've not got a leaf function. */
Re: [Qemu-devel] gcc auto-omit-frame-pointer vs msvc longjmp
2011/10/22 xunxun xunxun1...@gmail.com: 于 2011/10/22 13:13, xunxun 写道: Hi, all It seems that gcc's auto-omit-frame-pointer has other problems. The example is from mingw bug tracker: http://sourceforge.net/tracker/?func=detailaid=3426555group_id=2435atid=102435 g++ -O3 main.cpp running will crash. g++ -O2 main.cpp running no crash. g++ -O3 -fno-omit-frame-pointer running no crash. I don't know in the end which optimize option defaultly contains this switch -fomit-frame-pointer on i686-pc-mingw32 or x86_64-w64-mingw32? It crashes on Win7. Well, this issue isn't related to this thread. It is more related to dw2 and SjLj used. For toolchains using dw2 exception mechanism, you will see this crash. By using SjLj you won't (thanks for checking this). This shows indeed my strong concerns about dw2 exception mechanism for 32-bit Windows targets. The implementation depends too much on code-patterns and is therefore a bit inconsitant. Secondly it causes harm if you try to throw exceptions over VC generated code. So I would strongly recomment to use the slower, but more reliable SjLj throwing mechanism on Windows 32-bit. Regards, Kai
Re: [Qemu-devel] gcc auto-omit-frame-pointer vs msvc longjmp
2011/10/20 xunxun xunxun1...@gmail.com:
Hi, all
I think this issue causes the gdb crash on XP.
You can see the thread: http://sourceware.org/ml/gdb/2011-10/msg00056.html
My many friends and I can reproduce this crash issue, but no problem on Win7.
On Thu, Oct 20, 2011 at 5:05 AM, Bob Breuer breu...@mc.net wrote:
Kai Tietz wrote:
2011/10/18 Bob Breuer breu...@mc.net:
Kai Tietz wrote:
2011/10/17 Bob Breuer breu...@mc.net:
Richard Henderson wrote:
On 10/17/2011 07:09 AM, Bob Breuer wrote:
Google finds a mention of longjmp failing with -fomit-frame-pointer:
http://lua-users.org/lists/lua-l/2005-02/msg00158.html
Looks like gcc 4.6 turns on -fomit-frame-pointer by default.
Hmm. This is the first I've heard of a longjmp implementation
failing without a frame pointer. Presumably this is with the
mingw i.e. msvc libc?
Yeah, mingw from www.mingw.org which I believe uses msvcrt.dll, package
gcc-core-4.6.1-2-mingw32-bin.
This is something that could be worked around in gcc, I suppose.
We recognize longjmp for some things, we could force the use of
a frame pointer for msvc targets too.
For now it might be best to simply force -fno-omit-frame-pointer
for mingw host in the configure script.
Here's a testcase that crashes on the longjmp:
#include stdio.h
#include setjmp.h
jmp_buf env;
int test(void)
{
int i;
asm(xor %%ebp,%%ebp ::: ebp);
i = setjmp(env);
printf(i = %d\n, i);
if (i == 0)
longjmp(env, 2);
return i;
}
int main(void)
{
return test();
}
Remove the asm statement to make it not crash. Obviously with
omit-frame-pointer, gcc can shove anything into ebp.
Bob
This crash isn'r related to ebp existing, or not. The issue is the
hidden argument of setjmp, which is missing. If you can try the
following at top of file after include section.
#define setjmp(BUF) _setjmpex((BUF), NULL)
int __cdecl __attribute__ ((__nothrow__,__returns_twice__))
_setjmp3(jmp_buf _Buf, void *_Ctx);
...
Did you mean _setjmp3 instead of _setjmpex? With _setjmp3, it works
without the asm, but still crashes if I zero out ebp before the setjmp.
Aren't the function arguments on the stack anyway?
Yes, I mean _setjmp3 (pasto from headers and missed the second line
prototyping _setjmp3).
I repeat myself here. setjmp() has an hidden arguement, which is
passed on x86 on stack. By not passing this required argument, setjmp
will take a random-value from stack. In your case 'i'. btw if you
would pre-initialize 'i' with zero, I would assume you won't see a
crash, but anyway this is just by chance.
For this I suggest to use here _setjmp3 instead, as here
second-argument is documented as being present.
Btw I tested your code with i686-pc-mingw32 version 4.6.x and 4.7.x
gcc version. With my suggested pattern, I don't see a crash for your
provide test-code with, or without zero-ing ebp.
We probably have a difference in build or run environment. I've
double-checked with another machine and can get the same crash in
longjmp when running the test executable on both WinXP and Win2k, but
not on Win7. So it looks like Microsoft may have changed this feature
somewhere between WinXP and Win7.
The msvcrt implementation of longjmp (or at least the one I'm looking
at) does a ebp based access using the saved value of ebp. Here's the
relevant disassembly of longjmp:
0x7801e6f3 in longjmpex () from C:\WINNT\system32\msvcrt.dll
(gdb) disas
Dump of assembler code for function longjmpex:
0x7801e6ef +0: mov 0x4(%esp),%ebx
= 0x7801e6f3 +4: mov (%ebx),%ebp
...
0x7801e73d +78: call 0x7800bd5e abnormal_termination+56
...
0x7800bd5e +56: push %ebx
0x7800bd5f +57: push %ecx
0x7800bd60 +58: mov $0x7803dc64,%ebx
= 0x7800bd65 +63: mov 0x8(%ebp),%ecx
It crashes on the access of 0x8(%ebp). Those are the only 2 places
where this version of longjmp touches ebp. Is it possible to force a
stackframe by just adding a suitable attribute to either the setjmp
function prototype, or the function which calls setjmp?
Bob
--
Best Regards,
xunxun
This now makes sense. I use here Vista 64-bit, and Win7 64-bit and I
didn't found the issue. But well, it is indeed related to different
msvcrt-version.
So there might be some need to have for a function using setjmp the
frame-pointer enabled. I can confirm this by an older msvcrt.dll
version on my 64-bit box, too.
So bug can be re-opened.
Thanks,
Kai
Re: [Qemu-devel] gcc auto-omit-frame-pointer vs msvc longjmp
Hi, For trunk-version I have a tentative patch for this issue. On 4.6.x and older branches this doesn't work, as here we can't differenciate that easy between ms- and sysv-abi. But could somebody give this patch a try? Regards, Kai ChangeLog * config/i386/i386.c (ix86_frame_pointer_required): Enforce use of frame-pointer for 32-bit ms-abi, if setjmp is used. Index: i386.c === --- i386.c (revision 180099) +++ i386.c (working copy) @@ -8391,6 +8391,10 @@ if (SUBTARGET_FRAME_POINTER_REQUIRED) return true; + /* For older 32-bit runtimes setjmp requires valid frame-pointer. */ + if (TARGET_32BIT_MS_ABI cfun-calls_setjmp) +return true; + /* In ix86_option_override_internal, TARGET_OMIT_LEAF_FRAME_POINTER turns off the frame pointer by default. Turn it back on now if we've not got a leaf function. */
Re: [Qemu-devel] gcc auto-omit-frame-pointer vs msvc longjmp
2011/10/17 Bob Breuer breu...@mc.net:
Richard Henderson wrote:
On 10/17/2011 07:09 AM, Bob Breuer wrote:
I don't think this is a free/g_free issue. If I use the following
patch, then I at least get the openbios messages:
diff --git a/cpu-exec.c b/cpu-exec.c
index a9fa608..dfbd6ea 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -180,6 +180,7 @@ static void cpu_handle_debug_exception(CPUState
/* main execution loop */
volatile sig_atomic_t exit_request;
+register void *ebp asm(ebp);
int cpu_exec(CPUState *env)
{
@@ -233,6 +234,8 @@ int cpu_exec(CPUState *env)
/* prepare setjmp context for exception handling */
for(;;) {
+ int dummy = 0;
+ ebp = dummy;
See if
asm( : : : ebp);
also solves the problem.
No, that doesn't fix it.
Google finds a mention of longjmp failing with -fomit-frame-pointer:
http://lua-users.org/lists/lua-l/2005-02/msg00158.html
Looks like gcc 4.6 turns on -fomit-frame-pointer by default.
Hmm. This is the first I've heard of a longjmp implementation
failing without a frame pointer. Presumably this is with the
mingw i.e. msvc libc?
Yeah, mingw from www.mingw.org which I believe uses msvcrt.dll, package
gcc-core-4.6.1-2-mingw32-bin.
This is something that could be worked around in gcc, I suppose.
We recognize longjmp for some things, we could force the use of
a frame pointer for msvc targets too.
For now it might be best to simply force -fno-omit-frame-pointer
for mingw host in the configure script.
Here's a testcase that crashes on the longjmp:
#include stdio.h
#include setjmp.h
jmp_buf env;
int test(void)
{
int i;
asm(xor %%ebp,%%ebp ::: ebp);
i = setjmp(env);
printf(i = %d\n, i);
if (i == 0)
longjmp(env, 2);
return i;
}
int main(void)
{
return test();
}
Remove the asm statement to make it not crash. Obviously with
omit-frame-pointer, gcc can shove anything into ebp.
Bob
This crash isn'r related to ebp existing, or not. The issue is the
hidden argument of setjmp, which is missing. If you can try the
following at top of file after include section.
#define setjmp(BUF) _setjmpex((BUF), NULL)
int __cdecl __attribute__ ((__nothrow__,__returns_twice__))
_setjmp3(jmp_buf _Buf, void *_Ctx);
...
This will work as expected with or without omit-frame-pointer.
The issue is that setjmp has a second (undocumented as usual)
argument, which has a meaning.
Regards,
Kai
PS: _setjmp3 is an export from msvcrt.dll. So if symbol is missing
on link, simply specify msvcrt.dll as argument to link-line.
Re: [Qemu-devel] gcc auto-omit-frame-pointer vs msvc longjmp
2011/10/18 Bob Breuer breu...@mc.net:
Kai Tietz wrote:
2011/10/17 Bob Breuer breu...@mc.net:
Richard Henderson wrote:
On 10/17/2011 07:09 AM, Bob Breuer wrote:
I don't think this is a free/g_free issue. If I use the following
patch, then I at least get the openbios messages:
diff --git a/cpu-exec.c b/cpu-exec.c
index a9fa608..dfbd6ea 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -180,6 +180,7 @@ static void cpu_handle_debug_exception(CPUState
/* main execution loop */
volatile sig_atomic_t exit_request;
+register void *ebp asm(ebp);
int cpu_exec(CPUState *env)
{
@@ -233,6 +234,8 @@ int cpu_exec(CPUState *env)
/* prepare setjmp context for exception handling */
for(;;) {
+ int dummy = 0;
+ ebp = dummy;
See if
asm( : : : ebp);
also solves the problem.
No, that doesn't fix it.
Google finds a mention of longjmp failing with -fomit-frame-pointer:
http://lua-users.org/lists/lua-l/2005-02/msg00158.html
Looks like gcc 4.6 turns on -fomit-frame-pointer by default.
Hmm. This is the first I've heard of a longjmp implementation
failing without a frame pointer. Presumably this is with the
mingw i.e. msvc libc?
Yeah, mingw from www.mingw.org which I believe uses msvcrt.dll, package
gcc-core-4.6.1-2-mingw32-bin.
This is something that could be worked around in gcc, I suppose.
We recognize longjmp for some things, we could force the use of
a frame pointer for msvc targets too.
For now it might be best to simply force -fno-omit-frame-pointer
for mingw host in the configure script.
Here's a testcase that crashes on the longjmp:
#include stdio.h
#include setjmp.h
jmp_buf env;
int test(void)
{
int i;
asm(xor %%ebp,%%ebp ::: ebp);
i = setjmp(env);
printf(i = %d\n, i);
if (i == 0)
longjmp(env, 2);
return i;
}
int main(void)
{
return test();
}
Remove the asm statement to make it not crash. Obviously with
omit-frame-pointer, gcc can shove anything into ebp.
Bob
This crash isn'r related to ebp existing, or not. The issue is the
hidden argument of setjmp, which is missing. If you can try the
following at top of file after include section.
#define setjmp(BUF) _setjmpex((BUF), NULL)
int __cdecl __attribute__ ((__nothrow__,__returns_twice__))
_setjmp3(jmp_buf _Buf, void *_Ctx);
...
Did you mean _setjmp3 instead of _setjmpex? With _setjmp3, it works
without the asm, but still crashes if I zero out ebp before the setjmp.
Aren't the function arguments on the stack anyway?
Yes, I mean _setjmp3 (pasto from headers and missed the second line
prototyping _setjmp3).
I repeat myself here. setjmp() has an hidden arguement, which is
passed on x86 on stack. By not passing this required argument, setjmp
will take a random-value from stack. In your case 'i'. btw if you
would pre-initialize 'i' with zero, I would assume you won't see a
crash, but anyway this is just by chance.
For this I suggest to use here _setjmp3 instead, as here
second-argument is documented as being present.
Btw I tested your code with i686-pc-mingw32 version 4.6.x and 4.7.x
gcc version. With my suggested pattern, I don't see a crash for your
provide test-code with, or without zero-ing ebp.
Kai
