On Wed, Dec 10, 2014 at 12:13:34PM +0100, Paolo Bonzini wrote:
> On 09/12/2014 16:54, Richard W.M. Jones wrote:
> > On a slightly related topic, virtio-mmio traps are slow:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1123555
>
> I suspect it's not virtio-mmio, but just KVM on ARM.
>
> It
On 09/12/2014 16:54, Richard W.M. Jones wrote:
> On a slightly related topic, virtio-mmio traps are slow:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1123555
I suspect it's not virtio-mmio, but just KVM on ARM.
It would be nice to have a timing test for vmexits in kvm-unit-tests,
similar to
On Tue, Dec 09, 2014 at 03:47:44PM +, Peter Maydell wrote:
> On 9 December 2014 at 15:41, Laszlo Ersek wrote:
> > Again, this was the idea that Rich had in 2010 (see the links in the
> > discussion thus far). It was rejected back then (which is why I didn't
> > even try to resurrect it now), a
On 9 December 2014 at 15:41, Laszlo Ersek wrote:
> Again, this was the idea that Rich had in 2010 (see the links in the
> discussion thus far). It was rejected back then (which is why I didn't
> even try to resurrect it now), and Peter has now asked if anything has
> changed that would make that a
On 12/09/14 10:31, Gerd Hoffmann wrote:
> Hi,
>
>> So... after playing with this thing for some time, it's become clear
>> that "MMIO traps" are painfully slow on the aarch64 platform we've been
>> working on (using KVM).
>
> So, as we don't have compatibility requirements, and we also can't pl
Hi,
> So... after playing with this thing for some time, it's become clear
> that "MMIO traps" are painfully slow on the aarch64 platform we've been
> working on (using KVM).
So, as we don't have compatibility requirements, and we also can't play
tricks like using x86 string instructions: How
On 11/30/14 17:59, Laszlo Ersek wrote:
> fw_cfg already supports exposure over MMIO (used in ppc/mac_newworld.c,
> ppc/mac_oldworld.c, sparc/sun4m.c); we can easily add it to the "virt"
> board.
>
> The mmio register block of fw_cfg is advertized in the device tree. As
> base address we pick 0x090
On 12/09/14 00:18, Christopher Covington wrote:
> Hi Laszlo,
>
> On 12/08/2014 09:01 AM, Laszlo Ersek wrote:
>> On 11/30/14 17:59, Laszlo Ersek wrote:
>>> fw_cfg already supports exposure over MMIO (used in ppc/mac_newworld.c,
>>> ppc/mac_oldworld.c, sparc/sun4m.c); we can easily add it to the "vi
On 8 December 2014 at 23:18, Christopher Covington wrote:
> Just a thought--would it be possible to add a
> DMA-the-whole-thing-to-this-address register to the simulated device?
That was an idea raised in the 2010 thread that Laszlo mentioned:
http://thread.gmane.org/gmane.comp.emulators.qemu/775
On 12/08/14 22:34, Peter Maydell wrote:
> On 8 December 2014 at 21:19, Laszlo Ersek wrote:
>> So the following in addition makes it work on TCG (x86_64) too:
>>
>> -
>> diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
>> index 7147fea..c2bc44c 100644
>> --- a/hw/nvram/fw_cfg.c
>>
Hi Laszlo,
On 12/08/2014 09:01 AM, Laszlo Ersek wrote:
> On 11/30/14 17:59, Laszlo Ersek wrote:
>> fw_cfg already supports exposure over MMIO (used in ppc/mac_newworld.c,
>> ppc/mac_oldworld.c, sparc/sun4m.c); we can easily add it to the "virt"
>> board.
>>
>> The mmio register block of fw_cfg is
On 8 December 2014 at 21:19, Laszlo Ersek wrote:
> So the following in addition makes it work on TCG (x86_64) too:
>
> -
> diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
> index 7147fea..c2bc44c 100644
> --- a/hw/nvram/fw_cfg.c
> +++ b/hw/nvram/fw_cfg.c
> @@ -31,7 +31,7 @@
> #
On 12/08/14 20:39, Laszlo Ersek wrote:
> On 12/08/14 15:41, Peter Maydell wrote:
>> On 8 December 2014 at 14:01, Laszlo Ersek wrote:
>>> Peter, can we introduce a second, 64-bit wide, data register, for
>>> fw_cfg? (Or even two -- Drew suggested the LDP instruction for the guest.)
>>
>> I don't ha
On 12/08/14 15:41, Peter Maydell wrote:
> On 8 December 2014 at 14:01, Laszlo Ersek wrote:
>> Peter, can we introduce a second, 64-bit wide, data register, for
>> fw_cfg? (Or even two -- Drew suggested the LDP instruction for the guest.)
>
> I don't have an in-principle objection. I do require th
On 8 December 2014 at 14:41, Peter Maydell wrote:
> We also need to make sure it works with TCG QEMU. (64-bit access
> to devices is something we've needed previously in ARM QEMU, so
> though in theory it should work it would need testing.)
"is not something we've needed previously", obviously.
On 8 December 2014 at 14:01, Laszlo Ersek wrote:
> Peter, can we introduce a second, 64-bit wide, data register, for
> fw_cfg? (Or even two -- Drew suggested the LDP instruction for the guest.)
I don't have an in-principle objection. I do require that
whatever mechanism we provide is usable by 32
On 11/30/14 17:59, Laszlo Ersek wrote:
> fw_cfg already supports exposure over MMIO (used in ppc/mac_newworld.c,
> ppc/mac_oldworld.c, sparc/sun4m.c); we can easily add it to the "virt"
> board.
>
> The mmio register block of fw_cfg is advertized in the device tree. As
> base address we pick 0x090
On 12/05/14 19:42, Peter Maydell wrote:
> On 30 November 2014 at 16:59, Laszlo Ersek wrote:
>> fw_cfg already supports exposure over MMIO (used in ppc/mac_newworld.c,
>> ppc/mac_oldworld.c, sparc/sun4m.c); we can easily add it to the "virt"
>> board.
>>
>> The mmio register block of fw_cfg is adve
On 30 November 2014 at 16:59, Laszlo Ersek wrote:
> fw_cfg already supports exposure over MMIO (used in ppc/mac_newworld.c,
> ppc/mac_oldworld.c, sparc/sun4m.c); we can easily add it to the "virt"
> board.
>
> The mmio register block of fw_cfg is advertized in the device tree. As
> base address we
fw_cfg already supports exposure over MMIO (used in ppc/mac_newworld.c,
ppc/mac_oldworld.c, sparc/sun4m.c); we can easily add it to the "virt"
board.
The mmio register block of fw_cfg is advertized in the device tree. As
base address we pick 0x0902, which conforms to the comment preceding
"a15
20 matches
Mail list logo
