qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>,
	qemu-devel@nongnu.org,
	"Daniel Henrique Barboza" <danielhb413@gmail.com>
Subject: Re: [Qemu-devel] [PATCH qemu v2] hmp: Print if memory section is registered with an accelerator
Date: Wed, 24 Apr 2019 15:32:34 +1000	[thread overview]
Message-ID: <aca6d2ae-806f-55b3-d9d5-f5a2cfd760b9@ozlabs.ru> (raw)
In-Reply-To: <f346fdcb-1849-3397-7f4c-2d6ee07fcd7c@ozlabs.ru>

Paolo, ping?


On 19/03/2019 18:05, Alexey Kardashevskiy wrote:
> 
> 
> On 11/02/2019 15:56, Alexey Kardashevskiy wrote:
>>
>>
>> On 09/02/2019 04:26, Paolo Bonzini wrote:
>>> On 07/02/19 12:49, Dr. David Alan Gilbert wrote:
>>>>  //#define DEBUG_UNASSIGNED
>>>> @@ -2924,6 +2926,8 @@ struct FlatViewInfo {
>>>>      int counter;
>>>>      bool dispatch_tree;
>>>>      bool owner;
>>>> +    AccelClass *ac;
>>>> +    const char *ac_name;
>>>>  };
>>>>  
>>>>  static void mtree_print_flatview(gpointer key, gpointer value,
>>>> @@ -2939,6 +2943,7 @@ static void mtree_print_flatview(gpointer key, gpointer value,
>>>>      int n = view->nr;
>>>>      int i;
>>>>      AddressSpace *as;
>>>> +    bool system_as = false;
>>>>  
>>>>      p(f, "FlatView #%d\n", fvi->counter);
>>>>      ++fvi->counter;
>>>> @@ -2950,6 +2955,9 @@ static void mtree_print_flatview(gpointer key, gpointer value,
>>>>              p(f, ", alias %s", memory_region_name(as->root->alias));
>>>>          }
>>>>          p(f, "\n");
>>>> +        if (as == &address_space_memory) {
>>>> +            system_as = true;
>>>> +        }
>>>>      }
>>>>  
>>>>      p(f, " Root memory region: %s\n",
>>>> @@ -2985,6 +2993,13 @@ static void mtree_print_flatview(gpointer key, gpointer value,
>>>>          if (fvi->owner) {
>>>>              mtree_print_mr_owner(p, f, mr);
>>>>          }
>>>> +
>>>> +        if (system_as && fvi->ac &&
>>>> +            fvi->ac->has_memory(current_machine,
>>>> +                                int128_get64(range->addr.start),
>>>> +                                MR_SIZE(range->addr.size) + 1)) {
>>>> +            p(f, " %s", fvi->ac_name);
>>>
>>> I don't understand this.  This doesn't check that the memory range
>>> actually matches the memory registered with the accelerator, only that
>>> there is something in that range. 
>>
>>
>> It is checking that a flat range (i.e. what actually works) has a
>> corresponding KVM slot:
>> https://git.qemu.org/?p=qemu.git;a=blob;f=accel/kvm/kvm-all.c;h=4e1de942ce554c734ac2673030031c228a752ac9;hb=HEAD#l201
>>
>>
>>> Why isn't it enough to use "info
>>> mtree" and look at the KVM address space?
>>
>>
>> There is no such thing in my QEMU, did you mean "KVM-SMRAM" (which is
>> missing on spapr)? I am not sure I understand its purpose for the task -
>> it prints all same ranges on my x86 laptop, not just ones which we told
>> KVM about.
>>
>> My task is that if let's say "0000:00:1a.0 BAR 0 mmaps[0]" is split into
>> several sections because MSIX happens to be in a middle of that BAR and
>> it is not system page size aligned, then it is going to be several
>> ranges with no clear indication whether or not these were registered as
>> KVM slots. A memory chunk can be "ram" and not a KVM slot if it is 4K on
>> PPC with 64K system pages, for example.
>>
>>
>> FlatView #0
>>  AS "memory", root: system
>>  AS "cpu-memory-0", root: system
>>  AS "cpu-memory-1", root: system
>>  AS "cpu-memory-2", root: system
>>  AS "cpu-memory-3", root: system
>>  AS "piix3-ide", root: bus master container
>>  AS "virtio-net-pci", root: bus master container
>>  AS "vfio-pci", root: bus master container
>>  Root memory region: system
>>   0000000000000000-00000000000bffff (prio 0, ram): pc.ram kvm
>>   00000000000c0000-00000000000c0fff (prio 0, rom): pc.ram
>> @00000000000c0000 kvm
>>   00000000000c1000-00000000000c3fff (prio 0, ram): pc.ram
>> @00000000000c1000 kvm
>>   00000000000c4000-00000000000e7fff (prio 0, rom): pc.ram
>> @00000000000c4000 kvm
>>   00000000000e8000-00000000000effff (prio 0, ram): pc.ram
>> @00000000000e8000 kvm
>>   00000000000f0000-00000000000fffff (prio 0, rom): pc.ram
>> @00000000000f0000 kvm
>>   0000000000100000-00000000bfffffff (prio 0, ram): pc.ram
>> @0000000000100000 kvm
>>   00000000febc0000-00000000febc0fff (prio 0, ramd): 0000:00:1a.0 BAR 0
>> mmaps[0] kvm
>>   00000000febc1000-00000000febc102f (prio 0, i/o): msix-table
>>   00000000febc1800-00000000febc1807 (prio 0, i/o): msix-pba
>>   00000000febfc000-00000000febfcfff (prio 0, i/o): virtio-pci-common
>>   00000000febfd000-00000000febfdfff (prio 0, i/o): virtio-pci-isr
>>   00000000febfe000-00000000febfefff (prio 0, i/o): virtio-pci-device
>>   00000000febff000-00000000febfffff (prio 0, i/o): virtio-pci-notify
>>   00000000fec00000-00000000fec00fff (prio 0, i/o): kvm-ioapic
>>   00000000fed00000-00000000fed003ff (prio 0, i/o): hpet
>>   00000000fee00000-00000000feefffff (prio 4096, i/o): kvm-apic-msi
>>   00000000fffc0000-00000000ffffffff (prio 0, rom): pc.bios kvm
>>   0000000100000000-000000013fffffff (prio 0, ram): pc.ram
>> @00000000c0000000 kvm
>>
>>
>>
>> FlatView #3
>>  AS "KVM-SMRAM", root: mem-container-smram
>>  Root memory region: mem-container-smram
>>   0000000000000000-00000000000bffff (prio 0, ram): pc.ram
>>   00000000000c0000-00000000000c0fff (prio 0, rom): pc.ram @00000000000c0000
>>   00000000000c1000-00000000000c3fff (prio 0, ram): pc.ram @00000000000c1000
>>   00000000000c4000-00000000000e7fff (prio 0, rom): pc.ram @00000000000c4000
>>   00000000000e8000-00000000000effff (prio 0, ram): pc.ram @00000000000e8000
>>   00000000000f0000-00000000000fffff (prio 0, rom): pc.ram @00000000000f0000
>>   0000000000100000-00000000bfffffff (prio 0, ram): pc.ram @0000000000100000
>>   00000000febc0000-00000000febc0fff (prio 0, ramd): 0000:00:1a.0 BAR 0
>> mmaps[0]
>>   00000000febc1000-00000000febc102f (prio 0, i/o): msix-table
>>   00000000febc1800-00000000febc1807 (prio 0, i/o): msix-pba
>>   00000000febfc000-00000000febfcfff (prio 0, i/o): virtio-pci-common
>>   00000000febfd000-00000000febfdfff (prio 0, i/o): virtio-pci-isr
>>   00000000febfe000-00000000febfefff (prio 0, i/o): virtio-pci-device
>>   00000000febff000-00000000febfffff (prio 0, i/o): virtio-pci-notify
>>   00000000fec00000-00000000fec00fff (prio 0, i/o): kvm-ioapic
>>   00000000fed00000-00000000fed003ff (prio 0, i/o): hpet
>>   00000000fee00000-00000000feefffff (prio 4096, i/o): kvm-apic-msi
>>   00000000fffc0000-00000000ffffffff (prio 0, rom): pc.bios
>>   0000000100000000-000000013fffffff (prio 0, ram): pc.ram @00000000c0000000
>>
>>
>>
>>
>>> Perhaps you could add instead an argument to "info mtree" that prints
>>> only the AddressSpace with a given name?
>>
>> Nah, this is not what it is about.
> 
> 
> 
> Still a nack? :)



-- 
Alexey

WARNING: multiple messages have this Message-ID (diff)
From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Daniel Henrique Barboza" <danielhb413@gmail.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH qemu v2] hmp: Print if memory section is registered with an accelerator
Date: Wed, 24 Apr 2019 15:32:34 +1000	[thread overview]
Message-ID: <aca6d2ae-806f-55b3-d9d5-f5a2cfd760b9@ozlabs.ru> (raw)
Message-ID: <20190424053234.j_fEQlDW_ihbEk_c0W0lxydbwNVp0Rbti4eIEYWAVXA@z> (raw)
In-Reply-To: <f346fdcb-1849-3397-7f4c-2d6ee07fcd7c@ozlabs.ru>

Paolo, ping?


On 19/03/2019 18:05, Alexey Kardashevskiy wrote:
> 
> 
> On 11/02/2019 15:56, Alexey Kardashevskiy wrote:
>>
>>
>> On 09/02/2019 04:26, Paolo Bonzini wrote:
>>> On 07/02/19 12:49, Dr. David Alan Gilbert wrote:
>>>>  //#define DEBUG_UNASSIGNED
>>>> @@ -2924,6 +2926,8 @@ struct FlatViewInfo {
>>>>      int counter;
>>>>      bool dispatch_tree;
>>>>      bool owner;
>>>> +    AccelClass *ac;
>>>> +    const char *ac_name;
>>>>  };
>>>>  
>>>>  static void mtree_print_flatview(gpointer key, gpointer value,
>>>> @@ -2939,6 +2943,7 @@ static void mtree_print_flatview(gpointer key, gpointer value,
>>>>      int n = view->nr;
>>>>      int i;
>>>>      AddressSpace *as;
>>>> +    bool system_as = false;
>>>>  
>>>>      p(f, "FlatView #%d\n", fvi->counter);
>>>>      ++fvi->counter;
>>>> @@ -2950,6 +2955,9 @@ static void mtree_print_flatview(gpointer key, gpointer value,
>>>>              p(f, ", alias %s", memory_region_name(as->root->alias));
>>>>          }
>>>>          p(f, "\n");
>>>> +        if (as == &address_space_memory) {
>>>> +            system_as = true;
>>>> +        }
>>>>      }
>>>>  
>>>>      p(f, " Root memory region: %s\n",
>>>> @@ -2985,6 +2993,13 @@ static void mtree_print_flatview(gpointer key, gpointer value,
>>>>          if (fvi->owner) {
>>>>              mtree_print_mr_owner(p, f, mr);
>>>>          }
>>>> +
>>>> +        if (system_as && fvi->ac &&
>>>> +            fvi->ac->has_memory(current_machine,
>>>> +                                int128_get64(range->addr.start),
>>>> +                                MR_SIZE(range->addr.size) + 1)) {
>>>> +            p(f, " %s", fvi->ac_name);
>>>
>>> I don't understand this.  This doesn't check that the memory range
>>> actually matches the memory registered with the accelerator, only that
>>> there is something in that range. 
>>
>>
>> It is checking that a flat range (i.e. what actually works) has a
>> corresponding KVM slot:
>> https://git.qemu.org/?p=qemu.git;a=blob;f=accel/kvm/kvm-all.c;h=4e1de942ce554c734ac2673030031c228a752ac9;hb=HEAD#l201
>>
>>
>>> Why isn't it enough to use "info
>>> mtree" and look at the KVM address space?
>>
>>
>> There is no such thing in my QEMU, did you mean "KVM-SMRAM" (which is
>> missing on spapr)? I am not sure I understand its purpose for the task -
>> it prints all same ranges on my x86 laptop, not just ones which we told
>> KVM about.
>>
>> My task is that if let's say "0000:00:1a.0 BAR 0 mmaps[0]" is split into
>> several sections because MSIX happens to be in a middle of that BAR and
>> it is not system page size aligned, then it is going to be several
>> ranges with no clear indication whether or not these were registered as
>> KVM slots. A memory chunk can be "ram" and not a KVM slot if it is 4K on
>> PPC with 64K system pages, for example.
>>
>>
>> FlatView #0
>>  AS "memory", root: system
>>  AS "cpu-memory-0", root: system
>>  AS "cpu-memory-1", root: system
>>  AS "cpu-memory-2", root: system
>>  AS "cpu-memory-3", root: system
>>  AS "piix3-ide", root: bus master container
>>  AS "virtio-net-pci", root: bus master container
>>  AS "vfio-pci", root: bus master container
>>  Root memory region: system
>>   0000000000000000-00000000000bffff (prio 0, ram): pc.ram kvm
>>   00000000000c0000-00000000000c0fff (prio 0, rom): pc.ram
>> @00000000000c0000 kvm
>>   00000000000c1000-00000000000c3fff (prio 0, ram): pc.ram
>> @00000000000c1000 kvm
>>   00000000000c4000-00000000000e7fff (prio 0, rom): pc.ram
>> @00000000000c4000 kvm
>>   00000000000e8000-00000000000effff (prio 0, ram): pc.ram
>> @00000000000e8000 kvm
>>   00000000000f0000-00000000000fffff (prio 0, rom): pc.ram
>> @00000000000f0000 kvm
>>   0000000000100000-00000000bfffffff (prio 0, ram): pc.ram
>> @0000000000100000 kvm
>>   00000000febc0000-00000000febc0fff (prio 0, ramd): 0000:00:1a.0 BAR 0
>> mmaps[0] kvm
>>   00000000febc1000-00000000febc102f (prio 0, i/o): msix-table
>>   00000000febc1800-00000000febc1807 (prio 0, i/o): msix-pba
>>   00000000febfc000-00000000febfcfff (prio 0, i/o): virtio-pci-common
>>   00000000febfd000-00000000febfdfff (prio 0, i/o): virtio-pci-isr
>>   00000000febfe000-00000000febfefff (prio 0, i/o): virtio-pci-device
>>   00000000febff000-00000000febfffff (prio 0, i/o): virtio-pci-notify
>>   00000000fec00000-00000000fec00fff (prio 0, i/o): kvm-ioapic
>>   00000000fed00000-00000000fed003ff (prio 0, i/o): hpet
>>   00000000fee00000-00000000feefffff (prio 4096, i/o): kvm-apic-msi
>>   00000000fffc0000-00000000ffffffff (prio 0, rom): pc.bios kvm
>>   0000000100000000-000000013fffffff (prio 0, ram): pc.ram
>> @00000000c0000000 kvm
>>
>>
>>
>> FlatView #3
>>  AS "KVM-SMRAM", root: mem-container-smram
>>  Root memory region: mem-container-smram
>>   0000000000000000-00000000000bffff (prio 0, ram): pc.ram
>>   00000000000c0000-00000000000c0fff (prio 0, rom): pc.ram @00000000000c0000
>>   00000000000c1000-00000000000c3fff (prio 0, ram): pc.ram @00000000000c1000
>>   00000000000c4000-00000000000e7fff (prio 0, rom): pc.ram @00000000000c4000
>>   00000000000e8000-00000000000effff (prio 0, ram): pc.ram @00000000000e8000
>>   00000000000f0000-00000000000fffff (prio 0, rom): pc.ram @00000000000f0000
>>   0000000000100000-00000000bfffffff (prio 0, ram): pc.ram @0000000000100000
>>   00000000febc0000-00000000febc0fff (prio 0, ramd): 0000:00:1a.0 BAR 0
>> mmaps[0]
>>   00000000febc1000-00000000febc102f (prio 0, i/o): msix-table
>>   00000000febc1800-00000000febc1807 (prio 0, i/o): msix-pba
>>   00000000febfc000-00000000febfcfff (prio 0, i/o): virtio-pci-common
>>   00000000febfd000-00000000febfdfff (prio 0, i/o): virtio-pci-isr
>>   00000000febfe000-00000000febfefff (prio 0, i/o): virtio-pci-device
>>   00000000febff000-00000000febfffff (prio 0, i/o): virtio-pci-notify
>>   00000000fec00000-00000000fec00fff (prio 0, i/o): kvm-ioapic
>>   00000000fed00000-00000000fed003ff (prio 0, i/o): hpet
>>   00000000fee00000-00000000feefffff (prio 4096, i/o): kvm-apic-msi
>>   00000000fffc0000-00000000ffffffff (prio 0, rom): pc.bios
>>   0000000100000000-000000013fffffff (prio 0, ram): pc.ram @00000000c0000000
>>
>>
>>
>>
>>> Perhaps you could add instead an argument to "info mtree" that prints
>>> only the AddressSpace with a given name?
>>
>> Nah, this is not what it is about.
> 
> 
> 
> Still a nack? :)



-- 
Alexey


  parent reply	other threads:[~2019-04-24  5:32 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-14  2:58 [Qemu-devel] [PATCH qemu v2] hmp: Print if memory section is registered with an accelerator Alexey Kardashevskiy
2018-12-14 11:07 ` Philippe Mathieu-Daudé
2018-12-17  1:27   ` Alexey Kardashevskiy
2018-12-17 12:47     ` Philippe Mathieu-Daudé
2018-12-18  0:58       ` Alexey Kardashevskiy
2019-01-03 17:37         ` Dr. David Alan Gilbert
2019-01-14  1:43           ` Alexey Kardashevskiy
2019-01-29  2:30             ` Alexey Kardashevskiy
2019-02-07  5:20               ` Alexey Kardashevskiy
2019-02-07 11:49             ` Dr. David Alan Gilbert
2019-02-08 17:26               ` Paolo Bonzini
2019-02-11  4:56                 ` Alexey Kardashevskiy
     [not found]                   ` <f346fdcb-1849-3397-7f4c-2d6ee07fcd7c@ozlabs.ru>
2019-04-24  5:32                     ` Alexey Kardashevskiy [this message]
2019-04-24  5:32                       ` Alexey Kardashevskiy
2019-05-21  6:37                       ` Alexey Kardashevskiy
2019-06-13  5:07                         ` Alexey Kardashevskiy
2019-06-13 11:49                           ` Dr. David Alan Gilbert
2019-06-13 13:59                           ` Paolo Bonzini
2019-06-13 14:04                           ` Paolo Bonzini

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=aca6d2ae-806f-55b3-d9d5-f5a2cfd760b9@ozlabs.ru \
    --to=aik@ozlabs.ru \
    --cc=danielhb413@gmail.com \
    --cc=dgilbert@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).