From: Heiher
Signed-off-by: Heiher
---
target-mips/mips-defs.h | 2 +
target-mips/translate.c | 449 ++-
target-mips/translate_init.c | 24 +++
3 files changed, 469 insertions(+), 6 deletions(-)
diff --git a/target-mips/mips-defs.h b/target-
--git a/target-mips/helper.c b/target-mips/helper.c
index c864b15..a70b20f 100644
--- a/target-mips/helper.c
+++ b/target-mips/helper.c
@@ -715,7 +715,7 @@ void mips_cpu_do_interrupt(CPUState *cs)
int KX = (env->CP0_Status & (1 << CP0St_KX)) != 0;
if ((
conversion happens, but I need
its output.For that,
should I modify the code of tcg or something?
Nithish R
fedora.img -cdrom fedora.iso -boot d
VNC server running on `127.0.0.1:5900'
How do I enable my proper booting of guest OS?
Nithish R
On Sat, Aug 13, 2011 at 11:13 PM, Mulyadi Santosa wrote:
> On Sat, Aug 13, 2011 at 21:54, Nithish R wrote:
> > Hi
> > Thanx a lot... It worked...
>
> nice, btw, please reply to the list too, I don't want to take it as
> private discussion
>
> > By
none has out_asm or any command associated with it.
I need to know how Qemu is generating the log file in the Qemu Monitor when
we type things like log out_asm, in_asm, logfile a,etc.
Thanks In Advance,
Nithish R
I've tested an unpatched QEMU 2.3.0 (x86_64) with "-k pt_br" option and the
"/?°" key works perfectly.
I have not tested the numpad ".", but I can inform that ABNT2 keyboard does
have "." (dot) and "," (comma) as separate keys: comma (numlock on)
combined with delete (numlock off).
But I found an
Hello,
I would like to try this new functionality. What's the correct way to do
this?
I'm trying the following (after applying the patches to qemu upstream):
qemu-system-i386 mylinux.qcow2 -icount shift=7,rr=record,rrfile=record.bin
-net none
Linux gets booted, record.bin file is created.
Then I
In my QEMU-based project I would like to perform "extensive" tracing
of basic blocks (translation blocks). I.e. in addition to what the
existing tracing mechanism does, I'd like to log registers modified by
TB and memory (RAM) written by TB. As for registers, it seems to be
trivial. My main problem
I have some issues when accessing guest Linux kernel memory above
0xC000 by means of cpu_memory_rw_debug (x86_64 host, MIPS guest),
and I'm trying to debug it.
Here is an excerpt from r4k_map_address(), related to addresses >= 0x8000.
Actually, it maps 0x8010 and 0xA010 to the same
> > Here is an excerpt from r4k_map_address(), related to addresses >=
0x8000.
> > Actually, it maps 0x8010 and 0xA010 to the same physical
> > address. What's the idea behind that?
>
> 0x8010 is kseg0 whereas 0xA010 is kseg1, both segments are
> unmapped thus both refer to the
> > Here is an excerpt from r4k_map_address(), related to addresses >=
0x8000.
> > Actually, it maps 0x8010 and 0xA010 to the same physical
> > address. What's the idea behind that?
>
> 0x8010 is kseg0 whereas 0xA010 is kseg1, both segments are
> unmapped thus both refer to the
Hello,
I implemented a simple sys_bus device that only communicates through
port io. The purpose of this device is to be accessible via /dev/port
only, with no need for any additional kernel modules.
I Defined the memory region using memory_region_init_io and registered
it using sysbus_add_io.
I r
If I understand correctly, the most advanced MMU that QEMU emulates
for MIPS is "R4000-style" MMU - i.e. a "software-managed" TLB, where
on TLB miss QEMU just emulates exception that should be handled by the
guest OS. So, QEMU doesn't walk through the page directory, like it
does when emulating e.g
All,
I am testing VxLAN performance in VM. For this I am using below command
to bring up the VM.
# qemu-system-x86_64 -m 4096 -smp 4 -boot c -device
virtio-net-pci,netdev=tap0,mac=00:11:22:33:44:55 -netdev
tap,id=tap0,script=no,vhost=on -drive file=/root/vdisk_rhel65.img &
This is resulting i
On Mon, Jun 29, 2015 at 9:04 PM, Vlad Yasevich wrote:
> On 06/29/2015 01:46 AM, Santosh R wrote:
> > All,
> >
> >I am testing VxLAN performance in VM. For this I am using below
> command
> > to bring up the VM.
> > # qemu-system-x86_64 -m 4096 -smp 4 -boot
On Mon, Jun 29, 2015 at 9:24 PM, Santosh R wrote:
>
> On Mon, Jun 29, 2015 at 9:04 PM, Vlad Yasevich
> wrote:
>
>> On 06/29/2015 01:46 AM, Santosh R wrote:
>> > All,
>> >
>> >I am testing VxLAN performance in VM. For this I am using below
&g
not change any device features
# ethtool -k tap0 | grep -i tnl
tx-udp_tnl-segmentation: off [fixed]
On Tue, Jun 30, 2015 at 12:24 PM, Santosh R wrote:
>
> On Mon, Jun 29, 2015 at 9:24 PM, Santosh R wrote:
>
>>
>> On Mon, Jun 29, 2015 at 9:04 PM, Vlad Yasevich
>> wrote:
I am using 3.18 kernel.
#uname -a
Linux Indra.asicdesigners.com 3.18.0 #11 SMP Wed Jul 1 21:49:44 IST 2015
x86_64 x86_64 x86_64 GNU/Linux
#cat /etc/issue
Red Hat Enterprise Linux Server release 6.5 (Santiago)
Kernel \r on an \m
As mentioned in my initial post, this is how I am starting the VM
> > When debugging (via gdbstub), I would like to get the current process
> > id by a virtual address. When the virtual address is in the
> > user-space, the only way to find the current task_struct I can think
> > of is to iterate over all the task_struct's (assuming we know
> > task_init and the
Hello,
I try to use cpu_memory_rw_debug() to read from 0x8xxx kernel virtual
address, when the guest is in user mode. Obviously, it fails.
Is it possible to modify some control registers to allow such an access? I
tried to set/clear the kernel mode bits in CP0_Status, but it doesn't help.
Tha
>> I try to use cpu_memory_rw_debug() to read from 0x8xxx kernel virtual
>> address, when the guest is in user mode. Obviously, it fails.
>> Is it possible to modify some control registers to allow such an access? I
>> tried to set/clear the kernel mode bits in CP0_Status, but it doesn't help.
Hello,
On x86 one can get the current PGD from CR3. What's the right way to
do this on ARM?
In a code based on an old QEMU version, I see the following:
pgd = env->cp15.c2_base0 & env->cp15.c2_base_mask;
But in the recent QEMU version c2_base0 field is absent. Instead,
there's ttbr0[] array. So s
>> On x86 one can get the current PGD from CR3. What's the right way to
>> do this on ARM?
>
> What's a PGD ?
Page global directory
> However just looking at base & mask is not necessarily
> correct -- depending on the configuration of the CPU we
> might be using translation table base control r
Hello,
I need to access thread_info (linux kernel struct) of the guest from within
qemu, when the guest is in kernel mode.
To do this, I read the stack pointer and mask it with ~(stack_size - 1).
This works with x86 and ARM, but doesn't seem to work with MIPS - the
pointer points to something that
Thanks for the useful info!
(Actually, my approach works as well - it was just endianness issue...)
> This set of patches is related to the reverse execution and deterministic
> replay of qemu execution. It includes recording and replaying of serial
> devices
> and block devices operations.
>
> With these patches one can record and deterministically replay behavior
> of the system with connected
ing else is fine. This occurs
only after switching to the qemu-console and back. Any pointer to where to
look for the solution to the problem would be welcome.
Hope this is the right mailing-list.
Thanks.
arvind. r.
Or, someone who hasn't agreed to the contract could implement armv6
and 7 support.
-- John.
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
On 6/7/06, Paul Brook <[EMAIL PROTECTED]> wrote:
> > Basing work on the gcc/binutils code doesn't help me either because I
> > wrote most of that code in the first place :-)
>
> Since the idea is for someone else do it, that doesn't matter.
>
> I'm wondering why, if it were done, it would be a pr
ux image tries to make use of, but
which qemu does not emulate.
The host CPU is a dual-core Pentium D. Here is relevant lines from
/proc/cpuinfo:
--
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : Intel(R) Pentium(R) D CPU 3.
R. Armiento wrote:
The error looks very similar to the one reported here:
http://www.mail-archive.com/qemu-devel@nongnu.org/msg03964.html
But I believe that reported issue should not appear in recent qemu,
since SSE3 is now emulated (right?). (At least the patch in the end of
that thread
Hi,
Joachim Henke wrote:
Please use the updated patch attached below.
Great work! The patch fixes the kernel panic for me. Thank you.
However, as you probably know, despite not declaring MONITOR in qemu,
kqemu sees MONITOR on the host processor and Linux CPU usage will still
be 100%, even w
Hi,
Again, thank you for helping out with updated patches, it is much
appreciated.
Joachim Henke wrote:
R. Armiento wrote:
So even with your patch applied one should use the 'idle=halt'
kernel parameter when booting Linux with -kernel-kqemu on newer
processors. [...]
To lower the
R. Armiento wrote:
Couldn't there be situations where someone depends on mwait waking up
without there being an event that wakes hlt? Or are we sure qemu's hlt
will happen to wake up anyway?
Joachim Henke wrote:
Currently the Linux kernel simply uses monitor/mwait as a f
On 7/8/06, Oliver Gerlich <[EMAIL PROTECTED]> wrote:
Is wxC still under active development? The CVS version seems to be quite
old, and I also couldn't find any documentation.
Well it wouldn't be the first unmaintained batch of code added to
QEMU... Slirp is the example that comes to mind. In
Jens Axboe wrote:
On Tue, Aug 01 2006, Jamie Lokier wrote:
Should we change to only reiserfs and expect fsync() to commit data
reliably only with that fs? I realise this is a lot of difficult
questions, that apply to more than just Qemu...
Yes, reiser is the only one that works reliably acro
Thomas Steffen wrote:
On 8/7/06, R. Armiento <[EMAIL PROTECTED]> wrote:
And some IDE disks do not let you switch off write-caching. So as far
as I know, you need SCSI for transactional guarantees.
I don't think the fact that there are some buggy drives/firmwares out
there should
I I come by means of this, to ask for the inclusion of kqemu in the project Wackenroader GNU/LINUX. The project to wackenroader consists of one distro live compact disc with kernel linux, destined the Brazilian community. I anticipate gratefulness.
_
Hello Guys,
Looks like we haven't yet official support for OpenGL on MacOS? I need to apply
third-party patches to make it work. It would be great if these parts are
imported to qemu and be official. Nowaways, it's really needed Acceleration on
VMs for who uses Graphical interfaces browsing, eg
ing to introspect /org/qemu/Display1/VM), the call hangs
and never returns.
node, err := introspect.Call(session.Object("org.qemu.Display1.VM",
"/org/qemu/Display1/VM"))
I'm not sure what's going wrong here, but I suspect I'm obtaining the
file descriptor wr
Hi,
I'm trying to use the deterministic record/replay feature, and I would
like to know which commit I should take to get it work.
In RC0 it seems to be broken. I tried pre-MTTCG commit 2421f381dc, as
mentioned here:
http://lists.nongnu.org/archive/html/qemu-devel/2017-03/msg02657.html
with this p
(qemu) unknown keycodes `empty+aliases(qwerty)’, please report to
qemu-devel@nongnu.org
reported.
signature.asc
Description: Message signed with OpenPGP using GPGMail
>> Hi,
>>
>> I'm trying to use the deterministic record/replay feature, and I would
>> like to know which commit I should take to get it work.
>> In RC0 it seems to be broken. I tried pre-MTTCG commit 2421f381dc, as
> Can you retry with the latest rc? There were some fixes regarding rr since
> rc
I'm trying to use the deterministic record/replay feature, and I would
like to know which commit I should take to get it work.
In RC0 it seems to be broken. I tried pre-MTTCG commit 2421f381dc, as
>>
>>> Can you retry with the latest rc? There were some fixes regarding rr since
>>>
Hi,
I recently ran into problems and after a long time trying to find out the cause
landed here, I got in trouble using a CentOs Cloud image:
https://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud-1905.qcow2.xz
which extracts to a .qcow2 image with sha256 of:
b376afdc0150601f15e535
Since you are introducing #define CPUID_VENDOR_SZ, you may as well want to
introduce
#define CPUID_VENDOR_OFF_1 0
#define CPUID_VENDOR_OFF_2 4
#define CPUID_VENDOR_OFF_3 8
and use them.
Regards
Vijay
-Original Message-
From: qemu-devel-bounces+vijaymohan.pandarathil=hp@nongnu.
Public bug reported:
QEMU version: 1.0, 1.1, and 1.2
Host OS:
Intel(R) Core(TM) i5-2520M CPU @ 2.50GH
Linux tpad 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64
x86_64 x86_64 GNU/Linux
SLES Media:
SLES-11-SP2-DVD-ppc64-GM-DVD1.iso: sha256
Add support for error containment when a VFIO device assigned to a KVM
guest encounters an error. This is for PCIe devices/drivers that support AER
functionality. When the host OS is notified of an error in a device either
through the firmware first approach or through an interrupt handled by the A
- Added vfio_device_get_from_vdev(), vfio_device_put_vdev()
as wrappers to get/put reference to vfio_device from struct device.
- Added vfio_device_data() as a wrapper to get device_data from
vfio_device.
Signed-off-by: Vijay Mohan Pandarathil
---
drivers/vf
- New VFIO_SET_IRQ ioctl option to pass the eventfd that is signalled
when
an error occurs in the vfio_pci_device
- Register pci_error_handler for the vfio_pci driver
- When the device encounters an error, the error handler registered by
the vfio_pci
- Create eventfd per vfio device assigned to a guest and register an
event handler
- This fd is passed to the vfio_pci driver through the SET_IRQ ioctl
- When the device encounters an error, the eventfd is signalled
and the qemu eventfd handler gets in
won't effect TCP migration code.
More comments inline
On 01/29/2013 12:01 AM, mrhi...@linux.vnet.ibm.com wrote:
From: "Michael R. Hines"
Signed-off-by: Michael R. Hines
---
migration-tcp.c | 53 +
mi
an either add a new rdma_buffer QEMUFileOps or add the address to
put_buffer.
you also have some white space damage in the beginning of savevm.c.
Regards,
Orit
On 01/29/2013 12:01 AM, mrhi...@linux.vnet.ibm.com wrote
From: "Michael R. Hines"
Signed-off-by: Michael R.
What about using the linux pagemap?
With RDMA, I have exactly this problem. The cost of mapping and faulting
and checking for zeros is higher than the cost of simply dumping the
page into remote memory on the server side.
If we could avoid accessing the page, it was save huge amounts of time.
ounting without doing any additional memory
copies?
(If I'm understanding the abstraction properly)
- Michael
On 01/31/2013 01:56 PM, Orit Wasserman wrote:
On 01/31/2013 05:08 PM, Michael R. hines wrote:
Yes, I was hoping for a comment about this in particular (before I send out
anoth
> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Tuesday, January 29, 2013 5:25 AM
> To: Pandarathil, Vijaymohan R
> Cc: Gleb Natapov; Bjorn Helgaas; Blue Swirl; Ortiz, Lance E;
> k...@vger.kernel.org; qemu-devel
Excellent, thank you.
On 02/01/2013 05:01 AM, Orit Wasserman wrote:
On 01/31/2013 09:10 PM, Michael R. hines wrote:
Sorry, I didn't go into enough detail about the problem I'm having in the loop:
The loop that's not breaking is inside qemu_loadvm_state(), not
ram_save_block()
Add support for error containment when a VFIO device assigned to a KVM
guest encounters an error. This is for PCIe devices/drivers that support AER
functionality. When the host OS is notified of an error in a device either
through the firmware first approach or through an interrupt handled by the
- Added vfio_device_get_from_dev() as wrapper to get
reference to vfio_device from struct device.
- Added vfio_device_data() as a wrapper to get device_data from
vfio_device.
Signed-off-by: Vijay Mohan Pandarathil
---
drivers/vfio/vfio.c | 41 +++
- New VFIO_SET_IRQ ioctl option to pass the eventfd that is signaled
when
an error occurs in the vfio_pci_device
- Register pci_error_handler for the vfio_pci driver
- When the device encounters an error, the error handler registered by
the vfio_pci dr
- Create eventfd per vfio device assigned to a guest and register an
event handler
- This fd is passed to the vfio_pci driver through the SET_IRQ ioctl
- When the device encounters an error, the eventfd is signalled
and the qemu eventfd handler gets inv
> -Original Message-
> From: Gleb Natapov [mailto:g...@redhat.com]
> Sent: Tuesday, February 05, 2013 12:05 AM
> To: Blue Swirl
> Cc: Pandarathil, Vijaymohan R; Alex Williamson; Bjorn Helgaas; Ortiz, Lance
> E; k...@vger.kernel.org; qemu-devel@nongnu.org; linux-.
> -Original Message-
> From: Gleb Natapov [mailto:g...@redhat.com]
> Sent: Tuesday, February 05, 2013 1:21 AM
> To: Pandarathil, Vijaymohan R
> Cc: Blue Swirl; Alex Williamson; Bjorn Helgaas; Ortiz, Lance E;
> k...@vger.kernel.org; qemu-devel@nongnu.org; linux-.
> -Original Message-
> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> ow...@vger.kernel.org] On Behalf Of Gleb Natapov
> Sent: Tuesday, February 05, 2013 3:37 AM
> To: Pandarathil, Vijaymohan R
> Cc: Blue Swirl; Alex Williamson; Bjorn Helgaas; O
Hi,
According to the website, I should ask here for someone to make a wiki
account for me?
I would like to post documentation of the RDMA patches I'm preparing.
Thanks,
- Michael R. Hines
From: "Michael R. Hines"
Signed-off-by: Michael R. Hines
---
exec.c | 27 +++
vl.c | 13 +
2 files changed, 40 insertions(+)
diff --git a/exec.c b/exec.c
index b85508b..b7ac6fa 100644
--- a/exec.c
+++ b/exec.c
@@ -25,6 +25,8 @@
#endif
From: "Michael R. Hines"
Signed-off-by: Michael R. Hines
---
hmp-commands.hx | 28
hmp.c | 12
hmp.h |2 ++
include/migration/qemu-file.h |1 +
include/qapi/qm
From: "Michael R. Hines"
Signed-off-by: Michael R. Hines
---
include/qemu/rdma.h | 281 ++
migration-rdma.c| 1444 +++
2 files changed, 1725 insertions(+)
create mode 100644 include/qemu/rdma.h
create mode 100644 migrat
From: "Michael R. Hines"
Signed-off-by: Michael R. Hines
---
migration-tcp.c | 19 +++
migration.c | 53 -
2 files changed, 71 insertions(+), 1 deletion(-)
diff --git a/migration-tcp.c b/migration-tcp.c
ind
From: "Michael R. Hines"
This patchest introduces RDMA-based live-migration to QEMU.
A copy of this documentation is located online:
http://wiki.qemu.org/Features/RDMALiveMigration
DESIGN:
==
1. In order to provide maximum cross-device compatibility, we use the
librdma
From: "Michael R. Hines"
Signed-off-by: Michael R. Hines
---
arch_init.c | 84 ---
savevm.c| 59 -
2 files changed, 139 insertions(+), 4 deletions(-)
diff --git a/arch_init.c b/a
From: "Michael R. Hines"
This patchest introduces RDMA-based live-migration to QEMU.
A copy of this documentation is located online:
http://wiki.qemu.org/Features/RDMALiveMigration
DESIGN:
==
1. In order to provide maximum cross-device compatibility, we use the
librdma
None of the other migration QMP commands use dashes.
Shouldn't I stay consistent with the other commands?
If someone wants to re-work the migration command structure as a whole,
I'll certainly adapt to the new structure.
On 02/11/2013 05:58 PM, Eric Blake wrote:
+++ b/qapi-schema.json
#
Acknowledged.
/*
* Michael R. Hines
* http://researcher.ibm.com/person/us-mrhines
*/
From:
Eric Blake
To:
"Michael R. Hines" ,
Cc:
qemu-devel@nongnu.org, Anthony Liguori/Austin/IBM@IBMUS, Bulent
Abali/Watson/IBM@IBMUS, Michael R Hines/Watson/IBM@IBMUS, Gokul B
Kandiraju/Watson
Very helpful, thank you. I'll implement these and all the other ones soon.
- Michael
On 02/13/2013 04:50 AM, Orit Wasserman wrote:
On 02/12/2013 12:49 AM, Michael R. Hines wrote:
From: "Michael R. Hines"
Signed-off-by: Michael R. Hines
---
arc
Acknowledged.
On 02/13/2013 03:23 AM, Orit Wasserman wrote:
Hi Michael,
I would prefer that only migration specific code will be included in
migration-rdma.c.
The general RDMA code should be in rdma.c file (like the rdma.h header file).
Thanks,
Orit
On 02/12/2013 12:49 AM, Michael R. Hines
Orit (and anthony if you're not busy),
I forgot to respond to this very important comment:
On 02/13/2013 03:46 AM, Orit Wasserman wrote:
Are you still using the tcp for transferring device state? If so you
can call the tcp functions from the migration rdma code as a first
step but I would pref
Acknowledged.
On 02/18/2013 06:02 AM, Paolo Bonzini wrote:
Il 28/01/2013 23:01, mrhi...@linux.vnet.ibm.com ha scritto:
From: "Michael R. Hines"
Signed-off-by: Michael R. Hines
---
Makefile.target |5 +-
include/qemu/rdma.h | 249 ++
Please make this include
P command
line - we don't really have a preference.
Either way is fine whatever the consensus is.
- Michael
On 02/18/2013 05:37 AM, Paolo Bonzini wrote:
Il 11/02/2013 23:49, Michael R. Hines ha scritto:
+/*
+ * Memory regions need to be registered with the device and queue pairs setu
st to get rid of the migrate_use_rdma() checks
everywhere...
Thanks for the suggestion,
- Michael
On 02/18/2013 05:52 AM, Paolo Bonzini wrote:
Il 14/02/2013 20:29, Michael R. Hines ha scritto:
Are you still using the tcp for transferring device state? If so you
can call the tcp functions from the mi
On 02/18/2013 06:01 AM, Paolo Bonzini wrote:
Orit, can you rebase and post an RFC of your vectored-send patches for
TCP migration? Perhaps you and Michael can figure out an API that works
well for both TCP and RDMA.
Looking forward to reading these.
+#ifdef RDMA_EXTRA_SYNC
+/*
+
On 02/18/2013 03:24 AM, Orit Wasserman wrote:
Hi Michael, The guest device state is quite small (~100K probably
less) especially when compared to the guest memory and we already are
pinning the guest memory for RDMA any way I was actually wondering
about the memory pinning, do we pin all guest
On 02/19/2013 11:39 AM, Orit Wasserman wrote:
Do you have some results as to the performance cost on demand pinning has?
Yes, there's a single graph on the QEMU wiki that shows this:
http://wiki.qemu.org/Features/RDMALiveMigration
Pay attention to the last group of bars, labelled "A", "B", and
Hi,
Currently migration_bitmap_sync() is very expensive: on the order of
15-20 milliseconds by my count using timestamps (for a simple 2GB ram
virtual machine).
Until new EPT processor versions come out in 2014, we need software
support for cutting this time down much lowerby at least
On 02/21/2013 03:06 PM, Michael S. Tsirkin wrote:
On Mon, Feb 11, 2013 at 05:49:53PM -0500, Michael R. Hines wrote:
From: "Michael R. Hines"
Signed-off-by: Michael R. Hines
---
include/qemu/rdma.h | 281 ++
migration-rdma.c
On 02/21/2013 03:20 PM, Michael S. Tsirkin wrote:
I don't think people mind using RDMA specifically,
small amounts of data can be sent using SEND commands.
But it's cleaner not to use TCP for parts of data.
Understood. Still debating with my co-workers when and how long it will
take to implemen
Oh, that's fantastic - thanks for the response.
- Michael
On 03/01/2013 04:34 AM, Paolo Bonzini wrote:
Il 01/03/2013 00:22, Michael R. Hines ha scritto:te
Hi,
Currently migration_bitmap_sync() is very expensive: on the order of
15-20 milliseconds by my count using timestamps (for a s
Juan,
Can I try this patch that Paolo mentioned?
Does it go directly from GET_LOG_DIRTY => migration_bitmap?
Or is there still an intermediate sync in your patch?
Thanks,
- Michael
On 03/01/2013 04:34 AM, Paolo Bonzini wrote:
Il 01/03/2013 00:22, Michael R. Hines ha scritto:te
Excellent questions: answers inline.
On 03/11/2013 07:51 AM, Michael S. Tsirkin wrote:
+RDMA-based live migration protocol
+==
+
+We use two kinds of RDMA messages:
+
+1. RDMA WRITES (to the receiver)
+2. RDMA SEND (for non-live state, like devices and CPU
will fixacknowledged
On 03/11/2013 09:35 AM, Paolo Bonzini wrote:
Il 11/03/2013 05:33, michael.r.hines.mrhi...@linux.vnet.ibm.com ha scritto:
common-obj-y += migration.o migration-tcp.o
+common-obj-$(CONFIG_RDMA) += migration-rdma.o
common-obj-y += qemu-char.o #aio.o
common-obj-y += b
Acknowledged.
On 03/11/2013 09:40 AM, Paolo Bonzini wrote:
Il 11/03/2013 05:33, michael.r.hines.mrhi...@linux.vnet.ibm.com ha scritto:
From: "Michael R. Hines"
This is the loadvm() side of the connection which is RDMA-aware,
so that transfer of device state can use the same abstr
Acknowledged.
On 03/11/2013 09:40 AM, Paolo Bonzini wrote:
Il 11/03/2013 05:33, michael.r.hines.mrhi...@linux.vnet.ibm.com ha scritto:
From: "Michael R. Hines"
This is the loadvm() side of the connection which is RDMA-aware,
so that transfer of device state can use the same abstr
Yes, I was hoping to see your patch queue pulled already, but I guess
everyone's busy =)
On 03/11/2013 09:41 AM, Paolo Bonzini wrote:
Note that as soon as the pending migration patches hit upstream, almost
all of this code will move to QEMUFileRDMA (in particular qemu_rdma_send
and qemu_rdma_c
Il 11/03/2013 05:33, michael.r.hines.mrhi...@linux.vnet.ibm.com ha scritto:
From: "Michael R. Hines"
Very little changes here except for halting the migration after a maximum
number of iterations is reached.
When comparing against TCP, the migration never ends if we don't cap
the m
Acknowledged all...
On 03/11/2013 09:59 AM, Paolo Bonzini wrote:
Il 11/03/2013 05:33, michael.r.hines.mrhi...@linux.vnet.ibm.com ha scritto:
From: "Michael R. Hines"
For performance reasons, dup_page() and xbzrle() is skipped because
they are too expensive for zero-copy RDMA.
Sig
acknowledged
On 03/11/2013 10:00 AM, Paolo Bonzini wrote:
Il 11/03/2013 05:33, michael.r.hines.mrhi...@linux.vnet.ibm.com ha scritto:
From: "Michael R. Hines"
... want to use existing functions to do this.
Remember that each of the 10 steps should compile and link, both with
a
Understood..will take care of both of these.
On 03/11/2013 10:07 AM, Paolo Bonzini wrote:
Only used in qemu_rdma_init_ram_blocks. Can you add instead an API
like qemu_ram_foreach_block( void (*fn)(void *host_addr, ram_addr_t
offset, ram_addr_t length, void *opaque), void *opaque) ? BTW, ple
On 03/11/2013 01:05 PM, Michael S. Tsirkin wrote:
Well that's exactly the question. As far as I remember the RDMA memory
model, you need to know a key and address to execute RDMA writes.
Remote memory also needs to be locked, so you need some mechanism to
lock chunks of memory, do RDMA write an
Acknowledged.
On 03/11/2013 01:19 PM, Michael S. Tsirkin wrote:
Yes but the document should describe when is the destination memory
registered and how are keys/addresses passed back to source.
1 - 100 of 804 matches
Mail list logo
