Il 14/07/2014 04:42, Fam Zheng ha scritto:
On Tue, 06/10 14:55, Fam Zheng wrote:
> In the case that the lun number is taken by another scsi device, don't
> release the existing device siliently, but report an error to user.
>
> Signed-off-by: Fam Zheng
Do we want this in 2.1?
Fam
Yes, than
Il 13/07/2014 18:17, Alexander Graf ha scritto:
The NVRAM in our Core99 machine really supports 2byte and 4byte accesses
just as well as 1byte accesses. In fact, Mac OS X uses those.
Add support for higher register size granularities.
Signed-off-by: Alexander Graf
---
hw/nvram/mac_nvram.c | 4
On 07/03/2014 05:11 PM, Markus Armbruster wrote:
> Alexey Kardashevskiy writes:
>
>> On 06/23/2014 11:32 PM, Alexey Kardashevskiy wrote:
>>> On 06/16/2014 06:37 PM, Alexander Graf wrote:
On 16.06.14 10:33, Alexey Kardashevskiy wrote:
> On 06/16/2014 05:16 PM, Cornelia Huck wrote:
>>
On Mon, Jul 14, 2014 at 12:41:08AM +1000, Alexey Kardashevskiy wrote:
> Current object_child_foreach() uses QTAILQ_FOREACH() to walk
> through children and that makes children removal from the callback
> impossible.
>
> This makes object_child_foreach() use QTAILQ_FOREACH_SAFE().
>
> Signed-off-b
On Sat, Jul 12, 2014 at 11:17:40AM +0800, Liu Yuan wrote:
> Cc: Kevin Wolf
> Signed-off-by: Liu Yuan
> ---
> configure | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 7dd43fd..78e7baf 100755
> --- a/configure
> +++ b/configure
> @@ -3996,7
On Sat, 07/12 11:17, Liu Yuan wrote:
> Cc: Kevin Wolf
> Signed-off-by: Liu Yuan
> ---
> configure | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 7dd43fd..78e7baf 100755
> --- a/configure
> +++ b/configure
> @@ -3996,7 +3996,7 @@ if test "$
On Tue, 06/10 14:55, Fam Zheng wrote:
> In the case that the lun number is taken by another scsi device, don't
> release the existing device siliently, but report an error to user.
>
> Signed-off-by: Fam Zheng
Do we want this in 2.1?
Fam
> ---
> hw/scsi/scsi-bus.c | 3 ++-
> 1 file changed, 2
We currently calculate the final RTAS and FDT location based on
the early estimate of the RMA size, cropped to 256M on KVM since
we only know the real RMA size at reset time which happens much
later in the boot process.
This means the FDT and RTAS end up right below 256M while they
could be much h
A subsequent patch to ppc/spapr needs to load the RTAS blob into
qemu memory rather than target memory (so it can later be copied
into the right spot at machine reset time).
I would use load_image() but it is marked deprecated because it
doesn't take a buffer size as argument, so let's add load_im
A subsequent patch to ppc/spapr needs to load the RTAS blob into
qemu memory rather than target memory (so it can later be copied
into the right spot at machine reset time).
I would use load_image() but it is marked deprecated because it
doesn't take a buffer size as argument, so let's add load_i
> -Original Message-
> From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> Sent: Friday, July 11, 2014 9:04 PM
> To: Wangkai (Kevin,C)
> Cc: qemu-devel@nongnu.org; aligu...@amazon.com; Lee yang
> Subject: Re: [PATCH] Tap: fix vcpu long time io blocking on tap
>
> On Fri, Jul 11, 2014 at
On 13 July 2014 23:26, Michael S. Tsirkin wrote:
> On Wed, Jul 09, 2014 at 06:06:32PM +0300, Nikolay Nikolaev wrote:
>> Mising G_TIME_SPAN_SECOND definition breaks the RHEL6 compilation as GLib
>> version before 2.26 does not have it. In such case just define it.
>>
>> Reported-by: Kevin Wolf
>>
On Mon, Jul 14, 2014 at 01:26:34AM +0300, Michael S. Tsirkin wrote:
> On Wed, Jul 09, 2014 at 06:06:32PM +0300, Nikolay Nikolaev wrote:
> > Mising G_TIME_SPAN_SECOND definition breaks the RHEL6 compilation as GLib
> > version before 2.26 does not have it. In such case just define it.
> >
> > Repor
On Wed, Jul 09, 2014 at 06:06:32PM +0300, Nikolay Nikolaev wrote:
> Mising G_TIME_SPAN_SECOND definition breaks the RHEL6 compilation as GLib
> version before 2.26 does not have it. In such case just define it.
>
> Reported-by: Kevin Wolf
> Signed-off-by: Nikolay Nikolaev
Applied, thanks!
> --
We already expose the real CPU's tb frequency to the guest via fw_cfg. Soon
we will need to also expose it to the MacIO, so let's move it to a variable
that we can leverage every time we need the frequency.
Signed-off-by: Alexander Graf
---
hw/ppc/mac_newworld.c | 13 ++---
hw/ppc/mac_ol
Mac OS X calibrates a number of frequencies on bootup based on reading
tb values on bootup and comparing them to via cuda timer values.
The only variable we can really steer well (thanks to KVM) is the cuda
frequency. So let's use that one to fake Mac OS X into believing the
bus frequency is tbfre
Hi,
I developed a software in the loop simulator for the Lego Mindstorms NXT
brick. It uses the Qemu ARM emulator to run the Robot's Firmware. I plan
to release the simulator as an open source project. Now, I wonder if it
makes sense to integrate the Qemu board implementation back into Qemu
m
> Am 13.07.2014 um 19:51 schrieb Programmingkid :
>
>
>> On Jul 13, 2014, at 12:17 PM, Alexander Graf wrote:
>>
>> While trying to get Mac OS X booting with our -M mac99 emulation I stumbled
>> over a few issues that prevented it from doing so.
>>
>> With these patches applied I still can't p
On Jul 13, 2014, at 12:17 PM, Alexander Graf wrote:
> While trying to get Mac OS X booting with our -M mac99 emulation I stumbled
> over a few issues that prevented it from doing so.
>
> With these patches applied I still can't properly boot Mac OS X with -M mac99,
> but I get a lot further than
Mac OS X (at least with -M mac99) searches for a valid NVRAM partition
of a special Apple type. If it can't find that partition in the first
half of NVRAM, it will look at the second half.
There are a few implications from this. The first is that we need to
split NVRAM into 2 halves - one for Open
The mac99 machine really doesn't have any shifts in NVRAM usage. It simply has
a 1:1 MMIO mapped space where a guest can access the NVRAM data.
This patch fixes up the incorrect format we use for NVRAM today, making Mac OS
X happy and able to read NVRAM.
This patch also requires a new OpenBIOS ve
There is a special timer in the mac99 machine that we recently started
to emulate. Unfortunately we emulated it in the wrong frequency.
This patch adapts the frequency Mac OS X uses to evaluate results from
this timer, making calculations it bases off of it work.
Signed-off-by: Alexander Graf
--
The macio_nvram_read and macio_nvram_write functions are never called,
just remove them.
Signed-off-by: Alexander Graf
---
hw/nvram/mac_nvram.c | 23 ---
hw/ppc/mac.h | 2 --
2 files changed, 25 deletions(-)
diff --git a/hw/nvram/mac_nvram.c b/hw/nvram/mac_nvram.c
i
While trying to get Mac OS X booting with our -M mac99 emulation I stumbled
over a few issues that prevented it from doing so.
With these patches applied I still can't properly boot Mac OS X with -M mac99,
but I get a lot further than before. The biggest issue that's left now is to
properly fake M
The NVRAM in our Core99 machine really supports 2byte and 4byte accesses
just as well as 1byte accesses. In fact, Mac OS X uses those.
Add support for higher register size granularities.
Signed-off-by: Alexander Graf
---
hw/nvram/mac_nvram.c | 43 ---
1 f
On Sun, Jul 13, 2014 at 4:28 PM, Andrey Korolyov wrote:
> Hello,
>
> the issue is not specific to the iothread code because generic
> virtio-blk also hangs up:
>
> Given code set like in the
> http://www.mail-archive.com/qemu-devel@nongnu.org/msg246164.html,
> launch a VM with virtio-blk disk and
Current object_child_foreach() uses QTAILQ_FOREACH() to walk
through children and that makes children removal from the callback
impossible.
This makes object_child_foreach() use QTAILQ_FOREACH_SAFE().
Signed-off-by: Alexey Kardashevskiy
---
The problem I am trying to solve is:
there is a PHB wi
On Fri, Jul 11, 2014 at 4:28 AM, Alvise Rigo
wrote:
> The kernel version is a very recent one: v3.16.0-rc1.
> Maybe you are right. I will test some older version to see if I'm able
> to reproduce the issue.
BTW, the lsi driver has compile time option to use i/o or memory
accesses. I usually test
Hello,
the issue is not specific to the iothread code because generic
virtio-blk also hangs up:
Given code set like in the
http://www.mail-archive.com/qemu-devel@nongnu.org/msg246164.html,
launch a VM with virtio-blk disk and writeback rbd backend, fire up
fio, migrate once with libvirt:
time vi
29 matches
Mail list logo
