On 12.02.2016 17:49, Kevin Wolf wrote:
Am 05.02.2016 um 09:58 hat Vladimir Sementsov-Ogievskiy geschrieben:
The new feature for qcow2: storing bitmaps.
This patch adds new header extension to qcow2 - Bitmaps Extension. It
provides an ability to store virtual disk related bitmaps in a qcow2
imag
On Fri, Feb 12, 2016 at 05:23:18PM -0700, Alex Williamson wrote:
> Intel IGD makes use of memory allocated and marked reserved by the
> BIOS as a stolen memory range. For the most part, guest drivers don't
> make use of this, but our achilles heel is the vBIOS. The vBIOS
> programs the device to
We have two applications running on real custom board with custom asic and has
two arm cores. Each application runs on different core, and uses shared memory
for inter application high bandwidth transferss. The trigger for this RPC
mailbox communication where each core can send interrupt to othe
Intel IGD makes use of memory allocated and marked reserved by the
BIOS as a stolen memory range. For the most part, guest drivers don't
make use of this, but our achilles heel is the vBIOS. The vBIOS
programs the device to use the host stolen memory range and it's used
in the pre-boot environmen
Intel graphics (IGD) makes use of a stolen memory area reserved by
the BIOS. The minimum size is 1MB, naturally aligned. Increase the
space we have available to make that possible.
Signed-off-by: Alex Williamson
---
src/config.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
When assigning Intel IGD graphics via QEMU/vfio, the OpRegion for the
device may be exposed as a fw_cfg file. Allocate space for this, copy
the contents and write the ASL Storage register (0xFC) to point to
this buffer. NB, it's possible for QEMU to use the write to the ASL
Storage register to ma
Turns out that maybe we weren't done with IGD by simply reading a
new fw_cfg, copying it into a new reserved memory buffer and writing
back to the IGD device. We need another reserved memory buffer for
stolen memory. The hardware minimum size is 1MB, naturally aligned,
which means we need to be a
The IGD vBIOS really wants to use stolen memory, which it programs
into the device using I/O port BAR4. This is a typical dword index
and data register where indexes below 0x400 seem to be writing stolen
memory addresses. The vBIOS apparently comes up with the address of
stolen memory itself or i
Devices like Intel graphics are known to not only have bad checksums,
but also the wrong device ID. This is not so surprising given that
the video BIOS is typically part of the system firmware image rather
that embedded into the device and needs to support any IGD device
installed into the system.
In order to support device assignment of Intel IGD graphics, we need
support three quirks, which are enabled through vfio using device
specific regions.
The first quirk is to expose the OpRegion of the host. This contains
a Video BIOS Table (VBT), that often provides graphics modes that are
usefu
Match common vfio code with setup, exit, and finalize functions for
BAR, quirk, and VGA management. VGA is also changed to dynamic
allocation to match the other MemoryRegions.
Signed-off-by: Alex Williamson
---
hw/vfio/pci-quirks.c | 38 -
hw/vfio/pci.c| 114 +
The sparse mmap capability in a vfio region info allows vfio to tell
us which sub-areas of a region may be mmap'd. Thus rather than
assuming a single mmap covers the entire region and later frobbing it
ourselves for things like the PCI MSI-X vector table, we can read that
directly from vfio.
Sign
Both platform and PCI vfio drivers create a "slow", I/O memory region
with one or more mmap memory regions overlayed when supported by the
device. Generalize this to a set of common helpers in the core that
pulls the region info from vfio, fills the region data, configures
slow mapping, and adds he
Signed-off-by: Alex Williamson
---
linux-headers/linux/vfio.h | 101 +++-
1 file changed, 99 insertions(+), 2 deletions(-)
diff --git a/linux-headers/linux/vfio.h b/linux-headers/linux/vfio.h
index aa276bc..759b850 100644
--- a/linux-headers/linux/vfio.h
In preparation for supporting capability chains on regions, wrap
ioctl(VFIO_DEVICE_GET_REGION_INFO) so we don't duplicate the code for
each caller.
Signed-off-by: Alex Williamson
---
hw/vfio/common.c | 18 +
hw/vfio/pci.c | 81 +---
vfio-pci currently requires a host= parameter, which comes in the
form of a PCI address in [domain:] notation. We
expect to find a matching entry in sysfs for that under
/sys/bus/pci/devices/. vfio-platform takes a similar approach, but
defines the host= parameter to be a string, which can be mat
v2:
IGD support is greatly expanded. Due to feedback on the previous
serious QEMU no longer maps the OpRegion to the guest, we simply fill
a buffer and expose it as fw_cfg. We could still do the mapping in
the future if there's value to it.
New features include the use of host and LPC bridge co
During incremental backups, if the target has a cluster size that is
larger than the backup cluster size and we are backing up to a target
that cannot (for whichever reason) pull clusters up from a backing image,
we may inadvertantly create unusable incremental backup images.
For example:
If the
64K might not always be appropriate, make this a runtime value.
Signed-off-by: John Snow
---
block/backup.c | 57 +
1 file changed, 29 insertions(+), 28 deletions(-)
diff --git a/block/backup.c b/block/backup.c
index 00cafdb..fcf0043 10064
Incremental backups sometimes need a non-64KiB transfer cluster size.
See patch #2 for the detailed justificaton.
For convenience, this branch is available at:
https://github.com/jnsnow/qemu.git branch incremental-gr
If a backing file isn't specified in the target image and the
cluster_size is larger than the bitmap granularity, we run the risk of
creating bitmaps with allocated clusters but empty/no data which will
prevent the proper reading of the backup in the future.
Signed-off-by: John Snow
---
tests/qe
On 12/02/16 14:45, Peter Maydell wrote:
> NOTE: to get the -bios option to correctly load to the secure-only
> flash I had to implement a new function in loader.c. load_image_mr()
> is just like load_image_targphys() except that it requests loading
> to a MemoryRegion rather than a physaddr. I thi
On 12/02/2016 19:17, Eduardo Habkost wrote:
> Related question: is it OK to have files appearing in multiple
> sections? It would be useful for qdev*.c and vl.c. I would like
> to be CCed in any vl.c patch affecting machine initialization,
> for example.
Sure it is.
Paolo
On 10/02/16 03:41, Richard Henderson wrote:
> The bulk of the original patch set has been reviewed and
> comitted. But the actual end result is still outstanding.
>
>
> r~
>
>
> Richard Henderson (4):
> tcg: Implement indirect memory registers
> tcg: Allocate indirect_base temporaries in
On Sat, Feb 06, 2016 at 09:15:13PM +0200, Michael S. Tsirkin wrote:
> From: Stefano Stabellini
>
> On Xen MSIs can be remapped into pirqs, which are a type of event
> channels. It's mostly for the benefit of PCI passthrough devices, to
> avoid the overhead of interacting with the emulated lapic.
On Fri, Feb 12, 2016 at 06:04:59PM +, Daniel P. Berrange wrote:
> On Fri, Feb 12, 2016 at 06:12:46PM +0100, Markus Armbruster wrote:
> > "Daniel P. Berrange" writes:
> >
> > > On Fri, Feb 12, 2016 at 05:49:38PM +0100, Markus Armbruster wrote:
> > >> "Daniel P. Berrange" writes:
> > >>
> > >
On Fri 12 Feb 2016 06:19:06 PM CET, Kevin Wolf wrote:
> Anyway, the cover letter makes sense to me. And thanks for this great
> writeup! Can we turn it into documentation? Throttling seems to be quite
> underdocumented, and your explanation above let me understand for the
> first time what these *
On Wed, Feb 10, 2016 at 12:02:47PM +0100, Asia Slowinska wrote:
> Stick to the expected order of the FPU registers in xsave (as specified in
> the
> Intel manual.) Otherwise, instructions loading the FPU state don't set it
> up
> correctly.
>
> To set up FPU, software needs to provide a buffer of
On 02/12/2016 07:55 PM, Richard Henderson wrote:
> On 02/12/2016 10:12 PM, Bastian Koppelmann wrote:
>> On 02/12/2016 03:39 AM, Richard Henderson wrote:
>>
>> What do you mean by "pre-interrupt state"? The register context is saved
>> by generate_trap() calls.
>
> Because do_interrupt is normally
Eduardo and me will maintain it.
Signed-off-by: Marcel Apfelbaum
Acked-by: Andreas Färber
---
v1 -> v2:
Modified description to "Machine core" (Eduardo)
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2d6ee17..0590342 100644
--- a/M
On 02/12/2016 09:02 PM, Eduardo Habkost wrote:
Set error location so the error_report() calls will show
appropriate command-line argument or config file info.
Signed-off-by: Eduardo Habkost
---
replay/replay.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/replay/replay.c b/
On 02/12/2016 09:02 PM, Eduardo Habkost wrote:
Set error location so the error_report() calls will show
appropriate command-line argument or config file info.
Signed-off-by: Eduardo Habkost
---
vl.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/vl.c b/vl.c
index 50cd018..8fe79dd
On 02/12/2016 09:02 PM, Eduardo Habkost wrote:
After looping through all command-line arguments, error location
info becomes obsolete, and any function calling error_report()
will print misleading information. This breaks error reporting
for some option handling, like:
$ qemu-system-x86_64 -i
# Background
To configure virtfs, there is two methods in QEMU command line:
1. Use -fsdev and -device virtio-9p-pci,XXX directives
2. Use -virtfs directive
The second method is actually shorthand for the first method. It
constructs fsdev and device options behind the scene. In the end,
there wi
Set error location so the error_report() calls will show
appropriate command-line argument or config file info.
Signed-off-by: Eduardo Habkost
---
vl.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/vl.c b/vl.c
index 50cd018..8fe79dd 100644
--- a/vl.c
+++ b/vl.c
@@ -2907,6 +2907,10 @@
Set error location so the error_report() calls will show
appropriate command-line argument or config file info.
Signed-off-by: Eduardo Habkost
---
replay/replay.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/replay/replay.c b/replay/replay.c
index 9cac178..f8739c2 100644
--- a
This fixes the following bugs in error reporting:
$ qemu-system-x86_64 -icount rr=x -vnc :0
qemu-system-x86_64: -vnc :0: Invalid icount rr option: x
$ qemu-system-x86_64 -m size= -vnc :0
qemu-system-x86_64: -vnc :0: missing 'size' option value
The last command-line option (-vnc) is being
After looping through all command-line arguments, error location
info becomes obsolete, and any function calling error_report()
will print misleading information. This breaks error reporting
for some option handling, like:
$ qemu-system-x86_64 -icount rr=x -vnc :0
qemu-system-x86_64: -vnc :0:
From: Marcel Apfelbaum
Commit e1ce0c3cb (vl.c: fix regression when reading machine type
from config file) fixed the error message when the machine type
was supplied inside the config file. However now the option name
is not displayed correctly if the error happens when the machine
is specified at
On 12 February 2016 at 17:30, Stefano Stabellini
wrote:
> The following changes since commit f075c89f0a9cb31daf38892371d2822177505706:
>
> Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request'
> into staging (2016-02-09 17:56:46 +)
>
> are available in the git repository a
On 02/12/2016 10:12 PM, Bastian Koppelmann wrote:
On 02/12/2016 03:39 AM, Richard Henderson wrote:
On 02/12/2016 03:01 AM, Bastian Koppelmann wrote:
+void tricore_cpu_do_interrupt(CPUState *cs)
+{
+TriCoreCPU *cpu = TRICORE_CPU(cs);
+CPUTriCoreState *env = &cpu->env;
+
+/* The stack
On Fri, Feb 05, 2016 at 07:06:58PM +0100, Igor Mammedov wrote:
> on x86 currently range 0..max_cpus is used to generate
> architecture-dependent CPU ID (APIC Id) for each present
> and possible CPUs. However architecture-dependent CPU IDs
> list could be sparse and code that needs to enumerate
> al
On Fri, Feb 12, 2016 at 12:30:34PM +0100, Andreas Färber wrote:
> Hi,
>
> Am 12.02.2016 um 10:13 schrieb Valentin Rakush:
> > This is RFC because there is another implementation option: it is
> > possible to implement this functionality in the object_finalize for
> > all available targets. All tar
On Fri, Feb 12, 2016 at 03:57:10PM +0100, Andreas Färber wrote:
> X86CPU QOM type is in good hands and actively maintained these days, so
> drop it from the generic QOM CPU subsystem.
>
> Some refactorings and design questions will still intersect, but review
> and discussions of individual series
On Fri, Feb 12, 2016 at 12:22:41PM +0100, Andreas Färber wrote:
> Am 12.02.2016 um 10:17 schrieb Marcel Apfelbaum:
> > On 02/11/2016 09:41 PM, Eduardo Habkost wrote:
> >> On Fri, Feb 05, 2016 at 09:51:07AM +0200, Marcel Apfelbaum wrote:
> >>> On 02/05/2016 09:49 AM, Markus Armbruster wrote:
>
On Fri, Feb 12, 2016 at 05:03:07PM +0100, Kashyap Chamarthy wrote:
[...]
> So, 'qmp-shell' invocation works for me too:
>
> $ ./qmp-shell ./qmp-sock
> [...]
> (QEMU) nbd-server-start
> addr={"type":"inet","data":{"host":"localhost","port":"9000"}} tls-creds=tls0
> {"return": {}}
On Fri, Feb 12, 2016 at 11:17:14AM +0200, Marcel Apfelbaum wrote:
> On 02/11/2016 09:41 PM, Eduardo Habkost wrote:
> >On Fri, Feb 05, 2016 at 09:51:07AM +0200, Marcel Apfelbaum wrote:
> >>On 02/05/2016 09:49 AM, Markus Armbruster wrote:
> >>>"Michael S. Tsirkin" writes:
> >>>
> On Thu, Feb 04,
Oh, sorry, significant note:
These patches are based on Fam's [PATCH v2 00/13] Dirty bitmap changes
for migration/persistence work
On 12.02.2016 21:00, Vladimir Sementsov-Ogievskiy wrote:
Hi all!
These series are derived from my 'Dirty bitmaps migration' series. The
core idea is switch to p
When testing migration, auto-generated by qemu node-names differs in
source and destination qemu and migration fails. After this patch,
auto-generated by iotest nodenames will be the same.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
tests/qemu-iotests/iotests.py | 3 ++-
1 file changed, 2 in
On Fri, Feb 12, 2016 at 06:12:46PM +0100, Markus Armbruster wrote:
> "Daniel P. Berrange" writes:
>
> > On Fri, Feb 12, 2016 at 05:49:38PM +0100, Markus Armbruster wrote:
> >> "Daniel P. Berrange" writes:
> >>
> >> > On Thu, Jan 21, 2016 at 07:16:25AM +0100, Hervé Poussineau wrote:
> >> >> Hi,
Reviewed-by: John Snow
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
tests/qemu-iotests/iotests.py | 6 ++
1 file changed, 6 insertions(+)
diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index ab652ea..dc45dd9 100644
--- a/tests/qemu-iotests/iotests.py
+++ b/tes
Test
- start two vms (vm_a, vm_b)
- in a
- do writes from set A
- do writes from set B
- fix bitmap md5
- clear bitmap
- do writes from set A
- start migration
- than, in b
- wait vm start (postcopy should start)
- do writes from set B
- check btimap md5
The te
The test starts two vms (vm_a, vm_b), create dirty bitmap in
the first one, do several writes to corresponding device and
then migrate vm_a to vm_b with dirty bitmaps.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
tests/qemu-iotests/117 | 82 ++
The only problem with it is the same qmp socket name (which is
vm._monitor_path) for all vms. And because of this second vm couldn't be
lauched (vm.launch() fails because of socket is already in use).
This patch adds a number of vm into vm._monitor_path
Reviewed-by: John Snow
Signed-off-by: Vladi
Reviewed-by: John Snow
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block/dirty-bitmap.c | 1 +
include/qemu/hbitmap.h | 8
qapi/block-core.json | 5 -
util/hbitmap.c | 8
4 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/block/dirty-bitmap.c b/b
Postcopy migration of dirty bitmaps. Only named dirty bitmaps,
associated with root nodes and non-root named nodes are migrated.
If destination qemu is already containing a dirty bitmap with the same name
as a migrated bitmap (for the same node), than, if their granularities are
the same the migra
Add function opposite to qemu_get_counted_string.
qemu_put_counted_string puts one-byte length of the string (string
should not be longer than 255 characters), and then it puts the string,
without last zero byte.
Reviewed-by: John Snow
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
include/mig
Only-postcopy savevm states (dirty-bitmap) don't need live iteration, so
to disable them and stop transporting empty sections there is a new
savevm handler.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
include/migration/vmstate.h | 1 +
migration/savevm.c | 5 +
2 files changed,
There would be savevm states (dirty-bitmap) which can migrate only in
postcopy stage. The corresponding pending is introduced here.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
include/migration/vmstate.h | 5 +++--
include/sysemu/sysemu.h | 5 +++--
migration/block.c | 7 +++
Reviewed-by: John Snow
Reviewed-by: Eric Blake
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
include/migration/migration.h | 1 +
migration/migration.c | 9 +
qapi-schema.json | 4 +++-
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/include/migrati
Enabling bitmap successor is necessary to enable successors of bitmaps
being migrated before target vm start.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block/dirty-bitmap.c | 5 +
include/block/dirty-bitmap.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/block/dirty-bit
Split common postcopy staff from ram postcopy staff.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
include/migration/migration.h | 1 +
migration/migration.c | 39 +++
migration/postcopy-ram.c | 4 +++-
migration/savevm.c| 31 +
Fill postcopy-able pending only if ram postcopy is enabled.
It is necessary because of there will be other postcopy-able states and
when ram postcopy is disabled, it should not spoil common postcopy
related pending.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
migration/ram.c | 8 ++--
1
Now postcopy-able states are recognized by not NULL
save_live_complete_postcopy handler. But when we have several different
postcopy-able states, it is not convenient. Ram postcopy may be
disabled, while some other postcopy enabled, in this case Ram state
should behave as it is not postcopy-able.
Enable postcopy if dirty bitmap migration is endabled.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
migration/migration.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/migration/migration.c b/migration/migration.c
index 31993e9..9ccbeee 100644
--- a/migration/migration.c
Hi all!
These series are derived from my 'Dirty bitmaps migration' series. The
core idea is switch to postcopy migration and drop usage of meta
bitmaps.
These patches provide dirty bitmap postcopy migration feature. Only
named dirty bitmaps are to be migrated. Migration may be enabled using
migra
Like bdrv_next() - bdrv_next_dirty_bitmap() is a function to provide
access to private dirty bitmaps list.
Reviewed-by: John Snow
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block/dirty-bitmap.c | 10 ++
include/block/dirty-bitmap.h | 3 +++
2 files changed, 13 insertions(
From: Ian Campbell
Xen 4.2 become unsupported upstream in 09/2015 (see
http://wiki.xen.org/wiki/Xen_Release_Features). However as far as the
interfaces provided by the toolstack libraries go 4.2 and 4.3 are
indistinguishable.
Therefore drop support for Xen 4.1 and earlier which removes a whole
p
From: Ian Campbell
We assume (and check for in configure) 4.2 or later now. In reality
all of the removed checks are for far older versions.
FMT_ioreq_size is no longer needed.
Signed-off-by: Ian Campbell
Reviewed-by: Stefano Stabellini
Signed-off-by: Stefano Stabellini
---
hw/display/xenfb
From: Ian Campbell
The xc version is now always present.
Signed-off-by: Ian Campbell
Reviewed-by: Stefano Stabellini
Signed-off-by: Stefano Stabellini
---
include/hw/xen/xen_common.h |6 --
xen-hvm.c |2 +-
2 files changed, 1 insertion(+), 7 deletions(-)
diff -
From: Ian Campbell
Now that we no longer support Xen 4.2 and earlier only the <470 case
needs this so it can live with all the others.
Signed-off-by: Ian Campbell
Reviewed-by: Stefano Stabellini
Signed-off-by: Stefano Stabellini
---
include/hw/xen/xen_common.h | 34 ++--
From: Ian Campbell
Now that 4.2 and earlier are no longer supported "xc_interface *" is
always the right type for the xc interface handle.
With this we can also simplify the handling of the xenforeignmemory
compatibility wrapper by making xenforeignmemory_handle ==
xc_interface, instead of an xc
The following changes since commit f075c89f0a9cb31daf38892371d2822177505706:
Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into
staging (2016-02-09 17:56:46 +)
are available in the git repository at:
git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xe
Am 10.02.2016 um 16:48 schrieb Christian Borntraeger:
> On 02/10/2016 04:42 PM, Juan Quintela wrote:
>> Please, send any topic that you are interested in covering.
>>
>> At the end of Monday I will send an email with the agenda or the
>> cancellation of the call, so hurry up.
>>
>> After discussion
On Fri, Feb 12, 2016 at 05:09:52PM +, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrange (berra...@redhat.com) wrote:
> > This extends the TCP migration backend so that it can make use
> > of QIOChannelTLS to provide transparent TLS encryption. To
> > trigger enablement the URI on the incomin
On 12.02.2016 18:50, Peter Maydell wrote:
> Move bank_number()'s implementation into internals.h, so
> it's available in the user-mode-only compile as well.
>
> Signed-off-by: Peter Maydell
Reviewed-by: Sergey Fedorov
> ---
> Embarrassingly light on testing on that last change.
>
> target-arm/
* Daniel P. Berrange (berra...@redhat.com) wrote:
> The s390 skeys monitor command needs to write out a plain text
> file. Currently it is using the QEMUFile class for this. There
> is no real benefit to this, and the downside is that it needs to
> snprintf via an intermediate buffer. Switching to
sridhar kulkarni writes:
> Hi,
> I am working on a requirement where I need to have shared memory IPC
> between two guest VM's running different OS. Both VM's use vexpress-A9
> boards. I came across the "ivshmem" implementation and have some
> questions. Whether the "ivshmem" implementation can b
Am 05.02.2016 um 11:59 hat Alberto Garcia geschrieben:
> Hello everyone,
>
> the current throttling code in QEMU allows limiting the I/O rate on
> block devices. Limits can be set in operations per second (IOPS) or
> bytes per second, allowing separate limits for read and write
> operations on bot
* Daniel P. Berrange (berra...@redhat.com) wrote:
> On Tue, Feb 02, 2016 at 05:06:24PM +, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrange (berra...@redhat.com) wrote:
> > > Introduce a new QEMUFile implementation that is based on
> > > the QIOChannel objects. This impl is different from
"Daniel P. Berrange" writes:
> On Fri, Feb 12, 2016 at 05:49:38PM +0100, Markus Armbruster wrote:
>> "Daniel P. Berrange" writes:
>>
>> > On Thu, Jan 21, 2016 at 07:16:25AM +0100, Hervé Poussineau wrote:
>> >> Hi,
>> >>
>> >> This patch (commit d0d7708ba29cbcc343364a46bff981e0ff88366f) regress
if i try to compile with target-list=i386-linux-user it is working so
the problem must the target i386-softmmu
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1545024
Title:
compiling on armv7 crashe
* Daniel P. Berrange (berra...@redhat.com) wrote:
> This extends the TCP migration backend so that it can make use
> of QIOChannelTLS to provide transparent TLS encryption. To
> trigger enablement the URI on the incoming and outgoing sides
> should have 'tls-creds=ID' appended, eg
>
>tcp:$HOST
On 12 February 2016 at 15:05, sridhar kulkarni wrote:
> I am working on a requirement where I need to have shared memory IPC between
> two guest VM's running different OS. Both VM's use vexpress-A9 boards. I
> came across the "ivshmem" implementation and have some questions. Whether
> the "ivshmem
On Fri, Feb 12, 2016 at 05:49:38PM +0100, Markus Armbruster wrote:
> "Daniel P. Berrange" writes:
>
> > On Thu, Jan 21, 2016 at 07:16:25AM +0100, Hervé Poussineau wrote:
> >> Hi,
> >>
> >> This patch (commit d0d7708ba29cbcc343364a46bff981e0ff88366f) regresses the
> >> following command line:
>
"Daniel P. Berrange" writes:
> On Thu, Jan 21, 2016 at 07:16:25AM +0100, Hervé Poussineau wrote:
>> Hi,
>>
>> This patch (commit d0d7708ba29cbcc343364a46bff981e0ff88366f) regresses the
>> following command line:
>> qemu-system-i386 -nodefaults -chardev vc,id=mon0 -mon chardev=mon0
>>
>> Before
Hi,
I am working on a requirement where I need to have shared memory IPC between
two guest VM's running different OS. Both VM's use vexpress-A9 boards. I came
across the "ivshmem" implementation and have some questions. Whether the
"ivshmem" implementation can be used on qemu-system-arm? I under
On 02/12/2016 03:55 PM, Paolo Bonzini wrote:
On 12/02/2016 13:50, Dr. David Alan Gilbert wrote:
I'll admit to not really understanding what the difference is
between bh and coroutine context; I'd thought if it was all
in the main thread stuff was safe.
It's arguably a bug in the block layer co
On Fri, Feb 12, 2016 at 03:00:32PM +, Daniel P. Berrange wrote:
> On Fri, Feb 12, 2016 at 02:28:33PM +0100, Kashyap Chamarthy wrote:
> > On Wed, Feb 10, 2016 at 06:40:58PM +, Daniel P. Berrange wrote:
> >
> > [...]
> >
> > I've applied all the series in this patches,
s/series in this pa
FYI is is tested on current GIT master
commit fc1ec1acffd29d54c0c4266d30d38b2399d42f4f
Merge: f163684 1834ed3
Author: Peter Maydell
Date: Thu Feb 11 15:09:33 2016 +
Merge remote-tracking branch 'remotes/mjt/tags/pull-trivial-
patches-2016-02-11' into staging
--
You received this bug
i have tried gcc4.9 and gcc4.8. both creating this error
im using debian 8(jessie) and the host is a odroid-xu4
(http://www.hardkernel.com/main/products/prdt_info.php?g_code=G143452239825&tab_idx=2)
spice and spice-platform are build from the last stable the other
dependecies are from the debian
Public bug reported:
Get a pair of machines with infiniband support. On one host run
$ qemu-system-x86_64 -monitor stdio -incoming rdma:ibme: -vnc :1 -m
1000
To start an incoming migration.
Now on the other host, run QEMU with an intentionally different configuration
(ie different RAM siz
** Changed in: qemu
Status: New => Confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1545052
Title:
RDMA migration will hang forever if target QEMU fails to load vmstate
Status in QEM
Move get/set_r13_banked() from helper.c to op_helper.c. This will
let us add exception-raising code to them, and also puts them
in the same file as get/set_user_reg(), which makes some conceptual
sense.
(The original reason for the helper.c/op_helper.c split was that
only op_helper.c had access to
The user-mode versions of get/set_r13_banked() exist just to assert
if they're ever called -- the translate time code should never
emit calls to them because SRS from user mode always UNDEF.
There's no code in the softmmu versions that can't compile in
CONFIG_USER_ONLY, and the assertion is not par
* Daniel P. Berrange (berra...@redhat.com) wrote:
> Now that there is a set_blocking callback in QEMUFileOps,
> and all users needing non-blocking support have been
> converted to QIOChannel, there is no longer any codepath
> requiring the qemu_get_fd() method for QEMUFile. Remove it
> to avoid fur
On 12 February 2016 at 15:16, Edgar E. Iglesias
wrote:
> On Fri, Feb 12, 2016 at 03:15:22PM +, Peter Maydell wrote:
>> On 12 February 2016 at 15:12, Edgar E. Iglesias
>> wrote:
>> > On Thu, Feb 11, 2016 at 07:11:48PM +, Peter Maydell wrote:
>> >> The user-mode versions of get/set_r13_bank
The SRS instruction is a bit of an oddity because it isn't
used by Linux these days. Nonetheless it has a bunch of
UNPREDICTABLE, UNDEF and trapping behaviour that we weren't
correctly implementing:
- trap to EL3 if EL3 is AArch64 and we are at Secure EL1
- UNDEFINED in Hyp mode
- UNPREDICTABLE
Move bank_number()'s implementation into internals.h, so
it's available in the user-mode-only compile as well.
Signed-off-by: Peter Maydell
---
Embarrassingly light on testing on that last change.
target-arm/helper.c| 25 -
target-arm/internals.h | 26 +++
On 02/12/2016 06:24 AM, Peter Maydell wrote:
> On 9 February 2016 at 18:49, Eric Blake wrote:
>> Actively redefining 'inline' is wrong for C++, where gcc has an
>> extension 'inline namespace' which fails to compile if the
>> keyword 'inline' is replaced by a macro expansion. This will
>> matter
1 - 100 of 178 matches
Mail list logo
