All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joao Martins <joao.m.martins@oracle.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: qemu-devel@nongnu.org, Eduardo Habkost <eduardo@habkost.net>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Daniel Jordan <daniel.m.jordan@oracle.com>,
	David Edmondson <david.edmondson@oracle.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>, Ani Sinha <ani@anisinha.ca>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Subject: Re: [PATCH v5 4/5] i386/pc: relocate 4g start to 1T where applicable
Date: Fri, 17 Jun 2022 14:33:02 +0100	[thread overview]
Message-ID: <4f3e051e-fb13-5860-b39f-5ace782cdea0@oracle.com> (raw)
In-Reply-To: <20220617143251.5f064694@redhat.com>

On 6/17/22 13:32, Igor Mammedov wrote:
> On Fri, 17 Jun 2022 13:18:38 +0100
> Joao Martins <joao.m.martins@oracle.com> wrote:
>> On 6/16/22 15:23, Igor Mammedov wrote:
>>> On Fri, 20 May 2022 11:45:31 +0100
>>> Joao Martins <joao.m.martins@oracle.com> wrote:
>>>> +                                hwaddr above_4g_mem_start,
>>>> +                                uint64_t pci_hole64_size)
>>>> +{
>>>> +    PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
>>>> +    X86MachineState *x86ms = X86_MACHINE(pcms);
>>>> +    MachineState *machine = MACHINE(pcms);
>>>> +    ram_addr_t device_mem_size = 0;
>>>> +    hwaddr base;
>>>> +
>>>> +    if (!x86ms->above_4g_mem_size) {
>>>> +       /*
>>>> +        * 32-bit pci hole goes from
>>>> +        * end-of-low-ram (@below_4g_mem_size) to IOAPIC.
>>>> +        */
>>>> +        return IO_APIC_DEFAULT_ADDRESS - 1;  
>>>
>>> lack of above_4g_mem, doesn't mean absence of device_mem_size or anything else
>>> that's located above it.
>>>   
>>
>> True. But the intent is to fix 32-bit boundaries as one of the qtests was failing
>> otherwise. We won't hit the 1T hole, hence a nop.
> 
> I don't get the reasoning, can you clarify it pls?
> 

I was trying to say that what lead me here was a couple of qtests failures (from v3->v4).

I was doing this before based on pci_hole64. phys-bits=32 was for example one
of the test failures, and pci-hole64 sits above what 32-bit can reference.

>>  Unless we plan on using
>> pc_max_used_gpa() for something else other than this.
> 
> Even if '!above_4g_mem_sizem', we can still have hotpluggable memory region
> present and that can  hit 1Tb. The same goes for pci64_hole if it's configured
> large enough on CLI.
> 
So hotpluggable memory seems to assume it sits above 4g mem.

pci_hole64 likewise as it uses similar computations as hotplug.

Unless I am misunderstanding something here.

> Looks like guesstimate we could use is taking pci64_hole_end as max used GPA
> 
I think this was what I had before (v3[0]) and did not work.

Let me revisit this edge case again.

[0] https://lore.kernel.org/all/20220223184455.9057-5-joao.m.martins@oracle.com/


  reply	other threads:[~2022-06-17 13:34 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-20 10:45 [PATCH v5 0/5] i386/pc: Fix creation of >= 1010G guests on AMD systems with IOMMU Joao Martins
2022-05-20 10:45 ` [PATCH v5 1/5] hw/i386: add 4g boundary start to X86MachineState Joao Martins
2022-06-16 13:05   ` Igor Mammedov
2022-06-17 10:57     ` Joao Martins
2022-05-20 10:45 ` [PATCH v5 2/5] i386/pc: create pci-host qdev prior to pc_memory_init() Joao Martins
2022-06-16 13:21   ` Reviewed-by: Igor Mammedov
2022-06-17 11:03     ` Joao Martins
2022-06-20  7:12     ` Mark Cave-Ayland
2022-05-20 10:45 ` [PATCH v5 3/5] i386/pc: pass pci_hole64_size " Joao Martins
2022-06-16 13:30   ` Igor Mammedov
2022-06-16 14:16     ` Michael S. Tsirkin
2022-06-17 11:13     ` Joao Martins
2022-06-17 11:58       ` Igor Mammedov
2022-05-20 10:45 ` [PATCH v5 4/5] i386/pc: relocate 4g start to 1T where applicable Joao Martins
2022-06-16 14:23   ` Igor Mammedov
2022-06-17 12:18     ` Joao Martins
2022-06-17 12:32       ` Igor Mammedov
2022-06-17 13:33         ` Joao Martins [this message]
2022-06-20 14:27           ` Igor Mammedov
2022-06-20 16:36             ` Joao Martins
2022-06-20 18:13               ` Joao Martins
2022-06-28 12:38                 ` Igor Mammedov
2022-06-28 15:27                   ` Joao Martins
2022-06-17 16:12       ` Joao Martins
2022-05-20 10:45 ` [PATCH v5 5/5] i386/pc: restrict AMD only enforcing of valid IOVAs to new machine type Joao Martins
2022-06-16 14:27   ` Igor Mammedov
2022-06-17 13:36     ` Joao Martins
2022-06-08 10:37 ` [PATCH v5 0/5] i386/pc: Fix creation of >= 1010G guests on AMD systems with IOMMU Joao Martins
2022-06-22 22:37 ` Alex Williamson
2022-06-22 23:18   ` Joao Martins
2022-06-23 16:03     ` Alex Williamson
2022-06-23 17:13       ` Joao Martins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4f3e051e-fb13-5860-b39f-5ace782cdea0@oracle.com \
    --to=joao.m.martins@oracle.com \
    --cc=alex.williamson@redhat.com \
    --cc=ani@anisinha.ca \
    --cc=daniel.m.jordan@oracle.com \
    --cc=david.edmondson@oracle.com \
    --cc=eduardo@habkost.net \
    --cc=imammedo@redhat.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=suravee.suthikulpanit@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.