On 09/03/2017 19:48, Herbie Robinson wrote:
> Fix Bug #1670509: wrong video attrs for int 10h, ah==13h
> The subroutine set_cursor_position is trashing %bx.
> Unfortunately, %bl contains the video attribute for write_string.
>
> The fix saves %bx in the function prolog and restores it in
> the epi
---
hw/ppc/pnv.c | 1 +
target/alpha/translate.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index 09f0d22def..3fa722af82 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -21,6 +21,7 @@
#include "qapi/error.h"
#include "sysemu/sysemu.h"
#include
From: Alex Bennée
It's a silly little limitation on Shippable that is looks for clang
in the container even though we won't use it. The arm/aarch64 cross
builds inherit this from debian.docker but as we needed to use
debian-testing for this we add it here. We also collapse the update
step into on
From: Philippe Mathieu-Daudé
if ftp_proxy/http_proxy/https_proxy standard environment variables available,
pass them to the docker daemon to build images.
this is required when building behind corporate proxy/firewall, but also help
when using local cache server (ie: apt/yum).
Signed-off-by: Phi
The following changes since commit eba44e9339fc13c36e24c8c59e2b73ea231b46a1:
Merge remote-tracking branch 'remotes/jasowang/tags/net-pull-request' into
staging (2017-03-06 15:13:23 +)
are available in the git repository at:
git://github.com/famz/qemu.git tags/docker-pull-request
for yo
There is no need to delete subregion and do memory begin/commit for
subpage in memory_region_finalize().
This patch is from Anthony Xu .
Signed-off-by: Yang Zhong
---
memory.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/memory.c b/memory.c
index 284894b..3e
There are a lot of memory allocation during the qemu bootup, which are
freed later by RCU thread,which means the heap size becomes biger and
biger when allocation happens, but the heap may not be shrinked even
after release happens,because some memory blocks in top of heap are still
being used.Decr
On Wed, Mar 08, 2017 at 10:25:41AM +0100, Gerd Hoffmann wrote:
> > Current QEMU should have no restriction on parameter ordering, right?
> > Or do we have any existing case that:
> >
> > "$QEMU -parameter1 -parameter2"
> >
> > will work, while...
> >
> > "$QEMU -parameter2 -parameter1"
> >
Since cpu-memory and memory have same address space,one malloced
memory is enough. This patch will skip memory malloc for memory
address space,which will reduce around 3M physical memory in heap.
Signed-off-by: Yang Zhong
---
memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -
Hi All,
This patch is to fix the failed iotests case 68 and 91 and has been
tested. It's based on commit dd4d2578215 "Merge remote-tracking branch
'remotes/kraxel/tags/pull-fixes-20170309-1' into staging" and according
to Halil and Dave's comments. Also thanks for F
This problem affects s390x only if we are running without KVM.
Basically, S390CPU.irqstate is unused if we do not use KVM,
and thus no buffer is allocated.
This causes size=0, first_elem=NULL and n_elems=1 in
vmstate_load_state and vmstate_save_state. And the assert fails.
With this fix we can go b
On Fri, Mar 03, 2017 at 11:56:54PM +0200, Nir Soffer wrote:
> On Fri, Mar 3, 2017 at 3:51 PM, Stefan Hajnoczi wrote:
> > +ret_size = bdrv_max_size(drv, opts, in_blk ? blk_bs(in_blk) : NULL,
> > + &local_err);
> > +if (local_err) {
> > +error_report_err(l
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/887883
Title:
Coverity sca
On Tue, Mar 07, 2017 at 11:32:29AM +0100, Alberto Garcia wrote:
> On Fri 03 Mar 2017 02:51:48 PM CET, Stefan Hajnoczi wrote:
>
> > +static uint64_t raw_max_size(QemuOpts *opts, BlockDriverState *in_bs,
> > + Error **errp)
> > +{
> > +if (in_bs) {
> > +int64_
On Fri, Mar 03, 2017 at 11:32:55AM +, Daniel P. Berrange wrote:
> When using a memory-backend object with prealloc turned on, QEMU
> will memset() the first byte in every memory page to zero. While
> this might have been acceptable for memory backends associated
> with RAM, this corrupts applic
On Fri, Mar 03, 2017 at 11:32:55AM +, Daniel P. Berrange wrote:
> When using a memory-backend object with prealloc turned on, QEMU
> will memset() the first byte in every memory page to zero. While
> this might have been acceptable for memory backends associated
> with RAM, this corrupts applic
On Tue, Mar 07, 2017 at 10:30:30PM +0800, Hailiang Zhang wrote:
> Hi Stefan,
>
> Sorry for the delayed reply.
>
> On 2017/2/28 1:37, Stefan Hajnoczi wrote:
> > On Fri, Jan 20, 2017 at 11:47:59AM +0800, zhanghailiang wrote:
> > > Just as the scenario of non-shared disk block replication,
> > > we
Trying to get memory region size of an uninitialized memory region is
probably not a good idea. Let's just do the alloc no matter what.
Signed-off-by: Peter Xu
---
backends/hostmem-file.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/backends/hostmem-file
[adding Stefan in cc, as trace maintainer]
On 03/09/2017 09:15 PM, Eric Blake wrote:
Perhaps I should update the subject to mention trace?
> trace-events lists the parameters for mirror_yield consistently
> with other events (cnt just after s, like in mirror_before_sleep;
> in_flight last, like
trace-events lists the parameters for mirror_yield consistently
with other events (cnt just after s, like in mirror_before_sleep;
in_flight last, like in mirror_yield_in_flight). But the callers
were passing parameters in the wrong order, leading to poor trace
messages, including type truncation w
On Fri, Mar 10, 2017 at 12:41:13PM +1100, Alexey Kardashevskiy wrote:
> KVM_CAP_SPAPR_TCE capability allows creating TCE tables in KVM which
> allows having in-kernel acceleration for H_PUT_TCE_xxx hypercalls.
> However it only supports 32bit DMA windows at zero bus offset.
>
> There is a new KVM_
Public bug reported:
I'm running into a weird issue with the vfio-pci driver through qemu
I use it on a laptop and I passthrough an external GPU connected via PCI
express. In general this works well, however if the laptop has *ever*
suspended since its last boot, then the windows guest reports a
On Thu, Mar 09, 2017 at 01:28:09PM +0100, Paolo Bonzini wrote:
>
>
> On 09/03/2017 13:11, Marcel Apfelbaum wrote:
> > On 03/09/2017 01:13 PM, Paolo Bonzini wrote:
> >>
> >>
> >> On 09/03/2017 00:59, Michael S. Tsirkin wrote:
> >>> Allow forcing a specific order of initialization on
> >>> devices
KVM_CAP_SPAPR_TCE capability allows creating TCE tables in KVM which
allows having in-kernel acceleration for H_PUT_TCE_xxx hypercalls.
However it only supports 32bit DMA windows at zero bus offset.
There is a new KVM_CAP_SPAPR_TCE_64 capability which supports 64bit
window size, variable page size
Hi all,
Inspired by SimBench[1], I have written a set of scripts ("DBT-bench")
to easily obtain and plot performance numbers for linux-user.
The (Perl) scripts are available here:
https://github.com/cota/dbt-bench
[ It's better to clone with --recursive because the benchmarks
(NBench) are pulle
We've now implemented a PAPR extension allowing PAPR guest to resize
their hash page table (HPT) during runtime.
This patch makes use of that facility to allocate smaller HPTs by default.
Specifically when a guest is aware of the HPT resize facility, qemu sizes
the HPT to the initial memory size,
We've now implemented a PAPR extensions which allows PAPR guests (i.e.
"pseries" machine type) to resize their hash page table during runtime.
However, that extension is only enabled if explicitly chosen on the
command line. This patch enables it by default for spapr-2.10, but leaves
it disabled
On Thu, Mar 09, 2017 at 07:37:53PM +0100, Thomas Huth wrote:
> The devices that are derived from TYPE_PNV_CHIP currently show up
> as "uncategorized" devices in the help text of "-device ?". Since
> they obviously are related to the CPU, let's put them into the
> CPU category instead.
>
> Signed-o
On Fri, Mar 10, 2017 at 12:13:28PM +1100, David Gibson wrote:
> So far, qemu implements the PAPR Hash Page Table (HPT) resizing extension
> with TCG. The same implementation will work with KVM PR, but we don't
> currently allow that. For KVM HV we can only implement resizing with the
> assistance
So far, qemu implements the PAPR Hash Page Table (HPT) resizing extension
with TCG. The same implementation will work with KVM PR, but we don't
currently allow that. For KVM HV we can only implement resizing with the
assistance of the host kernel, which needs a new capability and ioctl()s.
This
This introduces stub implementations of the H_RESIZE_HPT_PREPARE and
H_RESIZE_HPT_COMMIT hypercalls which we hope to add in a PAPR
extension to allow run time resizing of a guest's hash page table. It
also adds a new machine property for controlling whether this new
facility is available.
For now
These patches implementa PAPR extension to allow 'pseries' machine
type guests to resize their hashed page table (HPT). This allows for
more flexible memory hotplug, because we don't need to size the
initial HPT for the maximum memory size. That's particularly valuable
with (HV) KVM, since the HP
This patch implements hypercalls allowing a PAPR guest to resize its own
hash page table. This will eventually allow for more flexible memory
hotplug.
The implementation is partially asynchronous, handled in a special thread
running the hpt_prepare_thread() function. The state of a pending resiz
在 2017/3/9 19:45, Halil Pasic 写道:
On 03/09/2017 03:55 AM, QingFeng Hao wrote:
在 2017/3/8 19:33, Halil Pasic 写道:
On 03/08/2017 08:05 AM, QingFeng Hao wrote:
在 2017/3/7 18:19, Halil Pasic 写道:
On 03/07/2017 11:05 AM, Kevin Wolf wrote:
Am 07.03.2017 um 10:54 hat Halil Pasic geschrieben:
On
On Wed, Mar 08, 2017 at 03:48:49PM +1100, Alexey Kardashevskiy wrote:
> Ping? It is not urgent, just wanted to make sure that it is not forgotten
> and I do not need to do anything to update it. Thanks.
Ah.. sorry, I lost track of this one (and confused it with the kernel
series for VFIO accelerat
On Thu, Mar 09, 2017 at 07:43:07AM +0100, Peter Maydell wrote:
> On 9 March 2017 at 02:31, David Gibson wrote:
> > Yes. I've now fixed this in upstream libfdt, at Paolo's suggestion.
> > Unfortunately, it came just after the 1.4.3 release. I was just leery
> > about making a new release and qemu
Still happened in qemu 2.5.0 on Ubuntu 16.04, it's random but you can
only switch between console, monitor, serial, parallel several times,
then it hangs.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs
Will the fix be backported? Right now, this is a regression in xenial
(caused by the security update in 1:2.5+dfsg-5ubuntu10.6).
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1581936
Title:
Frozen
Fix Bug #1670509: wrong video attrs for int 10h, ah==13h
The subroutine set_cursor_position is trashing %bx.
Unfortunately, %bl contains the video attribute for write_string.
The fix saves %bx in the function prolog and restores it in
the epilog. Also, remove save and restore in set_current_curso
Le 09/03/2017 à 09:38, Gerd Hoffmann a écrit :
Add two new registers to the qemu extended register range, carrying the
suggested width and height of the display device. In case the xres and
yres properties are set, fill these new registers accordingly.
Additionally guest driver updates are need
On Thu, Mar 09, 2017 at 08:08:00PM +, Dr. David Alan Gilbert wrote:
> * Eduardo Habkost (ehabk...@redhat.com) wrote:
> > When a KVM_{GET,SET}_MSRS ioctl() fails, it is difficult to find
> > out which MSR caused the problem. Print an error message for
> > debugging, before we trigger the (ret ==
* Eduardo Habkost (ehabk...@redhat.com) wrote:
> When a KVM_{GET,SET}_MSRS ioctl() fails, it is difficult to find
> out which MSR caused the problem. Print an error message for
> debugging, before we trigger the (ret == cpu->kvm_msr_buf->nmsrs)
> assert.
>
> Suggested-by: Dr. David Alan Gilbert
>
When a KVM_{GET,SET}_MSRS ioctl() fails, it is difficult to find
out which MSR caused the problem. Print an error message for
debugging, before we trigger the (ret == cpu->kvm_msr_buf->nmsrs)
assert.
Suggested-by: Dr. David Alan Gilbert
Signed-off-by: Eduardo Habkost
---
Changes v1 -> v2:
* Prin
On Thu, Mar 09, 2017 at 07:34:15PM +, Dr. David Alan Gilbert wrote:
> * Eduardo Habkost (ehabk...@redhat.com) wrote:
> > When a KVM_SET_MSRS ioctl() fails, it is difficult to find out
> > which MSR caused the problem. Print an error message for
> > debugging, before we trigger the (ret == cpu->
On 09.03.2017 13:42, Paolo Bonzini wrote:
> On 05/03/2017 19:21, Alexander Boettcher wrote:
>> the SVM I/O permission bitmap for user-level (ring-3) VM code running in
>> SVM seems to be ignored and causes a GP-fault. (Actual the IO permission
>> was granted by the kernel via the TSS I/O port permi
* Eduardo Habkost (ehabk...@redhat.com) wrote:
> When a KVM_SET_MSRS ioctl() fails, it is difficult to find out
> which MSR caused the problem. Print an error message for
> debugging, before we trigger the (ret == cpu->kvm_msr_buf->nmsrs)
> assert.
>
> Signed-off-by: Eduardo Habkost
> ---
> targ
When a KVM_SET_MSRS ioctl() fails, it is difficult to find out
which MSR caused the problem. Print an error message for
debugging, before we trigger the (ret == cpu->kvm_msr_buf->nmsrs)
assert.
Signed-off-by: Eduardo Habkost
---
target/i386/kvm.c | 6 ++
1 file changed, 6 insertions(+)
diff
I believe this is fixed in the qemu git mainline (but not yet in any release)
by the following commits:
commit c52ab08aee6f7d4717fc6b517174043126bd302f
Author: Doug Evans
Date: Tue Dec 6 23:06:30 2016 +
target-i386: Fix eflags.TF/#DB handling of syscall/sysret insns
The sysca
Hi,
This series failed automatic build test. Please find the testing commands and
their output below. If you have docker installed, you can probably reproduce it
locally.
Type: series
Subject: [Qemu-devel] [PATCH] xen: don't save/restore the physmap on VM
save/restore
Message-id: 1489084689-1900
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Subject: [Qemu-devel] [PATCH] xen: don't save/restore the physmap on VM
save/restore
Message-id: 1489084689-19008-1-git-send-email-igor.druzhi...@citrix.com
=== TEST SCRIPT BEGIN ===
#!
Saving/restoring the physmap to/from xenstore was introduced to
QEMU majorly in order to cover up the VRAM region restore issue.
The sequence of restore operations implies that we should know
the effective guest VRAM address *before* we have the VRAM region
restored (which happens later). Unfortuna
s/armbru/tags/pull-block-2017-02-28-v4'
> into staging (2017-03-07 17:06:48 +)
>
> are available in the git repository at:
>
>
> git://git.kraxel.org/qemu tags/pull-fixes-20170309-1
>
> for you to fetch changes up to dbb5fb8d3519130559b10fa4e1395e4486c633f8:
>
Most machines don't allow sysbus devices like "kvmclock" to be
created from the command-line, but some of them do (the ones with
has_dynamic_sysbus=true). In those cases, it's possible to
manually create a kvmclock device without KVM being enabled,
making QEMU crash:
$ qemu-system-x86_64 -machin
v2:
- applied code review
This patchset include initial support to PPC64 (Big-Endian), that is pretty
much the same: only some fixes in configure and risugen.
Also, it adds a better random initialization of VSX registers.
Jose Ricardo Ziviani (3):
risugen_ppc64: Load random 128-bit data to VS
This commit adds an option to risugen in order to give the opportunity
to generated big-endian instructions. By passing --be, users force
risugen to generated big-endian instructions for ppc64.
./risugen --be --numinsns 1000 --pattern "ADD" ppc64.risu test.bin
./risugen --numinsns 1000 --pattern "
This commit set Makefile to point to ppc64le source for both archs
(ppc64 and ppc64le) because they do the exact same thing. The
difference is in risugen and how the binary is build.
Signed-off-by: Jose Ricardo Ziviani
---
configure | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
Signed-off-by: Jose Ricardo Ziviani
---
risugen_ppc64.pm | 40 +---
1 file changed, 29 insertions(+), 11 deletions(-)
diff --git a/risugen_ppc64.pm b/risugen_ppc64.pm
index 341478c..45f7220 100644
--- a/risugen_ppc64.pm
+++ b/risugen_ppc64.pm
@@ -99,6 +99,29 @
The devices that are derived from TYPE_PNV_CHIP currently show up
as "uncategorized" devices in the help text of "-device ?". Since
they obviously are related to the CPU, let's put them into the
CPU category instead.
Signed-off-by: Thomas Huth
---
hw/ppc/pnv.c | 1 +
1 file changed, 1 insertion(
(This missed hard freeze, but I would still like to include the
warning in 2.9 so we can remove the default config file in 2.10.
I will include this series in a pull request only if at least 2
other maintainers send their Acked-by.)
We plan to remove support for /etc/qemu/qemu.conf in the near
fut
In case there were options set in the default config file, print
a warning so users can update their scripts.
If somebody wants to keep the config file as-is, avoid the
warning and use a command-line that will work in future QEMU
versions, they can use:
$QEMU -nodefconfig -readconfig /etc/qemu/q
Change qemu_config_parse() to return the number of config groups
in success and -EINVAL on error. This will allow callers of
qemu_config_parse() to check if something was really loaded from
the config file.
All existing callers of qemu_config_parse() and
qemu_read_config_file() only check if the r
glibc blacklists TSX on Haswell CPUs with model==60 and
stepping < 4. To make the Haswell CPU model more useful, make
those guests actually use TSX by changing CPU stepping to 4.
References:
* glibc commit 2702856bf45c82cf8e69f2064f5aa15c0ceb6359
https://sourceware.org/git/?p=glibc.git;a=commit
Some Intel CPUs are known to have a broken TSX implementation. A
microcode update from Intel disabled TSX on those CPUs, but
GET_SUPPORTED_CPUID might be reporting it as supported if the
hosts were not updated yet.
Manually fixup the GET_SUPPORTED_CPUID data to ensure we will
never enable TSX when
Helper function for code that needs to check the host CPU
vendor/family/model/stepping values.
Signed-off-by: Eduardo Habkost
---
Changes v2 -> v3:
* Don't touch max_x86_cpu_initfn() to reduce risk post
hard freeze
Changes v1 -> v2:
* Coding style fix (split long lines)
---
target/i386/cpu.h
I plan to merge this bug fix into 2.9.
Changes v2 -> v3:
* Rebase to latest master
* Don't touch max_x86_cpu_initfn() to reduce risk post
hard freeze
Changes v1 -> v2:
* Coding style fixes
* Make series simpler:
* Don't use trick: char vendor[static (CPUID_VENDOR_SZ + 1)]
because it confu
On 09.03.2017 18:27, Eduardo Habkost wrote:
> On Thu, Mar 09, 2017 at 05:32:08PM +0100, Paolo Bonzini wrote:
>>
>>
>> On 08/03/2017 19:44, Eduardo Habkost wrote:
> If it's only supported by x86, I would just move the
> implementation to a x86-specific file, and add a stub for the
> othe
On Mon, 6 Mar 2017 18:12:43 -0800
Stefano Stabellini wrote:
> Introduce the Xen 9pfs backend: add struct XenDevOps to register as a
> Xen backend and add struct V9fsTransport to register as v9fs transport.
>
> All functions are empty stubs for now.
>
> Signed-off-by: Stefano Stabellini
> CC:
On Mon, 6 Mar 2017 18:12:48 -0800
Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini
> CC: anthony.per...@citrix.com
> CC: jgr...@suse.com
> CC: Aneesh Kumar K.V
> CC: Greg Kurz
> ---
> hw/9pfs/Makefile.objs| 1 +
> hw/xen/xen_backend.c | 1 +
> include/hw/xen/xen_
* Christian Pinto (c.pi...@virtualopensystems.com) wrote:
> This patch series introduces a set of fixes to the previous work proposed by
> Hailiang Zhang to enable in QEMU live memory snapshot based
> on userfaultfd. See discussion here:
> http://www.mail-archive.com/qemu-devel@nongnu.org/msg393118
Am 09.03.2017 um 15:23 hat Eric Blake geschrieben:
> On 03/09/2017 05:38 AM, Kevin Wolf wrote:
> > Kevin Wolf (6):
> > block: Remove check_new_perm from bdrv_replace_child()
> > block: Request block status from *file for BDRV_BLOCK_RAW
> > commit: Implement bdrv_commit_top.bdrv_co_get_block_s
On 07/03/2017 02:30, herbierobinson wrote:
> Fix Bug #1670509: wrong video attrs for int 10h, ah==13h
> The subroutine set_cursor_position is trashing %bx.
> Unfortunately, %bl contains the video attribute for write_string.
>
> The fix saves %bx in the function prolog and restores it in
> the epil
On Thu, Mar 09, 2017 at 05:32:08PM +0100, Paolo Bonzini wrote:
>
>
> On 08/03/2017 19:44, Eduardo Habkost wrote:
> >>> If it's only supported by x86, I would just move the
> >>> implementation to a x86-specific file, and add a stub for the
> >>> other architectures. See qmp_query_gic_capabilities
On 09/03/2017 18:19, Alex Bennée wrote:
>
> Hmm your subject line was:
>
> Subject: [PATCH 0/6] tcg: fix icount super slowdown
>
> But:
>
>> Paolo Bonzini (5):
>> qemu-timer: fix off-by-one
>> qemu-timer: do not include sysemu/cpus.h from util/qemu-timer.h
>> cpus: define QEMUTimerLis
Paolo Bonzini writes:
Hmm your subject line was:
Subject: [PATCH 0/6] tcg: fix icount super slowdown
But:
> Paolo Bonzini (5):
> qemu-timer: fix off-by-one
> qemu-timer: do not include sysemu/cpus.h from util/qemu-timer.h
> cpus: define QEMUTimerListNotifyCB for QEMU system emulation
On 09/03/2017 18:06, Dr. David Alan Gilbert wrote:
> (cc'ing in Paolo since he knows our barrier code)
>
> * FENG, Jiasheng (nikof...@connect.hku.hk) wrote:
>> Dear David,
>>
>> Really appreciate your feedback.
>>
>> I have proceeded the experiments in both conditions, and no matter the
>> vCPUs
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Subject: [Qemu-devel] [PATCH] hw/arm/boot: take Linux/arm64 TEXT_OFFSET header
field into account
Message-id: 1489079383-11162-1-git-send-email-ard.biesheu...@linaro.org
=== TEST SCRIPT
Fix Bug #1670509: wrong video attrs for int 10h, ah==13h
The subroutine set_cursor_position is trashing %bx.
Unfortunately, %bl contains the video attribute for write_string.
The fix saves %bx in the function prolog and restores it in
the epilog. Also, remove save and restore in set_current_curso
Dear David,
Yes, it is a normal x86 PC server.
Thanks so much for your help and hope to receive your following feedback.
Best Regards,
Niko Jiasheng Feng
Sent from Mail for Windows 10
From: Dr. David Alan Gilbert
Sent: Friday, March 10, 2017 1:06 AM
To: FENG, Jiasheng
Cc: qemu-devel@nongnu.org
The arm64 boot protocol stipulates that the kernel must be loaded
TEXT_OFFSET bytes beyond a 2 MB aligned base address, where TEXT_OFFSET
could be any 4 KB multiple between 0 and 2 MB, and whose value can be
found in the header of the Image file.
So after attempts to load the kernel image as an EL
(cc'ing in Paolo since he knows our barrier code)
* FENG, Jiasheng (nikof...@connect.hku.hk) wrote:
> Dear David,
>
> Really appreciate your feedback.
>
> I have proceeded the experiments in both conditions, and no matter the
> vCPUs are in idle or busy situation, there is no difference that smp
On 03/09/2017 05:06 PM, Dr. David Alan Gilbert wrote:
> * Halil Pasic (pa...@linux.vnet.ibm.com) wrote:
>>
>>
>> On 03/09/2017 02:22 PM, Dr. David Alan Gilbert (git) wrote:
>>> From: "Dr. David Alan Gilbert"
>>>
>>> Postcopy doesn't support migration of RAM shared with another process
>>> yet (w
oussema ben khedher writes:
> hi
>
> i search the pc of tb in the guest code i used the function
> cpu_restore_state_from_tb in cpu_exec_tb but the searching pc take 0
> value can someone explain me why searching_pc is 0 or give me some
> hints
Have you got a backtrace of how you got there?
--
On 07/03/2017 15:19, Christian Borntraeger wrote:
> I sometimes got "Cannot access memory" when using the x command
> on the monitor. Turns out that the cpu env did contain stale data
> (e.g. wrong control register content for page table origin).
> We must synchronize the state of the CPU before
Dear David,
Really appreciate your feedback.
I have proceeded the experiments in both conditions, and no matter the
vCPUs are in idle or busy situation, there is no difference that smp_wmb()
will consume a lot of time to proceed its work.
In your opinion, may I know that what is the alternative
* Paolo Bonzini (pbonz...@redhat.com) wrote:
>
>
> On 09/03/2017 17:13, Dr. David Alan Gilbert wrote:
> >>> + * @name: Region name, becomes part of RAMBlock name used in migration
> >>> stream
> >>> + *must be unique within any device
> >>> * @size: size of the region; any subregions b
On 08/03/2017 12:17, Philippe Mathieu-Daudé wrote:
> On 03/08/2017 12:11 PM, Yang Zhong wrote:
>> Since cpu-memory and memory have same address space,one malloced
>> memory is enough. This patch will skip memory malloc for memory
>> address space,which will reduce around 3M physical memory in hea
On 08/03/2017 19:44, Eduardo Habkost wrote:
>>> If it's only supported by x86, I would just move the
>>> implementation to a x86-specific file, and add a stub for the
>>> other architectures. See qmp_query_gic_capabilities() for an
>>> example.
>>>
>>> Also, the command should be added to
>>> qmp
On 09/03/2017 17:13, Dr. David Alan Gilbert wrote:
>>> + * @name: Region name, becomes part of RAMBlock name used in migration
>>> stream
>>> + *must be unique within any device
>>> * @size: size of the region; any subregions beyond this size will be
>>> clipped
>>> */
>>> void mem
* Paolo Bonzini (pbonz...@redhat.com) wrote:
>
>
> On 09/03/2017 16:27, Dr. David Alan Gilbert (git) wrote:
> > + * @name: Region name, becomes part of RAMBlock name used in migration
> > stream
> > + *must be unique within any device
> > * @size: size of the region; any subregions bey
On 09/03/2017 16:27, Dr. David Alan Gilbert (git) wrote:
> + * @name: Region name, becomes part of RAMBlock name used in migration stream
> + *must be unique within any device
> * @size: size of the region; any subregions beyond this size will be clipped
> */
> void memory_region_ini
* Halil Pasic (pa...@linux.vnet.ibm.com) wrote:
>
>
> On 03/09/2017 02:22 PM, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > Postcopy doesn't support migration of RAM shared with another process
> > yet (we've got a bunch of things to understand).
> > Check for t
On 03/09/2017 02:22 PM, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> Postcopy doesn't support migration of RAM shared with another process
> yet (we've got a bunch of things to understand).
> Check for the case and don't allow postcopy to be enabled.
>
> Signed-off-
Am 08.03.2017 um 09:26 hat Thomas Huth geschrieben:
> what will be the next version of QEMU after 2.9? Will we go for a 2.10
> (as I've seen it mentioned a couple of times on the mailing list
> already), or do we dare to switch to 3.0 instead?
>
> I personally dislike two-digit minor version numbe
hi
i search the pc of tb in the guest code i used the function
cpu_restore_state_from_tb in cpu_exec_tb but the searching pc take 0 value can
someone explain me why searching_pc is 0 or give me some hints
thanks
Am 08.03.2017 um 22:34 hat Eric Blake geschrieben:
> bdrv_is_allocated() returns tri-state, not just bool, although
> there were several callers using it as a bool. Fix them to
> either propagate the error or to document why treatment of
> failure like allocation is okay.
>
> [Found during a larg
On 09/03/2017 16:31, Michael S. Tsirkin wrote:
> On Thu, Mar 09, 2017 at 11:05:36AM +0100, Paolo Bonzini wrote:
>>
>>
>> On 09/03/2017 10:58, Jason Wang wrote:
>>>
>>>
>>> On 2017年03月09日 17:28, Igor Mammedov wrote:
On Thu, 9 Mar 2017 10:32:44 +0800
Jason Wang wrote:
> On 2017年
On 09/03/2017 16:29, Michael S. Tsirkin wrote:
>> If VFIO had an iommu property, to be used like "-device
>> intel_iommu,id=iommu0 -device vfio-pci,iommu=iommu0", It could tell VFIO
>> to use separate containers and also ensure proper ordering of command
>> line arguments.
>
> Lots of guests can'
On Thu, Mar 09, 2017 at 11:05:36AM +0100, Paolo Bonzini wrote:
>
>
> On 09/03/2017 10:58, Jason Wang wrote:
> >
> >
> > On 2017年03月09日 17:28, Igor Mammedov wrote:
> >> On Thu, 9 Mar 2017 10:32:44 +0800
> >> Jason Wang wrote:
> >>
> >>> On 2017年03月09日 00:40, Igor Mammedov wrote:
> On Tue,
On Thu, Mar 09, 2017 at 01:31:45PM +0100, Paolo Bonzini wrote:
>
>
> On 23/02/2017 16:35, Alex Williamson wrote:
> > It's the architecture of vfio, the user only gets access to the device
> > when the container has iommu protection, therefore vfio needs to look
> > at the device address space to
From: "Dr. David Alan Gilbert"
The 'name' parameter to memory_region_init_* had been marked as debug
only, however vmstate_region_ram uses it as a parameter to
qemu_ram_set_idstr to set RAMBlock names and these form part of the
migration stream.
Signed-off-by: Dr. David Alan Gilbert
---
v2
Re
1 - 100 of 172 matches
Mail list logo
