On 20.07.2018 [15:11:14 -0400], Farhan Ali wrote:
> I am seeing another issue pop up, in a different test. Even though it's a
> different assertion, it might be related based on the call trace.
Just to be clear, this does not happen if you revert the original patch
(i.e., the one you bisected to b
Hi Christian,
On 19.07.2018 [08:55:20 +0200], Christian Borntraeger wrote:
>
>
> On 07/18/2018 08:52 PM, Nishanth Aravamudan wrote:
> > On 18.07.2018 [11:10:27 -0400], Farhan Ali wrote:
> >>
> >>
> >> On 07/18/2018 09:42 AM, Farhan Ali wrote:
> &g
cause they did not call aio_setup_linux_aio first.
Add the appropriate callback definition to the affected driver
definitions.
Fixes: ed6e2161 ("linux-aio: properly bubble up errors from initialization")
Reported-by: Farhan Ali
Signed-off-by: Nishanth Aravamudan
Cc: Eric Blake
Cc:
On 18.07.2018 [11:10:27 -0400], Farhan Ali wrote:
>
>
> On 07/18/2018 09:42 AM, Farhan Ali wrote:
> >
> >
> > On 07/17/2018 04:52 PM, Nishanth Aravamudan wrote:
> > > iiuc, this possibly implies AIO was not actually used previously on this
> > > gu
error.
>
> commit ed6e2161715c527330f936d44af4c547f25f687e
> Author: Nishanth Aravamudan
> Date: Fri Jun 22 12:37:00 2018 -0700
>
> linux-aio: properly bubble up errors from initialization
>
> laio_init() can fail for a couple of reasons, which will lead to a NULL
> pointer dereference in laio
(), which will allocate a
new AioContext if needed, and return errors on failures. If it fails for
any reason, fallback to threaded AIO with an error message, as the
device is already in-use by the guest.
Add an assert that aio_get_linux_aio() cannot return NULL.
Signed-off-by: Nishanth Aravamudan
On 22.06.2018 [11:02:06 +0200], Kevin Wolf wrote:
> Am 22.06.2018 um 04:25 hat Fam Zheng geschrieben:
> > On Thu, 06/21 15:21, Nishanth Aravamudan wrote:
> > > When the AioContext changes, we need to associate a LinuxAioState with
> > > the new AioContext. Use the bdrv_
On 22.06.2018 [10:21:19 +0800], Fam Zheng wrote:
> On Thu, 06/21 15:21, Nishanth Aravamudan wrote:
> > laio_init() can fail for a couple of reasons, which will lead to a NULL
> > pointer dereference in laio_attach_aio_context().
> >
> > To solve this, add a aio_setup_li
not modified, because it seems
preferable to return the actual errno from the possible failing
initialization calls.
Add an assert that aio_get_linux_aio() cannot return NULL.
Signed-off-by: Nishanth Aravamudan
---
Changes from v2 -> v3 (thanks to Eric Blake and Kevin Wolf for review):
Us
not being able to allocate
additional AIO contexts for the I/O thread. This NULL is assigned to
ctx->linux_aio and dereferenced in aio_get_linux_aio.
Thanks to Jon Snow, Eric Blake and Kevin Wolf for review comments on v1
and v2.
Nishanth Aravamudan (2):
linux-aio: properly bubble up
threaded AIO with an error message, as the device is already
in-use by the guest.
Signed-off-by: Nishanth Aravamudan
---
Note this patch didn't exist in v2, but is a result of feedback to that
posting.
block/file-posix.c | 16
1 file changed, 16 insertions(+)
diff --git a/block
On 21.06.2018 [15:51:08 +0200], Kevin Wolf wrote:
> Am 21.06.2018 um 05:26 hat Nishanth Aravamudan geschrieben:
> > On 20.06.2018 [12:34:52 -0700], Nishanth Aravamudan wrote:
> > > On 20.06.2018 [11:57:42 +0200], Kevin Wolf wrote:
> > > > Am 20.06.2018 um 00:54 hat N
On 20.06.2018 [12:34:52 -0700], Nishanth Aravamudan wrote:
> On 20.06.2018 [11:57:42 +0200], Kevin Wolf wrote:
> > Am 20.06.2018 um 00:54 hat Nishanth Aravamudan geschrieben:
> > > On 19.06.2018 [15:35:57 -0700], Nishanth Aravamudan wrote:
> > > > On 19.06.2
On 20.06.2018 [11:57:42 +0200], Kevin Wolf wrote:
> Am 20.06.2018 um 00:54 hat Nishanth Aravamudan geschrieben:
> > On 19.06.2018 [15:35:57 -0700], Nishanth Aravamudan wrote:
> > > On 19.06.2018 [13:14:51 -0700], Nishanth Aravamudan wrote:
> > > > On 19.06.2018 [14:
On 19.06.2018 [15:35:57 -0700], Nishanth Aravamudan wrote:
> On 19.06.2018 [13:14:51 -0700], Nishanth Aravamudan wrote:
> > On 19.06.2018 [14:35:33 -0500], Eric Blake wrote:
> > > On 06/15/2018 12:47 PM, Nishanth Aravamudan via Qemu-devel wrote:
>
>
>
>
On 19.06.2018 [13:14:51 -0700], Nishanth Aravamudan wrote:
> On 19.06.2018 [14:35:33 -0500], Eric Blake wrote:
> > On 06/15/2018 12:47 PM, Nishanth Aravamudan via Qemu-devel wrote:
> > > } else if (s->use_linux_aio) {
> > > +
On 19.06.2018 [14:35:33 -0500], Eric Blake wrote:
> On 06/15/2018 12:47 PM, Nishanth Aravamudan via Qemu-devel wrote:
> > laio_init() can fail for a couple of reasons, which will lead to a NULL
> > pointer dereference in laio_attach_aio_context().
> >
> > To solve this
ith
aio=native,cache=directsync. With this patch, the guest successfully
starts (but obviously isn't using native AIO). Setting aio-max-nr back
up to a reasonable value, AIO contexts are consumed normally.
Signed-off-by: Nishanth Aravamudan
---
Changes from v1 -> v2:
Rather than affect
Hi Kevin,
On 15.06.2018 [10:41:26 +0200], Kevin Wolf wrote:
> Am 15.06.2018 um 01:21 hat Nishanth Aravamudan geschrieben:
> > laio_init() can fail for a couple of reasons, which will lead to a NULL
> > pointer dereference in laio_attach_aio_context().
> >
>
. With this patch, the guest successfully
starts (but obviously isn't using native AIO). Setting aio-max-nr back
up to a reasonable value, AIO contexts are consumed normally.
Signed-off-by: Nishanth Aravamudan
---
block/block-backend.c | 10 ++
block/file-posix.c
On Wed, May 23, 2018 at 10:53 AM, John Snow wrote:
>
>
>
> On 05/22/2018 06:01 PM, Nishanth Aravamudan via Qemu-devel wrote:
> > Hi!
> >
>
> Hi! CCing qemu-bl...@nongnu.org;
>
> > I'm tracking an error case in the native AIO path, and was wondering if
Hi!
I'm tracking an error case in the native AIO path, and was wondering if
there was a latent (albeit possibly hard to hit) bug. Specifically
util/async.c::aio_get_linux_aio:
#ifdef CONFIG_LINUX_AIO
LinuxAioState *aio_get_linux_aio(AioContext *ctx)
{
if (!ctx->linux_aio) {
ctx->linux
On 01.12.2015 [14:41:25 +1100], David Gibson wrote:
> On Thu, Nov 12, 2015 at 08:46:27AM -0800, Nishanth Aravamudan wrote:
> > On 12.11.2015 [15:47:15 +1100], David Gibson wrote:
> > > On Wed, Nov 11, 2015 at 02:10:48PM -0800, Nishanth Aravamudan wrote:
> > > >
On 12.11.2015 [15:47:15 +1100], David Gibson wrote:
> On Wed, Nov 11, 2015 at 02:10:48PM -0800, Nishanth Aravamudan wrote:
> > On 11.11.2015 [12:41:26 +1100], David Gibson wrote:
> > > On Tue, Nov 10, 2015 at 04:56:38PM -0800, Nishanth Aravamudan wrote:
> > > >
On 11.11.2015 [12:41:26 +1100], David Gibson wrote:
> On Tue, Nov 10, 2015 at 04:56:38PM -0800, Nishanth Aravamudan wrote:
> > On 11.11.2015 [11:17:58 +1100], David Gibson wrote:
> > > On Mon, Nov 09, 2015 at 08:22:32PM -0800, Sukadev Bhattiprolu wrote:
> > > The trou
gt; modules in the _host_ system and return this info to the guest
> > application
> > | > that makes the rtas_get_sysparm() call.
> > | >
> > | > We currently hard code the number of module_types to 1, but we should
> > determine
> > | > that d
On 24.06.2014 [16:14:11 +1000], Alexey Kardashevskiy wrote:
> > It seems like if neither are present,
> > we can just hotplug them later?
>
> hotplug what? NUMA nodes?
Just an FYI, as I didn't realize this, but Jiang Liu recently posted a
patchset for NUMA node hotplug issues Intel ran into on
On 03.07.2014 [10:03:10 +0300], Michael S. Tsirkin wrote:
> On Tue, Jul 01, 2014 at 01:11:08PM -0700, Nishanth Aravamudan wrote:
> > As suggested by Eduardo Habkost, rename nb_numa_nodes to num_numa_nodes
> > throughout the code, as that reflects the use of the variable m
On 02.07.2014 [15:21:38 -0300], Eduardo Habkost wrote:
> On Tue, Jul 01, 2014 at 01:50:06PM -0700, Nishanth Aravamudan wrote:
> > On 01.07.2014 [17:39:57 -0300], Eduardo Habkost wrote:
> > > On Tue, Jul 01, 2014 at 01:13:28PM -0700, Nishanth Aravamudan wrote:
> > > [.
On 01.07.2014 [17:39:57 -0300], Eduardo Habkost wrote:
> On Tue, Jul 01, 2014 at 01:13:28PM -0700, Nishanth Aravamudan wrote:
> [...]
> > diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> > index 12472c6..cdefafe 100644
> > --- a/hw/i386/pc.c
> > +++ b/hw/i386/pc.c
> >
ze: 2048 MB
node 3 cpus: 0 2
node 3 size: 2048 MB
available: 2 nodes (0,3)
node 0 cpus: 1 3
node 0 size: 2030 MB
node 0 free: 1934 MB
node 3 cpus: 0 2
node 3 size: 2045 MB
node 3 free: 1957 MB
node distances:
node 0 3
0: 10 40
3: 40 10
Signed-off-by: Nishanth Aravamudan
Cc: Eduardo Habko
As suggested by Eduardo Habkost, rename nb_numa_nodes to num_numa_nodes
throughout the code, as that reflects the use of the variable more
clearly.
Signed-off-by: Nishanth Aravamudan
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 2cf22b1..12472c6 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
On 01.07.2014 [12:24:48 -0300], Eduardo Habkost wrote:
> On Mon, Jun 30, 2014 at 02:34:56PM -0700, Nishanth Aravamudan wrote:
> [...]
> > }
> > + assert(numa_info[i].present);
> > numa_info[i].node_mem = ram_size - usedmem;
>
ze: 2048 MB
node 3 cpus: 0 2
node 3 size: 2048 MB
available: 2 nodes (0,3)
node 0 cpus: 1 3
node 0 size: 2030 MB
node 0 free: 1934 MB
node 3 cpus: 0 2
node 3 size: 2045 MB
node 3 free: 1957 MB
node distances:
node 0 3
0: 10 40
3: 40 10
Signed-off-by: Nishanth Aravamudan
---
I unde
On 26.06.2014 [16:37:05 -0300], Eduardo Habkost wrote:
> On Tue, Jun 24, 2014 at 10:40:38AM -0700, Nishanth Aravamudan wrote:
> > diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
> > index 277230d..b90bf66 100644
> > --- a/include/sysemu/sysemu.h
> > ++
On 26.06.2014 [17:09:25 +0800], Hu Tao wrote:
> On Wed, Jun 25, 2014 at 09:23:17PM +0300, Michael S. Tsirkin wrote:
> > On Wed, Jun 25, 2014 at 01:52:56PM -0300, Eduardo Habkost wrote:
> > > On Wed, Jun 25, 2014 at 09:13:59AM -0700, Nishanth Aravamudan wrote:
> > > >
On 25.06.2014 [13:52:56 -0300], Eduardo Habkost wrote:
> On Wed, Jun 25, 2014 at 09:13:59AM -0700, Nishanth Aravamudan wrote:
> > On 25.06.2014 [13:21:34 +0200], Igor Mammedov wrote:
> > > On Tue, 24 Jun 2014 10:40:38 -0700
> > > Nishanth Aravamudan wrote:
> >
&g
On 25.06.2014 [13:21:34 +0200], Igor Mammedov wrote:
> On Tue, 24 Jun 2014 10:40:38 -0700
> Nishanth Aravamudan wrote:
> > diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
> > index 277230d..b90bf66 100644
> > --- a/include/sysemu/sysemu.h
> >
Signed-off-by: Nishanth Aravamudan
Tested-by: Hu Tao
---
Based off mst's for_upstream tag, which has the NodeInfo changes.
v1 -> v2:
Modify set_numa_nodes loop for round-robin'ing CPUs.
v2 -> v3:
Updated changelog to indicate problem being solved.
Updated memory_region_al
On 24.06.2014 [16:07:41 +1000], Alexey Kardashevskiy wrote:
> On 06/24/2014 03:40 AM, Nishanth Aravamudan wrote:
> > On 21.06.2014 [13:06:53 +1000], Alexey Kardashevskiy wrote:
> >> On 06/21/2014 08:55 AM, Nishanth Aravamudan wrote:
> >>> On 16.06.2014 [17:53:49 +100
On 24.06.2014 [16:14:11 +1000], Alexey Kardashevskiy wrote:
> On 06/24/2014 01:08 PM, Nishanth Aravamudan wrote:
> > On 21.06.2014 [13:06:53 +1000], Alexey Kardashevskiy wrote:
> >> On 06/21/2014 08:55 AM, Nishanth Aravamudan wrote:
> >>> On 16.06.2014 [17:53:49 +100
On 24.06.2014 [09:33:48 +0200], Igor Mammedov wrote:
> On Mon, 23 Jun 2014 12:33:10 -0700
> Nishanth Aravamudan wrote:
>
> > Add a present field to NodeInfo which indicates if a given nodeid was
> > present on the command-line or not. Current code relies on a memory
> &g
Hi David,
On 23.06.2014 [18:08:33 -0700], Nishanth Aravamudan wrote:
> With generic sparse NUMA node parsing in place ("numa: enable sparse
> node numbering"), ppc can be updated to iterate over only the
> user-specified nodes.
>
> qemu-system-ppc64 -machine pseries,
On 21.06.2014 [13:06:53 +1000], Alexey Kardashevskiy wrote:
> On 06/21/2014 08:55 AM, Nishanth Aravamudan wrote:
> > On 16.06.2014 [17:53:49 +1000], Alexey Kardashevskiy wrote:
> >> Current QEMU does not support memoryless NUMA nodes.
> >> This prepares SPAPR for that.
&
MB
node 3 free: 1904 MB
node distances:
node 0 2 3
0: 10 40 40
2: 40 10 40
3: 40 40 10
Note, the empty node 0 is due to the Linux kernel.
Signed-off-by: Nishanth Aravamudan
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 82f183f..d07857a 100644
--- a/hw/ppc/spapr.c
++
On 23.06.2014 [12:33:10 -0700], Nishanth Aravamudan wrote:
> Add a present field to NodeInfo which indicates if a given nodeid was
> present on the command-line or not. Current code relies on a memory
> value being passed for a node to indicate presence, which is
> insufficient in the
11 15|
node 3 size: 1024 MB
After:
node 0 cpus: 0 4 8 12
node 0 size: 1024 MB
node 1 cpus: 1 5 9 13
node 1 size: 1024 MB
node 2 cpus: 2 6 10 14
node 2 size: 1024 MB
node 3 cpus: 3 7 11 15
node 3 size: 1024 MB
Signed-off-by: Nishanth Aravamudan
---
Base
On 21.06.2014 [13:08:59 +1000], Alexey Kardashevskiy wrote:
> On 06/21/2014 05:10 AM, Nishanth Aravamudan wrote:
> > On 16.06.2014 [17:53:49 +1000], Alexey Kardashevskiy wrote:
> >> Current QEMU does not support memoryless NUMA nodes.
> >> This prepares SPAPR for that.
&
On 21.06.2014 [13:06:53 +1000], Alexey Kardashevskiy wrote:
> On 06/21/2014 08:55 AM, Nishanth Aravamudan wrote:
> > On 16.06.2014 [17:53:49 +1000], Alexey Kardashevskiy wrote:
> >> Current QEMU does not support memoryless NUMA nodes.
> >> This prepares SPAPR for that.
&
On 16.06.2014 [17:53:49 +1000], Alexey Kardashevskiy wrote:
> Current QEMU does not support memoryless NUMA nodes.
> This prepares SPAPR for that.
>
> This moves 2 calls of spapr_populate_memory_node() into
> the existing loop which handles nodes other than than
> the first one.
>
> Signed-off-by
On 16.06.2014 [17:53:49 +1000], Alexey Kardashevskiy wrote:
> Current QEMU does not support memoryless NUMA nodes.
> This prepares SPAPR for that.
>
> This moves 2 calls of spapr_populate_memory_node() into
> the existing loop which handles nodes other than than
> the first one.
> @@ -719,6 +70
On 18.06.2014 [16:33:55 -0300], Eduardo Habkost wrote:
> On Wed, Jun 18, 2014 at 11:28:53AM -0700, Nishanth Aravamudan wrote:
> > On 17.06.2014 [16:22:33 -0300], Eduardo Habkost wrote:
> > > On Tue, Jun 17, 2014 at 11:38:16AM -0700, Nishanth Aravamudan wrote:
> > > >
On 17.06.2014 [16:22:33 -0300], Eduardo Habkost wrote:
> On Tue, Jun 17, 2014 at 11:38:16AM -0700, Nishanth Aravamudan wrote:
> > On 17.06.2014 [11:07:00 -0300], Eduardo Habkost wrote:
> >
> > > > If it is canonical and kosher way of using NUMA in QEMU, ok, we can use
On 17.06.2014 [11:07:00 -0300], Eduardo Habkost wrote:
> > If it is canonical and kosher way of using NUMA in QEMU, ok, we can use it.
> > I just fail to see why we need a requirement for nodes to go consequently
> > here. And it confuses me as a user a bit if I can add "-numa
> > node,nodeid=22"
On 16.06.2014 [22:41:08 -0300], Eduardo Habkost wrote:
> On Mon, Jun 16, 2014 at 05:25:00PM -0700, Nishanth Aravamudan wrote:
> [...]
> > > But you seem to claim you need 3 nodes with non-contiguous IDs. In that
> > > case, which exactly is the guest-visible diff
On 16.06.2014 [22:37:00 -0300], Eduardo Habkost wrote:
> On Mon, Jun 16, 2014 at 05:25:00PM -0700, Nishanth Aravamudan wrote:
> > On 16.06.2014 [17:51:50 -0300], Eduardo Habkost wrote:
> > > On Mon, Jun 16, 2014 at 06:16:29PM +1000, Alexey Kardashevskiy wrote:
> > &g
On 16.06.2014 [17:51:50 -0300], Eduardo Habkost wrote:
> On Mon, Jun 16, 2014 at 06:16:29PM +1000, Alexey Kardashevskiy wrote:
> > On 06/16/2014 05:53 PM, Alexey Kardashevskiy wrote:
> > > c4177479 "spapr: make sure RMA is in first mode of first memory node"
> > > introduced regression which preven
On 16.06.2014 [17:31:24 -0300], Eduardo Habkost wrote:
> On Mon, Jun 16, 2014 at 05:11:40PM -0300, Eduardo Habkost wrote:
> [...]
> > Wait, is the node ID visible to the guest at all? I believe it is a
> > QEMU-internal thing, just to allow the NUMA nodes to be ordered in the
> > command-line. I wo
On 16.06.2014 [17:11:40 -0300], Eduardo Habkost wrote:
> On Mon, Jun 16, 2014 at 11:49:46AM -0700, Nishanth Aravamudan wrote:
> > On 16.06.2014 [13:15:00 -0300], Eduardo Habkost wrote:
> > > On Mon, Jun 16, 2014 at 05:53:53PM +1000, Alexey Kardashevskiy wrote:
> > > >
On 16.06.2014 [13:15:00 -0300], Eduardo Habkost wrote:
> On Mon, Jun 16, 2014 at 05:53:53PM +1000, Alexey Kardashevskiy wrote:
> > Currently NUMA nodes must go consequently and QEMU ignores nodes
> > with @nodeid bigger than the number of NUMA nodes in the command line.
>
> Why would somebody need
On 16.06.2014 [17:53:51 +1000], Alexey Kardashevskiy wrote:
> In multiple places there is a node0_size variable calculation
> which assumes that NUMA node #0 and memory node #0 are the same
> things which they are not. Since we are going to change it and
> do not want to change it in multiple place
On 16.06.2014 [18:16:29 +1000], Alexey Kardashevskiy wrote:
> On 06/16/2014 05:53 PM, Alexey Kardashevskiy wrote:
> > c4177479 "spapr: make sure RMA is in first mode of first memory node"
> > introduced regression which prevents from running guests with memoryless
> > NUMA node#0 which may happen o
On 29.05.2014 [11:57:01 +1000], Alexey Kardashevskiy wrote:
> On 05/29/2014 05:57 AM, Nishanth Aravamudan wrote:
> > On 27.05.2014 [14:59:03 -0700], Nishanth Aravamudan wrote:
> >> On 20.05.2014 [12:44:15 +1000], Alexey Kardashevskiy wrote:
> >>> On 05/20/2014 10:06
On 27.05.2014 [14:59:03 -0700], Nishanth Aravamudan wrote:
> On 20.05.2014 [12:44:15 +1000], Alexey Kardashevskiy wrote:
> > On 05/20/2014 10:06 AM, Nishanth Aravamudan wrote:
> > > On 19.05.2014 [15:37:52 -0700], Nishanth Aravamudan wrote:
> > >> Hi Alexey,
> &g
On 20.05.2014 [12:44:15 +1000], Alexey Kardashevskiy wrote:
> On 05/20/2014 10:06 AM, Nishanth Aravamudan wrote:
> > On 19.05.2014 [15:37:52 -0700], Nishanth Aravamudan wrote:
> >> Hi Alexey,
> >>
> >> I've been looking at hw/ppc/spapr.c::spapr_populate_m
On 19.05.2014 [15:37:52 -0700], Nishanth Aravamudan wrote:
> Hi Alexey,
>
> I've been looking at hw/ppc/spapr.c::spapr_populate_memory() and ran
> into a few questions:
>
> 1) The values from 1 to nb_numa_nodes are used as indices into the
> node_mem array, but that is
Hi Alexey,
I've been looking at hw/ppc/spapr.c::spapr_populate_memory() and ran
into a few questions:
1) The values from 1 to nb_numa_nodes are used as indices into the
node_mem array, but that is not populated, necessarily, linearly.
vl.c::add_node() uses the nodeid parameter as the index into n
On 26.04.2014 [00:16:38 +1000], Alexey Kardashevskiy wrote:
> On 04/23/2014 05:04 AM, Nishanth Aravamudan wrote:
> > On 22.04.2014 [19:27:51 +1000], Benjamin Herrenschmidt wrote:
> >> On Tue, 2014-04-22 at 19:12 +1000, Alexey Kardashevskiy wrote:
> >>> I already ha
On 22.04.2014 [19:27:51 +1000], Benjamin Herrenschmidt wrote:
> On Tue, 2014-04-22 at 19:12 +1000, Alexey Kardashevskiy wrote:
> > I already have in plan to fix non-power-of-two sized memory nodes so I will
> > this too.
> >
> > What exactly is the point in having NUMA memoryless nodes now? We do
On 18.04.2014 [08:46:55 +1000], Benjamin Herrenschmidt wrote:
> On Fri, 2014-04-18 at 08:43 +1000, Alexey Kardashevskiy wrote:
> > On 04/18/2014 06:25 AM, Nishanth Aravamudan wrote:
> > > Hi Alexey,
> > >
> > > Prior to the $SUBJECT commit, we could present me
Hi Alexey,
Prior to the $SUBJECT commit, we could present memoryless node0s to
guests. Now, we indicate that we don't have the requisite 128M for the
RMA if node 0 has no memory. Note that a memoryless node0 is possible
under PowerVM (but not predictably present) so I was hoping to use KVM
to test
U Currently 'info tlb' in the
qemu monitor reports "dump_mmu: unimplemented". However, during
bringup work, it can be quite handy to have the SLB entries, which are
available in the CPUPPCState. This patch adds an implementation of
info tlb for book3s, which dumps the SLB.
On 31.10.2011 [17:35:13 -0700], Alexander Graf wrote:
>
> On 31.10.2011, at 15:53, Nishanth Aravamudan wrote:
>
> > On 31.10.2011 [15:14:12 +1100], David Gibson wrote:
> >> Good points below. I forgot to CC Nish, the original patch author on
> >> my post,
> On Mon, Oct 31, 2011 at 04:35:54AM +0100, Alexander Graf wrote:
> >
> > On 31.10.2011, at 04:16, David Gibson wrote:
> >
> > > From: Nishanth Aravamudan
> > >
> > > When run with a PPC Book3S (server) CPU Currently 'info tlb' in the
>
74 matches
Mail list logo
