> Am 03.08.2015 um 11:20 schrieb Pavel Fedin :
>
> Hello!
>
>>> In order to keep this guest working, we need a possibility to
>>> disable the new MMIO region in qemu. At least to omit it from the
>>> device tree.
>>
>> Yes, this is the workaround, which it sounds like we need.
>
> Ok. Just to
Hello!
> > In order to keep this guest working, we need a possibility to
> > disable the new MMIO region in qemu. At least to omit it from the
> > device tree.
>
> Yes, this is the workaround, which it sounds like we need.
Ok. Just to avoid sending one more version which will be rejected. Wha
On 3 August 2015 at 09:09, Pavel Fedin wrote:
> Hi!
>
>> What I thought you meant was that a non-LPAE kernel didn't
>> work at all if we told it about the high-MMIO window (which
>> would mean we'd need to *not* put that in the dtb if we
>> wanted to avoid breaking non-LPAE guests that didn't car
Hi!
> What I thought you meant was that a non-LPAE kernel didn't
> work at all if we told it about the high-MMIO window (which
> would mean we'd need to *not* put that in the dtb if we
> wanted to avoid breaking non-LPAE guests that didn't care
> about the other window.)
Current generic PCI dri
On 3 August 2015 at 08:03, Pavel Fedin wrote:
> Hi! I have done an additional study...
>
>> (1) We should confirm whether this really is a guest kernel
>> bug (as opposed to the device tree QEMU emits not being
>> in spec)
>> (2) If it is a kernel bug, submit a patch to fix it
>
> It is a bug, b
Hi! I have done an additional study...
> (1) We should confirm whether this really is a guest kernel
> bug (as opposed to the device tree QEMU emits not being
> in spec)
> (2) If it is a kernel bug, submit a patch to fix it
It is a bug, but not major bug. The bug is only that the kernel tries t
Hello! I have studied the problem. It is a kernel bug and it's still not
fixed, at least in 4.1
> (1) We should confirm whether this really is a guest kernel
> bug (as opposed to the device tree QEMU emits not being
> in spec)
The problem is in of_pci_range_to_resource():
http://lxr.free-elec
On Wed, 29 Jul 2015 15:02:00 +0300
Pavel Fedin wrote:
> Hello!
>
> > I don't suggest to have something mapped on top of the window,
> > Suggestion was to just use the same value for
> > AddressMaximum and AddressMinimum arguments in aml_qword_memory() call.
>
> And this will shrink the region
On 29 July 2015 at 13:05, Igor Mammedov wrote:
> Now imagine that guest was started on host with 'old' layout and then has been
> migrated to a host with 'new' layout. Stability of layout matters, that's why
> we support versioned machine types and compat nightmare even if basic machine
> is the s
Hello!
> Now imagine that guest was started on host with 'old' layout and then has been
> migrated to a host with 'new' layout.
Aaarrgghh, yes, i totally forgot about migration. Stupid me...
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
On Wed, 29 Jul 2015 13:03:57 +0300
Pavel Fedin wrote:
> Hello!
>
> > > I'm not sure that ARM architecture has this machine_done callback.
> > Maybe this would help you,
> >git grep machine_done
>
> Heh, i was not patient enough. I have already discovered this by myself, and
> yes, "virt
Hello!
> I don't suggest to have something mapped on top of the window,
> Suggestion was to just use the same value for
> AddressMaximum and AddressMinimum arguments in aml_qword_memory() call.
And this will shrink the region down to zero, right? For what reason? Physical
region would still
be
On Wed, 29 Jul 2015 12:48:18 +0300
Pavel Fedin wrote:
> Hello!
>
> > this is wrong since dword is too small for values of high memory
> > use aml_qword_memory() instead
>
> Thanks, will fix it.
>
> > since window is at fixed position and it's not possible for guest to
> > move base address o
On 29 July 2015 at 12:16, Pavel Fedin wrote:
>> I don't really want to have two different address layouts
>> just to work around a kernel bug
>
> They will not be really different. Just for 32-bit machines
> there will be no second MMIO window, and for 64-bit ones there
> will be. Nothing else wi
Hello!
> It matters because you can run 32 bit guests in 64-bit-capable
> CPUs.
Yes, i know.
> I don't really want to have two different address layouts
> just to work around a kernel bug
They will not be really different. Just for 32-bit machines there will be no
second MMIO window, and fo
On 29 July 2015 at 11:03, Pavel Fedin wrote:
>> Also in light of guests with huge memory size, 512Gb gap for RAM seems too
>> small,
>> what are limitations of ARM64 regarding max supported physical address bits?
>
> 40 bits IIRC.
In hardware, implemented maximum physical address size may be
Hello!
> > I'm not sure that ARM architecture has this machine_done callback.
> Maybe this would help you,
>git grep machine_done
Heh, i was not patient enough. I have already discovered this by myself, and
yes, "virt" uses the
same mechanism. But, still, i perhaps can have problems with
On 29 July 2015 at 10:45, Pavel Fedin wrote:
>> > because i discovered problems with 32-bit guests. They simply truncate
>> > high word and end up in attempt to put PCI at 0x - 0x,
>> > fail,
>> > and do not work of course. So, my next version will have high MMIO
>> > only for 64-
Hello!
> this is wrong since dword is too small for values of high memory
> use aml_qword_memory() instead
Thanks, will fix it.
> since window is at fixed position and it's not possible for guest to
> move base address of the range, make AddressMaximum the same as
> AddressMinimum i.e.
But
> > because i discovered problems with 32-bit guests. They simply truncate
> > high word and end up in attempt to put PCI at 0x - 0x, fail,
> > and do not work of course. So, my next version will have high MMIO
> > only for 64-bit guests.
>
> That sounds like a guest bug to me. If
On Wed, 29 Jul 2015 11:58:11 +0300
Pavel Fedin wrote:
> Hello!
>
> > I'm not sure but fixed hole start/size might be a problem later when
> > adding memory hotplug
> wasting
> > address space.
>
> But 'virt' machine entirely relies on fixed layout. And, we can always
> change it if we need
On Mon, 27 Jul 2015 14:09:28 +0300
Pavel Fedin wrote:
> @@ -234,6 +236,12 @@ static void acpi_dsdt_add_pci(Aml *scope, const
> MemMapEntry *memmap, int irq)
> AML_ENTIRE_RANGE, 0x, 0x, size_pio - 1,
> base_pio,
> size_pio));
>
> +aml_app
On 29 July 2015 at 09:58, Pavel Fedin wrote:
> So, can we leave fixed layout for now? I am currently reworking the patch
> because i discovered problems with 32-bit guests. They simply truncate
> high word and end up in attempt to put PCI at 0x - 0x, fail,
> and do not work of cou
Hello!
> I'm not sure but fixed hole start/size might be a problem later when adding
> memory hotplug
wasting
> address space.
But 'virt' machine entirely relies on fixed layout. And, we can always change
it if we need to.
>
> On x86 we do it a little different, see call chain:
> acpi_set
On 27 July 2015 at 16:18, Michael S. Tsirkin wrote:
> It's more a question of figuring out what does real hardware do.
> It's true, PIIX has this "everything that isn't memory is PCI"
> assumption. We do this for Q35 but I'm not even sure it's the
> right thing to do there.
>
> If as you say real
On Mon, Jul 27, 2015 at 05:36:07PM +0300, Pavel Fedin wrote:
> Hello!
>
> > > +/* High MMIO space */
> > > +mmio_alias = g_new0(MemoryRegion, 1);
> > > +memory_region_init_alias(mmio_alias, OBJECT(dev), "pcie-mmio-high",
> > > + mmio_reg, base_mmio_high, si
Hello!
> > +/* High MMIO space */
> > +mmio_alias = g_new0(MemoryRegion, 1);
> > +memory_region_init_alias(mmio_alias, OBJECT(dev), "pcie-mmio-high",
> > + mmio_reg, base_mmio_high, size_mmio_high);
> > +memory_region_add_subregion(get_system_memory(),
On Mon, 27 Jul 2015 14:09:28 +0300
Pavel Fedin wrote:
> This large region is necessary for some devices like ivshmem and video cards
>
> Signed-off-by: Pavel Fedin
> ---
> Changes since v2:
> - Region size increased to 512G
> - Added ACPI description
> Changes since v1:
> - Region address chang
This large region is necessary for some devices like ivshmem and video cards
Signed-off-by: Pavel Fedin
---
Changes since v2:
- Region size increased to 512G
- Added ACPI description
Changes since v1:
- Region address changed to 512G, leaving more space for RAM
---
hw/arm/virt-acpi-build.c | 8
29 matches
Mail list logo
