search for: msg00584

On Fri, 2014-09-05 at 13:39 +0200, trenta wrote: > Additional information: > http://lists.xen.org/archives/html/xen-devel/2013-09/msg00584.html This thread suggests that mmconfig might be the issue, in which case does adding "mmcfg=0" to your hypervisor command line help? I'd recommend continuing to pursue this upstream, there are far more experts on the low level aspect of things there. Ian.

...e solved? - Can I use for production environment this configuration? Thanks 2014-09-05 15:56 GMT+02:00 Ian Campbell <ijc at hellion.org.uk>: > On Fri, 2014-09-05 at 13:39 +0200, trenta wrote: >> Additional information: >> http://lists.xen.org/archives/html/xen-devel/2013-09/msg00584.html > > This thread suggests that mmconfig might be the issue, in which case > does adding "mmcfg=0" to your hypervisor command line help? > > I'd recommend continuing to pursue this upstream, there are far more > experts on the low level aspect of things there. &gt...

...rks. Also tried with citrix 6.2 and during install server was rebooted Error verified with Debian 7 and xen 4.1, Debian 8 and xen.4.4. Attached additional information about errors reportes by IBM AMM (files attached) Additional information: http://lists.xen.org/archives/html/xen-devel/2013-09/msg00584.html

...rty memory information back and forth, so that migration is > not prevented > * sending interrupts to a device > * setting up ring buffers in the shared memory Yes, I do agree that it is promising. And of course some tests are here: https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg00584.html for some of the bullets you are listing (not all yet). > Also, vhost-user is documented! See here: > https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg00581.html as I told you, we'll send a contribution with ivshmem's documentation. > The only part of ivshmem that vh...

Hello everybody, i've defined a simple network, with no dhcp. I'd like to use dnsmasq only as a dns server. $ virsh net-dumpxml basicswitch <network> <name>basicswitch</name> <uuid>60f491d2-d6c4-6b57-8a50-081cace8dedc</uuid> <forward mode='nat'/> <bridge name='virbr1' stp='on' delay='0' /> <ip

Il 13/06/2014 15:41, Vincent JARDIN ha scritto: >> Fine, however Red Hat would also need a way to test ivshmem code, with >> proper quality assurance (that also benefits upstream, of course). With >> ivshmem this is not possible without the out-of-tree packages. > > You did not reply to my question: how to get the list of things that > are/will be disabled by Redhat? I

Il 13/06/2014 15:41, Vincent JARDIN ha scritto: >> Fine, however Red Hat would also need a way to test ivshmem code, with >> proper quality assurance (that also benefits upstream, of course). With >> ivshmem this is not possible without the out-of-tree packages. > > You did not reply to my question: how to get the list of things that > are/will be disabled by Redhat? I

Il 13/06/2014 11:26, Vincent JARDIN ha scritto: >> Markus especially referred to parts *outside* QEMU: the server, the >> uio driver, etc. These out-of-tree, non-packaged parts of ivshmem >> are one of the reasons why Red Hat has disabled ivshmem in RHEL7. > > You made the right choices, these out-of-tree packages are not required. > You can use QEMU's ivshmem

Il 13/06/2014 11:26, Vincent JARDIN ha scritto: >> Markus especially referred to parts *outside* QEMU: the server, the >> uio driver, etc. These out-of-tree, non-packaged parts of ivshmem >> are one of the reasons why Red Hat has disabled ivshmem in RHEL7. > > You made the right choices, these out-of-tree packages are not required. > You can use QEMU's ivshmem