On Mon, Apr 11, 2016 at 9:56 AM, Raghavendra Gowdappa
wrote:
>
> > +Raghavendra G who implemented this option in write-behind, to this
> > upstream patch review discussion
>
> Thanks Pranith. Kritika did inform us about the discussion. We were
> working on ways to find out solutions to the proble
On Thu, May 05, 2016 at 12:29:13PM +0300, David Kiarie wrote:
> On Thu, May 5, 2016 at 6:25 AM, Peter Xu wrote:
> > Moves acpi_get_iommu() under VT-d to make it a public function.
> >
> > Signed-off-by: Peter Xu
> > ---
> > hw/i386/acpi-build.c | 7 +--
> > hw/i386/intel_iommu.c
Hi
I am doing host to vm communication and and launched the VM as below-
qemu-system-x86_64 -m 1024 -smp 3 -cpu host -hda
/var/lib/libvirt/images/GuestImage.img -boot c -enable-kvm -pidfile
/tmp/GuestImage.pid -monitor unix:/tmp/gmmonitor,server,nowait -name
'GuestImage' -net none
On Fri, May 06, 2016 at 10:53:44PM +0200, Radim Krčmář wrote:
> This series bases on Peter's IR v6 and depends on patches that were just
> posted to kvm-list, "[RFC 0/9] KVM: x86: break the xAPIC barrier".
>
> The kernel interface could use your comments, but internal QEMU one is
> in dire need of
On Thu, May 05, 2016 at 11:35:43AM +0200, Jan Kiszka wrote:
> On 2016-05-05 05:25, Peter Xu wrote:
> > Previously, there are lots of VT-d hooks in common codes (like q35,
> > ioapic, etc.). A better way is to avoid using VT-d interfaces. Also, we
> > can start to abstract some common functions betw
On Mon, Apr 04, 2016 at 02:27:24PM +1000, David Gibson wrote:
> On Thu, Mar 31, 2016 at 02:09:21PM +0530, Bharata B Rao wrote:
> > Remove the CPU core device by removing the underlying CPU thread devices.
> > Hot removal of CPU for sPAPR guests is achieved by sending the hot unplug
> > notification
Hi Suzuki/Peter,
On Wed, Apr 13, 2016 at 5:59 PM, Suzuki K Poulose
wrote:
> On 13/04/16 10:54, Vijay Kilari wrote:
>>
>> On Mon, Apr 11, 2016 at 3:07 PM, Suzuki K Poulose
>> wrote:
>>>
>>> On 11/04/16 07:52, Vijay Kilari wrote:
>
>
>>
>> Hi Suzuki,
>>
>> The last 5 patches are not compiling on
And if this is not clear - in all cases everything was OK when emulation was
started without -smp cors=2 or 3 or 4. By OK i mean there was no
qemu: fatal: Trying to execute code outside RAM or ROM at 0x
errors and I was able to execute some comands like help and printenv and
nothing hap
Yes, there are still problems on qemu 2.6.0 release candidate and 2.5.1
with same version of u-boot as mentioned and with latest stable u-boot
release. When qemu has parameter -smp cores=2 or 3 or 4.
errors are:
qemu: fatal: Trying to execute code outside RAM or ROM at 0x31306c70
That adress chang
Sorry, missed '-' character at the end of command obviously. It shaould
be:
$ make vexpress_ca9x4_defconfig ARCH=arm CROSS_COMPILE=arm-none-eabi-
$ make all_ca9x4_defconfig ARCH=arm CROSS_COMPILE=arm-none-eabi-
--
You received this bug notification because you are a member of qemu-
devel-ml,
thanks for the infos
Stefan i will check tomorrow and report.
Peter, yes this is an issue of the powerpc64 of ubuntu/debian the ppc64
libraries are half ported usually i fix changing in the makefile -m32 where
-m64 is call i will try to force the flags on configure of qemu too. i will
report
The problem could also be that your build environment is broken in the
way the warning is trying to diagnose (for instance that you have the
32-bit PPC glib development packages installed and not the 64-bit ones.)
--
You received this bug notification because you are a member of qemu-
devel-ml, w
Please try this patch: http://patchwork.ozlabs.org/patch/616440/
** Changed in: qemu
Status: New => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1579565
Title:
ERROR: sizeof(
Public bug reported:
cont build from last 2.6 rc4
~/Downloads/qemu-2.6.0-rc4$ ./configure
ERROR: sizeof(size_t) doesn't match GLIB_SIZEOF_SIZE_T.
You probably need to set PKG_CONFIG_LIBDIR
to point to the right pkg-config files for your
build target
Os Ubuntu Mate 16.04 PPC
This adds the ENET device to the i.MX6 SOC.
This was tested by booting Linux on an Qemu i.MX6 instance and accessing
the internet from the linux guest.
Reviewed-by: Peter Maydell
Signed-off-by: Jean-Christophe Dubois
---
Changes since v1:
* Not present on v1
Changes since v2:
* None
hw
The ENET device (present in i.MX6) is "derived" from FEC and backward
compatible with it.
This patch adds the necessary support of the added feature in the ENET
device to allow Linux to use it (on supported processors).
Signed-off-by: Jean-Christophe Dubois
---
Changes since v1:
* Not present
This is to prepare for the ENET Gb device of the i.MX6.
Signed-off-by: Jean-Christophe Dubois
---
Changes since v1:
* Not present on v1.
Changes since v2:
* The patch was split in 2 parts:
- a "port" to a reg array based device (this patch).
- the addition of the Gb support (next patc
* based on Eth, UDP, TCP struct present in eth.h instead of hardcoded
indexes and sizes.
* based on various macros present in eth.h.
Signed-off-by: Jean-Christophe Dubois
---
Changes since v1:
* None
Changes since v2:
* The patch was split in 2 parts:
- a rewrite of the TCP/UDB chec
This patch series adds Gb ENET Ethernet device to the i.MX6 SOC.
The ENET device is an evolution of the FEC device present on the i.MX25 SOC
and is backward compatible with it.
Therefore the ENET support has been added to the actual Qemu FEC device (
rather than adding a new device).
The Patch h
Signed-off-by: Jean-Christophe Dubois
---
Changes since v1:
* Not present on v1
Changes since v2:
* Not present on v2
net/checksum.c | 35 +++
1 file changed, 31 insertions(+), 4 deletions(-)
diff --git a/net/checksum.c b/net/checksum.c
index f62b18a..8acd99
On Mon, 25 Apr 2016 17:04:41 +0100
"Richard W.M. Jones" wrote:
> From: Marc Marí
>
> This optionrom is based on linuxboot.S.
>
> Signed-off-by: Marc Marí
> Signed-off-by: Richard W.M. Jones
> ---
> .gitignore| 4 +
> hw/i386/pc.c | 10 +-
> hw
On Sun, 8 May 2016 20:22:53 +0200
Marc Marí wrote:
> On Mon, 25 Apr 2016 13:46:08 +0100
> Stefan Hajnoczi wrote:
>
> > Signed-off-by: Stefan Hajnoczi
> > ---
> > tests/libqos/virtio.c | 19 ++-
> > tests/libqos/virtio.h | 9 -
> > tests/virtio-blk-test.c | 5 +++-
On Mon, 25 Apr 2016 13:46:08 +0100
Stefan Hajnoczi wrote:
> Signed-off-by: Stefan Hajnoczi
> ---
> tests/libqos/virtio.c | 19 ++-
> tests/libqos/virtio.h | 9 -
> tests/virtio-blk-test.c | 5 +++--
> 3 files changed, 13 insertions(+), 20 deletions(-)
>
> diff --g
On 8 May 2016 at 10:07, Laurent Vivier wrote:
> But I didn't really care here of the page faults because m68k only
> supports non privileged instructions: coldfire is used in semi-hosting
> mode (no MMU) and 680x0-like machine has no hardware (I use it in
> linux-user mode).
It does still affect
Le 07/05/2016 à 23:50, Peter Maydell a écrit :
> On 7 May 2016 at 20:01, Laurent Vivier wrote:
>>
>>
>> Le 07/05/2016 à 00:00, Richard Henderson a écrit :
>>> On 05/04/2016 11:21 AM, Laurent Vivier wrote:
+reg = AREG(insn, 0);
+src = gen_load(s, opsize, reg, 1);
+tcg_g
On 05/06/2016 03:34 PM, Dr. David Alan Gilbert (git) wrote:
From: "Dr. David Alan Gilbert"
This is a postcopy test (x86 only) that actually runs the guest
and checks the memory contents.
The test runs from an x86 boot block with the hex embedded in the test;
the source for this is:
..
26 matches
Mail list logo