On 08/01/2014 09:19 AM, Paolo Bonzini wrote:
> Il 01/08/2014 16:02, Joel Schopp ha scritto:
I think the patch is right but, besides these considerations, does this
bug still manifest itself after Andrew fixed the start address of the
device at 0x9001 (IIRC it was the pl031)?
>>
> I agree.
>
> I think the patch is right but, besides these considerations, does this
> bug still manifest itself after Andrew fixed the start address of the
> device at 0x9001 (IIRC it was the pl031)?
The device I see with that address is:
hw/arm/virt.c:[VIRT_RTC] = { 0x9001, 0x1000
Il 01/08/2014 16:02, Joel Schopp ha scritto:
>> >
>> > I think the patch is right but, besides these considerations, does this
>> > bug still manifest itself after Andrew fixed the start address of the
>> > device at 0x9001 (IIRC it was the pl031)?
> The device I see with that address is:
> hw/
Il 01/08/2014 13:28, Peter Maydell ha scritto:
> Paolo: can you review this? Do we also need to do something
> about the use of TARGET_PAGE_BITS in
> kvm_physical_sync_dirty_bitmap?
No, it should be the host page size, matching
cpu_physical_memory_set_dirty_lebitmap.
> Is it really OK to define
>
On 23 July 2014 21:09, Joel Schopp wrote:
> kvm_set_phys_mem doesn't work on arm64 with memory > 1GB. It exits with:
> kvm_set_phys_mem: error registering slot: Invalid argument
>
> An example of the failing address and size are start_addr == 0x90011000
> and size=0xaffef000. As you can see both
kvm_set_phys_mem doesn't work on arm64 with memory > 1GB. It exits with:
kvm_set_phys_mem: error registering slot: Invalid argument
An example of the failing address and size are start_addr == 0x90011000
and size=0xaffef000. As you can see both of these are 4K aligned, not
64K aligned.
At 1024M
