* Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Matthieu CASTET @ 2011-08-23 10:02 UTC (permalink / raw)
To: LiuShuo
Cc: Scott Wood, linuxppc-dev@ozlabs.org, dwmw2@infradead.org,
Li Yang-R58472, linux-mtd@lists.infradead.org
In-Reply-To: <4E5366AF.7040108@freescale.com>
LiuShuo a écrit :
> 于 2011年08月19日 00:25, Scott Wood 写道:
>> On 08/17/2011 09:33 PM, b35362@freescale.com wrote:
>>> From: Liu Shuo<b35362@freescale.com>
>>>
>>> Freescale FCM controller has a 2K size limitation of buffer RAM. In order
>>> to support the Nand flash chip whose page size is larger than 2K bytes,
>>> we divide a page into multi-2K pages for MTD layer driver. In that case,
>>> we force to set the page size to 2K bytes. We convert the page address of
>>> MTD layer driver to a real page address in flash chips and a column index
>>> in fsl_elbc driver. We can issue any column address by UA instruction of
>>> elbc controller.
>>>
>>> NOTE: Due to there is a limitation of 'Number of Partial Program Cycles in
>>> the Same Page (NOP)', the flash chip which is supported by this workaround
>>> have to meet below conditions.
>>> 1. page size is not greater than 4KB
>>> 2. 1) if main area and spare area have independent NOPs:
>>> main area NOP :>=3
>>> spare area NOP :>=2?
>> How often are the NOPs split like this?
>>
>>> 2) if main area and spare area have a common NOP:
>>> NOP :>=4
>> This depends on how the flash is used. If you treat it as a NOP1 flash
>> (e.g. run ubifs rather than jffs2), then you need NOP2 for a 4K chip and
>> NOP4 for an 8K chip. OTOH, if you would be making full use of NOP4 on a
>> real 2K chip, you'll need NOP8 for a 4K chip.
>>
>> The NOP restrictions should be documented in the code itself, not just
>> in the git changelog. Maybe print it to the console when this hack is
>> used, along with the NOP value read from the ID.
>
> We can't read the NOP from the ID on any chip. Some chips don't
> give this infomation.(e.g. Micron MT29F4G08BAC)
Doesn't the micron chip provide it with onfi info ?
Matthieu
^ permalink raw reply
* Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Matthieu CASTET @ 2011-08-23 10:13 UTC (permalink / raw)
To: LiuShuo
Cc: Li Yang-R58472, Artem Bityutskiy, linuxppc-dev@ozlabs.org,
linux-mtd@lists.infradead.org, Scott Wood, Ivan Djelic,
dwmw2@infradead.org
In-Reply-To: <4E53798D.7050307@freescale.com>
LiuShuo a écrit :
> 于 2011年08月23日 16:14, Matthieu CASTET 写道:
>> LiuShuo a écrit :
>>> 于 2011年08月23日 00:19, Scott Wood 写道:
>>>> On 08/22/2011 11:13 AM, Matthieu CASTET wrote:
>>>>> Scott Wood a écrit :
>>>>>> To eliminate it we'd need to do an extra data transfer without reissuing
>>>>>> the command, which Shuo was unable to get to work.
>>>>>>
>>>>> That's weird because our controller seems quite flexible [1].
>>>>>
>>>>> Something like that should work ?
>>>>>
>>>>> out_be32(&lbc->fir,
>>>>> (FIR_OP_CM2<< FIR_OP0_SHIFT) |
>>>>> (FIR_OP_CA<< FIR_OP1_SHIFT) |
>>>>> (FIR_OP_PA<< FIR_OP2_SHIFT) |
>>>>> (FIR_OP_WB<< FIR_OP3_SHIFT));
>>>>> refill FCM buffer with next 2k data
>>>>>
>>>>> out_be32(&lbc->fir,
>>>>> (FIR_OP_WB<< FIR_OP3_SHIFT) |
>>>>> (FIR_OP_CM3<< FIR_OP4_SHIFT) |
>>>>> (FIR_OP_CW1<< FIR_OP5_SHIFT) |
>>>>> (FIR_OP_RS<< FIR_OP6_SHIFT));
>>>> Something like that is what I originally suggested, but Shuo said it
>>>> didn't work (even in theory, it requires a CE-don't-care NAND chip,
>>>> since bus atomicity is broken).
>>>>
>>>> Shuo, what specifically did you try, and what did you see happen?
>>>>
>>>> -Scott
>>> First, if we want to read 4K data with once command issuing, we can't
>>> use HW_ECC.
>> Yes, but as ivan said doesn't the cost of 2 read isn't bigger than software ecc ?
>>
>>> Even if we use SW_ECC, we always get lots of weird '0xFF's between 1st
>>> 2k and 2nd 2k data.
>> Did you understand where those 0xff comes (what's the size of them. Doesn't the
>> controller try to insert spare aera ?)
> I don't understand. I set FBCR to 2048, the controller will read the
> main area without spare area.
> But the size of them is nearly spare area size( more or less a few bytes)..
> I can't guess the behavior of the controller then, so I select another way.
>
> Could you try to do it and explain how those 0xff comes ?
>> Could you detail the sequence you used ?
>>
> First half :
> out_be32(&lbc->fbcr, 2048);
shouldn't you read 2k+64 here ? At the end you want 4k plus spare aera (128) ?
> out_be32(&lbc->fir,
> (FIR_OP_CM0 << FIR_OP0_SHIFT) |
> (FIR_OP_CA << FIR_OP1_SHIFT) |
> (FIR_OP_PA << FIR_OP2_SHIFT) |
> (FIR_OP_CM1 << FIR_OP3_SHIFT) |
> (FIR_OP_RBW << FIR_OP4_SHIFT));
>
>
> Sencond half :
> out_be32(&lbc->fbcr, 2048);
> out_be32(&lbc->fir,
> (FIR_OP_RB << FIR_OP0_SHIFT) |
> (FIR_OP_RBW << FIR_OP1_SHIFT));
Why do you do FIR_OP_RBW ?
FIR_OP_RB already fetch the data.
Matthieu
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Joerg Roedel @ 2011-08-23 11:04 UTC (permalink / raw)
To: aafabbri
Cc: Alexey Kardashevskiy, kvm@vger.kernel.org, Paul Mackerras,
linux-pci@vger.kernel.org, qemu-devel, chrisw, iommu, Avi Kivity,
Anthony Liguori, linuxppc-dev, benve@cisco.com
In-Reply-To: <CA7847D2.FB3A%aafabbri@cisco.com>
On Mon, Aug 22, 2011 at 08:52:18PM -0400, aafabbri wrote:
> You have to enforce group/iommu domain assignment whether you have the
> existing uiommu API, or if you change it to your proposed
> ioctl(inherit_iommu) API.
>
> The only change needed to VFIO here should be to make uiommu fd assignment
> happen on the groups instead of on device fds. That operation fails or
> succeeds according to the group semantics (all-or-none assignment/same
> uiommu).
That is makes uiommu basically the same as the meta-groups, right?
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Joerg Roedel @ 2011-08-23 11:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: chrisw, Alexey Kardashevskiy, kvm@vger.kernel.org, Paul Mackerras,
linux-pci@vger.kernel.org, qemu-devel, aafabbri, iommu,
Avi Kivity, Anthony Liguori, linuxppc-dev, benve@cisco.com
In-Reply-To: <1314082483.30478.43.camel@pasglop>
On Tue, Aug 23, 2011 at 02:54:43AM -0400, Benjamin Herrenschmidt wrote:
> Possibly, the question that interest me the most is what interface will
> KVM end up using. I'm also not terribly fan with the (perceived)
> discrepancy between using uiommu to create groups but using the group fd
> to actually do the mappings, at least if that is still the plan.
>
> If the separate uiommu interface is kept, then anything that wants to be
> able to benefit from the ability to put multiple devices (or existing
> groups) into such a "meta group" would need to be explicitly modified to
> deal with the uiommu APIs.
>
> I tend to prefer such "meta groups" as being something you create
> statically using a configuration interface, either via sysfs, netlink or
> ioctl's to a "control" vfio device driven by a simple command line tool
> (which can have the configuration stored in /etc and re-apply it at
> boot).
Hmm, I don't think that these groups are static for the systems
run-time. They only exist for the lifetime of a guest per default, at
least on x86. Thats why I prefer to do this grouping using VFIO and not
some sysfs interface (which would be the third interface beside the
ioctls and netlink a VFIO user needs to be aware of). Doing this in the
ioctl interface just makes things easier.
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
^ permalink raw reply
* [PATCH] perf: fix build for PowerPC with uclibc toolchains
From: Florian Fainelli @ 2011-08-23 12:20 UTC (permalink / raw)
To: Ian Munsie, linuxppc-dev
libio.h is not provided by uClibc, in order to be able to test the
definition of __UCLIBC__ we need to include stdlib.h, which also
includes stddef.h, providing the definition of 'NULL'.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
---
FYI, I submitted the exact same patch for ARM:
https://patchwork.kernel.org/patch/1049152/
diff --git a/tools/perf/arch/powerpc/util/dwarf-regs.c b/tools/perf/arch/powerpc/util/dwarf-regs.c
index 48ae0c5..7cdd61d 100644
--- a/tools/perf/arch/powerpc/util/dwarf-regs.c
+++ b/tools/perf/arch/powerpc/util/dwarf-regs.c
@@ -9,7 +9,10 @@
* 2 of the License, or (at your option) any later version.
*/
+#include <stdlib.h>
+#ifndef __UCLIBC__
#include <libio.h>
+#endif
#include <dwarf-regs.h>
--
1.7.4.1
^ permalink raw reply related
* [PATCH] powerpc: fixup QE_General4 errata
From: Joakim Tjernlund @ 2011-08-23 12:30 UTC (permalink / raw)
To: Timur Tabi, linuxppc-dev
QE_General4 should only round up the divisor iff divisor is > 3.
Rounding up lower divisors makes the error too big, causing USB
on MPC832x to fail.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
arch/powerpc/sysdev/qe_lib/qe.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 093e0ae..5399316 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -216,7 +216,7 @@ int qe_setbrg(enum qe_clock brg, unsigned int rate, unsigned int multiplier)
/* Errata QE_General4, which affects some MPC832x and MPC836x SOCs, says
that the BRG divisor must be even if you're not using divide-by-16
mode. */
- if (!div16 && (divisor & 1))
+ if (!div16 && (divisor & 1) && (divisor > 3))
divisor++;
tempval = ((divisor - 1) << QE_BRGC_DIVISOR_SHIFT) |
--
1.7.3.4
^ permalink raw reply related
* [PATCH] usb: Allocate pram dynamically.
From: Joakim Tjernlund @ 2011-08-23 12:38 UTC (permalink / raw)
To: Anton Vorontsov, linuxppc-dev
MPC832x does not have enough MURAM to do fixed MURAM allocation.
Change to dynamic allocation.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
drivers/usb/host/fhci-hcd.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/fhci-hcd.c b/drivers/usb/host/fhci-hcd.c
index c7c8392..98adbe8 100644
--- a/drivers/usb/host/fhci-hcd.c
+++ b/drivers/usb/host/fhci-hcd.c
@@ -622,12 +622,15 @@ static int __devinit of_fhci_probe(struct of_device *ofdev,
goto err_pram;
}
- pram_addr = cpm_muram_alloc_fixed(iprop[2], FHCI_PRAM_SIZE);
+ pram_addr = cpm_muram_alloc(FHCI_PRAM_SIZE, 64);
if (IS_ERR_VALUE(pram_addr)) {
dev_err(dev, "failed to allocate usb pram\n");
ret = -ENOMEM;
goto err_pram;
}
+
+ qe_issue_cmd(QE_ASSIGN_PAGE_TO_DEVICE, QE_CR_SUBBLOCK_USB,
+ QE_CR_PROTOCOL_UNSPECIFIED, pram_addr);
fhci->pram = cpm_muram_addr(pram_addr);
/* GPIOs and pins */
--
1.7.3.4
^ permalink raw reply related
* RE: [PATCH] RapidIO: Fix use of non-compatible registers
From: Bounine, Alexandre @ 2011-08-23 12:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: Kim, Chul, linux-kernel, Thomas Moll, linuxppc-dev, stable
In-Reply-To: <20110822122807.5b558d65.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Tue, 26 Jul 2011 14:07:26 -0400
> Alexandre Bounine <alexandre.bounine@idt.com> wrote:
>=20
> > Replace/remove use of RIO v.1.2 registers/bits that are not forward-
> compatible
> > with newer versions of RapidIO specification.
> >
> > RapidIO specification v. 1.3 removed Write Port CSR, Doorbell CSR,
> > Mailbox CSR and Mailbox and Doorbell bits of the PEF CAR.
> >
.....
> You did a cc:stable but provided no reason (that I can understand) for
> backporting the patch. Please explain why the problem is sufficiently
> serious to warrant this action.
My reason for this is that use of removed (since RIO v.1.3) register
bits
affects users of currently available 1.3 and 2.x compliant devices who
may
use not so recent kernel versions.
Removing checks for unsupported bits makes corresponding routines
compatible
with all versions of RapidIO specification. Therefore, backporting makes
stable
kernel versions compliant with RIO v.1.3 and later as well.=20
^ permalink raw reply
* Re: [PATCH] usb: Allocate pram dynamically.
From: Anton Vorontsov @ 2011-08-23 13:02 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev
In-Reply-To: <1314103121-9857-1-git-send-email-Joakim.Tjernlund@transmode.se>
On Tue, Aug 23, 2011 at 02:38:41PM +0200, Joakim Tjernlund wrote:
> MPC832x does not have enough MURAM to do fixed MURAM allocation.
> Change to dynamic allocation.
>
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Acked-by: Anton Vorontsov <cbouatmailru@gmail.com>
Thanks!
p.s. You probably want to send this to Greg KH, + Cc linux-usb
mailing list.
--
Anton Vorontsov
Email: cbouatmailru@gmail.com
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Roedel, Joerg @ 2011-08-23 13:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Alexey Kardashevskiy, kvm@vger.kernel.org, Paul Mackerras,
linux-pci@vger.kernel.org, qemu-devel, iommu, chrisw,
Alex Williamson, Avi Kivity, Anthony Liguori, linuxppc-dev,
benve@cisco.com
In-Reply-To: <1314047033.7662.39.camel@pasglop>
On Mon, Aug 22, 2011 at 05:03:53PM -0400, Benjamin Herrenschmidt wrote:
>
> > I am in favour of /dev/vfio/$GROUP. If multiple devices should be
> > assigned to a guest, there can also be an ioctl to bind a group to an
> > address-space of another group (certainly needs some care to not allow
> > that both groups belong to different processes).
> >
> > Btw, a problem we havn't talked about yet entirely is
> > driver-deassignment. User space can decide to de-assign the device from
> > vfio while a fd is open on it. With PCI there is no way to let this fail
> > (the .release function returns void last time i checked). Is this a
> > problem, and yes, how we handle that?
>
> We can treat it as a hard unplug (like a cardbus gone away).
>
> IE. Dispose of the direct mappings (switch to MMIO emulation) and return
> all ff's from reads (& ignore writes).
>
> Then send an unplug event via whatever mechanism the platform provides
> (ACPI hotplug controller on x86 for example, we haven't quite sorted out
> what to do on power for hotplug yet).
Hmm, good idea. But as far as I know the hotplug-event needs to be in
the guest _before_ the device is actually unplugged (so that the guest
can unbind its driver first). That somehow brings back the sleep-idea
and the timeout in the .release function.
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Roedel, Joerg @ 2011-08-23 13:14 UTC (permalink / raw)
To: Alex Williamson
Cc: Alexey Kardashevskiy, kvm@vger.kernel.org, Paul Mackerras,
qemu-devel, chrisw, iommu, Avi Kivity, Anthony Liguori,
linux-pci@vger.kernel.org, linuxppc-dev, benve@cisco.com
In-Reply-To: <1314040622.6866.268.camel@x201.home>
On Mon, Aug 22, 2011 at 03:17:00PM -0400, Alex Williamson wrote:
> On Mon, 2011-08-22 at 19:25 +0200, Joerg Roedel wrote:
> > I am in favour of /dev/vfio/$GROUP. If multiple devices should be
> > assigned to a guest, there can also be an ioctl to bind a group to an
> > address-space of another group (certainly needs some care to not allow
> > that both groups belong to different processes).
>
> That's an interesting idea. Maybe an interface similar to the current
> uiommu interface, where you open() the 2nd group fd and pass the fd via
> ioctl to the primary group. IOMMUs that don't support this would fail
> the attach device callback, which would fail the ioctl to bind them. It
> will need to be designed so any group can be removed from the super-set
> and the remaining group(s) still works. This feels like something that
> can be added after we get an initial implementation.
Handling it through fds is a good idea. This makes sure that everything
belongs to one process. I am not really sure yet if we go the way to
just bind plain groups together or if we create meta-groups. The
meta-groups thing seems somewhat cleaner, though.
> > Btw, a problem we havn't talked about yet entirely is
> > driver-deassignment. User space can decide to de-assign the device from
> > vfio while a fd is open on it. With PCI there is no way to let this fail
> > (the .release function returns void last time i checked). Is this a
> > problem, and yes, how we handle that?
>
> The current vfio has the same problem, we can't unbind a device from
> vfio while it's attached to a guest. I think we'd use the same solution
> too; send out a netlink packet for a device removal and have the .remove
> call sleep on a wait_event(, refcnt == 0). We could also set a timeout
> and SIGBUS the PIDs holding the device if they don't return it
> willingly. Thanks,
Putting the process to sleep (which would be uninterruptible) seems bad.
The process would sleep until the guest releases the device-group, which
can take days or months.
The best thing (and the most intrusive :-) ) is to change PCI core to
allow unbindings to fail, I think. But this probably further complicates
the way to upstream VFIO...
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
^ permalink raw reply
* Re: [PATCH] usb: Allocate pram dynamically.
From: Joakim Tjernlund @ 2011-08-23 13:23 UTC (permalink / raw)
To: Anton Vorontsov, Greg Kroah-Hartman; +Cc: linux-usb, linuxppc-dev
In-Reply-To: <20110823130253.GA30733@oksana.dev.rtsoft.ru>
Anton Vorontsov <cbouatmailru@gmail.com> wrote on 2011/08/23 15:02:53:
> From: Anton Vorontsov <cbouatmailru@gmail.com>
> To: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> Cc: linuxppc-dev@lists.ozlabs.org
> Date: 2011/08/23 15:02
> Subject: Re: [PATCH] usb: Allocate pram dynamically.
>
> On Tue, Aug 23, 2011 at 02:38:41PM +0200, Joakim Tjernlund wrote:
> > MPC832x does not have enough MURAM to do fixed MURAM allocation.
> > Change to dynamic allocation.
> >
> > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
>
> Acked-by: Anton Vorontsov <cbouatmailru@gmail.com>
>
> Thanks!
>
> p.s. You probably want to send this to Greg KH, + Cc linux-usb
> mailing list.
Added linux-usb and Greg KH per Antons suggestion.
Jocke
>From 587137e365ac1ba7e333a09962b3e4b68c587808 Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date: Tue, 23 Aug 2011 11:04:24 +0200
Subject: [PATCH] usb: Allocate pram dynamically.
MPC832x does not have enough MURAM to do fixed MURAM allocation.
Change to dynamic allocation.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
drivers/usb/host/fhci-hcd.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/fhci-hcd.c b/drivers/usb/host/fhci-hcd.c
index c7c8392..98adbe8 100644
--- a/drivers/usb/host/fhci-hcd.c
+++ b/drivers/usb/host/fhci-hcd.c
@@ -622,12 +622,15 @@ static int __devinit of_fhci_probe(struct of_device *ofdev,
goto err_pram;
}
- pram_addr = cpm_muram_alloc_fixed(iprop[2], FHCI_PRAM_SIZE);
+ pram_addr = cpm_muram_alloc(FHCI_PRAM_SIZE, 64);
if (IS_ERR_VALUE(pram_addr)) {
dev_err(dev, "failed to allocate usb pram\n");
ret = -ENOMEM;
goto err_pram;
}
+
+ qe_issue_cmd(QE_ASSIGN_PAGE_TO_DEVICE, QE_CR_SUBBLOCK_USB,
+ QE_CR_PROTOCOL_UNSPECIFIED, pram_addr);
fhci->pram = cpm_muram_addr(pram_addr);
/* GPIOs and pins */
--
1.7.3.4
^ permalink raw reply related
* MPC5200 + BestComm support in QEMU
From: steve.belanger @ 2011-08-23 14:09 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2633 bytes --]
Hi,
I'm Steve, an embedded software developper for Bombardier Transportation
Canada. We use the MPC5200 for most of our onboard computers inside train
control systems. To enhance our SW engineering process, we would like the
emulate the MPC5200 processor using QEMU, an open source software CPU
emulator. This software supports the MPC5200 CPU emulation.
However, the network interface is handled with the BestComm DMA engine and
it seems very difficult to simulate this co-processor with our current
knowledge level. In that sense, I would like to know if someone was able
to emulate correctly the MPC5200 with the BestComm DMA using QEMU
software?
Regards,
Steve Bélanger, ing. / Eng.
Développeur logiciel embarqué / Embedded Software Developper
Bombardier Transportation Canada Inc.
Train Control and Management System
Saint-Bruno: 450-441-2020 ext.6148
Please consider the environment before you print / Merci de penser à
l'environnement avant d'imprimer
_______________________________________________________________________________________________________________
This e-mail communication (and any attachment/s) may contain confidential
or privileged information and is intended only for the individual(s) or
entity named above and to others who have been specifically authorized to
receive it. If you are not the intended recipient, please do not read,
copy, use or disclose the contents of this communication to others. Please
notify the sender that you have received this e-mail in error by reply
e-mail, and delete the e-mail subsequently. Please note that in order to
protect the security of our information systems an AntiSPAM solution is in
use and will browse through incoming emails.
Thank you.
_________________________________________________________________________________________________________________
Ce message (ainsi que le(s) fichier(s)), transmis par courriel, peut
contenir des renseignements confidentiels ou protégés et est destiné à
l?usage exclusif du destinataire ci-dessus. Toute autre personne est, par
les présentes, avisée qu?il est strictement interdit de le diffuser, le
distribuer ou le reproduire. Si vous l?avez reçu par inadvertance,
veuillez nous en aviser et détruire ce message. Veuillez prendre note
qu'une solution antipollupostage (AntiSPAM) est utilisée afin d'assurer la
sécurité de nos systèmes d'information et qu'elle furètera les courriels
entrants.
Merci.
_________________________________________________________________________________________________________________
[-- Attachment #2: Type: text/html, Size: 3034 bytes --]
^ permalink raw reply
* MPC5200 + BestComm support in QEMU
From: steve.belanger @ 2011-08-23 14:26 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2621 bytes --]
Hi,
I'm Steve, an embedded software developper for Bombardier Transportation
Canada. We use the MPC5200 for most of our onboard computers inside train
control systems. To enhance our SW engineering process, we would like the
emulate the MPC5200 processor using QEMU, an open source software CPU
emulator. This software supports the MPC5200 CPU emulation.
However, the network interface is handled with the BestComm DMA engine and
it seems very difficult to simulate this co-processor with our current
knowledge level. In that sense, I would like to know if someone was able
to emulate correctly the MPC5200 with the BestComm DMA using QEMU
software?
Steve Bélanger, ing. / Eng.
Développeur logiciel embarqué / Embedded Software Developper
Bombardier Transportation Canada Inc.
Train Control and Management System
Saint-Bruno: 450-441-2020 ext.6148
Please consider the environment before you print / Merci de penser à
l'environnement avant d'imprimer
_______________________________________________________________________________________________________________
This e-mail communication (and any attachment/s) may contain confidential
or privileged information and is intended only for the individual(s) or
entity named above and to others who have been specifically authorized to
receive it. If you are not the intended recipient, please do not read,
copy, use or disclose the contents of this communication to others. Please
notify the sender that you have received this e-mail in error by reply
e-mail, and delete the e-mail subsequently. Please note that in order to
protect the security of our information systems an AntiSPAM solution is in
use and will browse through incoming emails.
Thank you.
_________________________________________________________________________________________________________________
Ce message (ainsi que le(s) fichier(s)), transmis par courriel, peut
contenir des renseignements confidentiels ou protégés et est destiné à
l?usage exclusif du destinataire ci-dessus. Toute autre personne est, par
les présentes, avisée qu?il est strictement interdit de le diffuser, le
distribuer ou le reproduire. Si vous l?avez reçu par inadvertance,
veuillez nous en aviser et détruire ce message. Veuillez prendre note
qu'une solution antipollupostage (AntiSPAM) est utilisée afin d'assurer la
sécurité de nos systèmes d'information et qu'elle furètera les courriels
entrants.
Merci.
_________________________________________________________________________________________________________________
[-- Attachment #2: Type: text/html, Size: 2976 bytes --]
^ permalink raw reply
* Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Scott Wood @ 2011-08-23 16:12 UTC (permalink / raw)
To: Matthieu CASTET
Cc: linuxppc-dev@ozlabs.org, LiuShuo, dwmw2@infradead.org,
linux-mtd@lists.infradead.org, Li Yang-R58472
In-Reply-To: <4E537AC4.6000301@parrot.com>
On 08/23/2011 05:02 AM, Matthieu CASTET wrote:
> LiuShuo a =C3=A9crit :
>> We can't read the NOP from the ID on any chip. Some chips don't
>> give this infomation.(e.g. Micron MT29F4G08BAC)
Are there any 4K+ chips (especially ones with insufficient NOP) that
don't have the info?
This chip is 2K and NOP8.
Is there an easy way (without needing to have every datasheet for every
chip ever made) to determine at runtime which chips supply this informati=
on?
> Doesn't the micron chip provide it with onfi info ?
This chip doesn't appear to be ONFI.
-Scott
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Alex Williamson @ 2011-08-23 16:23 UTC (permalink / raw)
To: David Gibson
Cc: chrisw, Alexey Kardashevskiy, kvm, Paul Mackerras,
linux-pci@vger.kernel.org, qemu-devel, aafabbri, iommu,
Avi Kivity, Anthony Liguori, linuxppc-dev, benve
In-Reply-To: <20110823023822.GO30097@yookeroo.fritz.box>
On Tue, 2011-08-23 at 12:38 +1000, David Gibson wrote:
> On Mon, Aug 22, 2011 at 09:45:48AM -0600, Alex Williamson wrote:
> > On Mon, 2011-08-22 at 15:55 +1000, David Gibson wrote:
> > > On Sat, Aug 20, 2011 at 09:51:39AM -0700, Alex Williamson wrote:
> > > > We had an extremely productive VFIO BoF on Monday. Here's my attempt to
> > > > capture the plan that I think we agreed to:
> > > >
> > > > We need to address both the description and enforcement of device
> > > > groups. Groups are formed any time the iommu does not have resolution
> > > > between a set of devices. On x86, this typically happens when a
> > > > PCI-to-PCI bridge exists between the set of devices and the iommu. For
> > > > Power, partitionable endpoints define a group. Grouping information
> > > > needs to be exposed for both userspace and kernel internal usage. This
> > > > will be a sysfs attribute setup by the iommu drivers. Perhaps:
> > > >
> > > > # cat /sys/devices/pci0000:00/0000:00:19.0/iommu_group
> > > > 42
> > > >
> > > > (I use a PCI example here, but attribute should not be PCI specific)
> > >
> > > Ok. Am I correct in thinking these group IDs are representing the
> > > minimum granularity, and are therefore always static, defined only by
> > > the connected hardware, not by configuration?
> >
> > Yes, that's the idea. An open question I have towards the configuration
> > side is whether we might add iommu driver specific options to the
> > groups. For instance on x86 where we typically have B:D.F granularity,
> > should we have an option not to trust multi-function devices and use a
> > B:D granularity for grouping?
>
> Right. And likewise I can see a place for configuration parameters
> like the present 'allow_unsafe_irqs'. But these would be more-or-less
> global options which affected the overall granularity, rather than
> detailed configuration such as explicitly binding some devices into a
> group, yes?
Yes, currently the interrupt remapping support is a global iommu
capability. I suppose it's possible that this could be an iommu option,
where the iommu driver would not advertise a group if the interrupt
remapping constraint isn't met.
> > > > >From there we have a few options. In the BoF we discussed a model where
> > > > binding a device to vfio creates a /dev/vfio$GROUP character device
> > > > file. This "group" fd provides provides dma mapping ioctls as well as
> > > > ioctls to enumerate and return a "device" fd for each attached member of
> > > > the group (similar to KVM_CREATE_VCPU). We enforce grouping by
> > > > returning an error on open() of the group fd if there are members of the
> > > > group not bound to the vfio driver. Each device fd would then support a
> > > > similar set of ioctls and mapping (mmio/pio/config) interface as current
> > > > vfio, except for the obvious domain and dma ioctls superseded by the
> > > > group fd.
> > >
> > > It seems a slightly strange distinction that the group device appears
> > > when any device in the group is bound to vfio, but only becomes usable
> > > when all devices are bound.
> > >
> > > > Another valid model might be that /dev/vfio/$GROUP is created for all
> > > > groups when the vfio module is loaded. The group fd would allow open()
> > > > and some set of iommu querying and device enumeration ioctls, but would
> > > > error on dma mapping and retrieving device fds until all of the group
> > > > devices are bound to the vfio driver.
> > >
> > > Which is why I marginally prefer this model, although it's not a big
> > > deal.
> >
> > Right, we can also combine models. Binding a device to vfio
> > creates /dev/vfio$GROUP, which only allows a subset of ioctls and no
> > device access until all the group devices are also bound. I think
> > the /dev/vfio/$GROUP might help provide an enumeration interface as well
> > though, which could be useful.
>
> I'm not entirely sure what you mean here. But, that's now several
> weak votes in favour of the always-present group devices, and none in
> favour of the created-when-first-device-bound model, so I suggest we
> take the /dev/vfio/$GROUP as our tentative approach.
Yep
> > > > In either case, the uiommu interface is removed entirely since dma
> > > > mapping is done via the group fd. As necessary in the future, we can
> > > > define a more high performance dma mapping interface for streaming dma
> > > > via the group fd. I expect we'll also include architecture specific
> > > > group ioctls to describe features and capabilities of the iommu. The
> > > > group fd will need to prevent concurrent open()s to maintain a 1:1 group
> > > > to userspace process ownership model.
> > >
> > > A 1:1 group<->process correspondance seems wrong to me. But there are
> > > many ways you could legitimately write the userspace side of the code,
> > > many of them involving some sort of concurrency. Implementing that
> > > concurrency as multiple processes (using explicit shared memory and/or
> > > other IPC mechanisms to co-ordinate) seems a valid choice that we
> > > shouldn't arbitrarily prohibit.
> > >
> > > Obviously, only one UID may be permitted to have the group open at a
> > > time, and I think that's enough to prevent them doing any worse than
> > > shooting themselves in the foot.
> >
> > 1:1 group<->process is probably too strong. Not allowing concurrent
> > open()s on the group file enforces a single userspace entity is
> > responsible for that group. Device fds can be passed to other
> > processes, but only retrieved via the group fd. I suppose we could even
> > branch off the dma interface into a different fd, but it seems like we
> > would logically want to serialize dma mappings at each iommu group
> > anyway. I'm open to alternatives, this just seemed an easy way to do
> > it. Restricting on UID implies that we require isolated qemu instances
> > to run as different UIDs.
>
> Well.. yes and know. It means guests which need to be isolated from
> malicious interference with each other need different UIDs, but given
> that if they have the same UID one qemu can kill() or ptrace() the
> other, they're not isolated in that sense anyway.
>
> It seems to me that running as the same UIDs with different device
> groups assigned, the guests are still pretty well isolated from
> accidental interference with each other.
If our only restriction is UID, what prevents a non-clueful user from
trying to create separate qemu instances making use of different devices
within the same group (or even the same device)? If we restrict
concurrent opens, it's just the subsequent instances get a -EBUSY.
> > I know that's a goal, but I don't know if we
> > want to make it an assumption in the group security model.
> >
> > > > Also on the table is supporting non-PCI devices with vfio. To do this,
> > > > we need to generalize the read/write/mmap and irq eventfd interfaces.
> > > > We could keep the same model of segmenting the device fd address space,
> > > > perhaps adding ioctls to define the segment offset bit position or we
> > > > could split each region into it's own fd (VFIO_GET_PCI_BAR_FD(0),
> > > > VFIO_GET_PCI_CONFIG_FD(), VFIO_GET_MMIO_FD(3)), though we're already
> > > > suffering some degree of fd bloat (group fd, device fd(s), interrupt
> > > > event fd(s), per resource fd, etc). For interrupts we can overload
> > > > VFIO_SET_IRQ_EVENTFD to be either PCI INTx or non-PCI irq
> > >
> > > Sounds reasonable.
> > >
> > > > (do non-PCI
> > > > devices support MSI?).
> > >
> > > They can. Obviously they might not have exactly the same semantics as
> > > PCI MSIs, but I know we have SoC systems with (non-PCI) on-die devices
> > > whose interrupts are treated by the (also on-die) root interrupt
> > > controller in the same way as PCI MSIs.
> >
> > Ok, I suppose we can define ioctls to enable these as we go. We also
> > need to figure out how non-PCI resources, interrupts, and iommu mapping
> > restrictions are described via vfio.
>
> Yeah. On device tree platforms we'd want it to be bound to the device
> tree representation in some way.
>
> For platform devices, at least, could we have the index into the array
> of resources take the place of BAR number for PCI?
That's what I was thinking, but we need some way to describe the set of
valid indexes and type and size for each as well. We already have the
BAR_LEN helper ioctl, we could make that generic (RANGE_LEN?) and add
NUM_RANGES and RANGE_TYPE. For PCI there would always be 7 ranges (6
BARs + ROM).
> > > > For qemu, these changes imply we'd only support a model where we have a
> > > > 1:1 group to iommu domain. The current vfio driver could probably
> > > > become vfio-pci as we might end up with more target specific vfio
> > > > drivers for non-pci. PCI should be able to maintain a simple -device
> > > > vfio-pci,host=bb:dd.f to enable hotplug of individual devices. We'll
> > > > need to come up with extra options when we need to expose groups to
> > > > guest for pvdma.
> > >
> > > Are you saying that you'd no longer support the current x86 usage of
> > > putting all of one guest's devices into a single domain?
> >
> > Yes. I'm not sure there's a good ROI to prioritize that model. We have
> > to assume >1 device per guest is a typical model and that the iotlb is
> > large enough that we might improve thrashing to see both a resource and
> > performance benefit from it. I'm open to suggestions for how we could
> > include it though.
>
> Creating supergroups of some sort seems to be what we need, but I'm
> not sure what's the best interface for doing that.
Yeah. Joerg's idea of binding groups internally (pass the fd of one
group to another via ioctl) is one option. The tricky part will be
implementing it to support hot unplug of any group from the supergroup.
I believe Ben had a suggestion that supergroups could be created in
sysfs, but I don't know what the mechanism to do that looks like. It
would also be an extra management step to dynamically bind and unbind
groups to the supergroup around hotplug. Thanks,
Alex
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: aafabbri @ 2011-08-23 16:54 UTC (permalink / raw)
To: Joerg Roedel
Cc: Alexey Kardashevskiy, kvm@vger.kernel.org, Paul Mackerras,
linux-pci@vger.kernel.org, qemu-devel, chrisw, iommu, Avi Kivity,
Anthony Liguori, linuxppc-dev, benve@cisco.com
In-Reply-To: <20110823110431.GK2079@amd.com>
On 8/23/11 4:04 AM, "Joerg Roedel" <joerg.roedel@amd.com> wrote:
> On Mon, Aug 22, 2011 at 08:52:18PM -0400, aafabbri wrote:
>> You have to enforce group/iommu domain assignment whether you have the
>> existing uiommu API, or if you change it to your proposed
>> ioctl(inherit_iommu) API.
>>
>> The only change needed to VFIO here should be to make uiommu fd assignment
>> happen on the groups instead of on device fds. That operation fails or
>> succeeds according to the group semantics (all-or-none assignment/same
>> uiommu).
>
> That is makes uiommu basically the same as the meta-groups, right?
Yes, functionality seems the same, thus my suggestion to keep uiommu
explicit. Is there some need for group-groups besides defining sets of
groups which share IOMMU resources?
I do all this stuff (bringing up sets of devices which may share IOMMU
domain) dynamically from C applications. I don't really want some static
(boot-time or sysfs fiddling) supergroup config unless there is a good
reason KVM/power needs it.
As you say in your next email, doing it all from ioctls is very easy,
programmatically.
-Aaron Fabbri
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Alex Williamson @ 2011-08-23 17:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: chrisw, Alexey Kardashevskiy, kvm, Paul Mackerras,
linux-pci@vger.kernel.org, qemu-devel, aafabbri, iommu,
Avi Kivity, Anthony Liguori, linuxppc-dev, benve
In-Reply-To: <1314082483.30478.43.camel@pasglop>
On Tue, 2011-08-23 at 16:54 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2011-08-22 at 17:52 -0700, aafabbri wrote:
>
> > I'm not following you.
> >
> > You have to enforce group/iommu domain assignment whether you have the
> > existing uiommu API, or if you change it to your proposed
> > ioctl(inherit_iommu) API.
> >
> > The only change needed to VFIO here should be to make uiommu fd assignment
> > happen on the groups instead of on device fds. That operation fails or
> > succeeds according to the group semantics (all-or-none assignment/same
> > uiommu).
>
> Ok, so I missed that part where you change uiommu to operate on group
> fd's rather than device fd's, my apologies if you actually wrote that
> down :-) It might be obvious ... bare with me I just flew back from the
> US and I am badly jet lagged ...
I missed it too, the model I'm proposing entirely removes the uiommu
concept.
> So I see what you mean, however...
>
> > I think the question is: do we force 1:1 iommu/group mapping, or do we allow
> > arbitrary mapping (satisfying group constraints) as we do today.
> >
> > I'm saying I'm an existing user who wants the arbitrary iommu/group mapping
> > ability and definitely think the uiommu approach is cleaner than the
> > ioctl(inherit_iommu) approach. We considered that approach before but it
> > seemed less clean so we went with the explicit uiommu context.
>
> Possibly, the question that interest me the most is what interface will
> KVM end up using. I'm also not terribly fan with the (perceived)
> discrepancy between using uiommu to create groups but using the group fd
> to actually do the mappings, at least if that is still the plan.
Current code: uiommu creates the domain, we bind a vfio device to that
domain via a SET_UIOMMU_DOMAIN ioctl on the vfio device, then do
mappings via MAP_DMA on the vfio device (affecting all the vfio devices
bound to the domain)
My current proposal: "groups" are predefined. groups ~= iommu domain.
The iommu domain would probably be allocated when the first device is
bound to vfio. As each device is bound, it gets attached to the group.
DMAs are done via an ioctl on the group.
I think group + uiommu leads to effectively reliving most of the
problems with the current code. The only benefit is the group
assignment to enforce hardware restrictions. We still have the problem
that uiommu open() = iommu_domain_alloc(), whose properties are
meaningless without attached devices (groups). Which I think leads to
the same awkward model of attaching groups to define the domain, then we
end up doing mappings via the group to enforce ordering.
> If the separate uiommu interface is kept, then anything that wants to be
> able to benefit from the ability to put multiple devices (or existing
> groups) into such a "meta group" would need to be explicitly modified to
> deal with the uiommu APIs.
>
> I tend to prefer such "meta groups" as being something you create
> statically using a configuration interface, either via sysfs, netlink or
> ioctl's to a "control" vfio device driven by a simple command line tool
> (which can have the configuration stored in /etc and re-apply it at
> boot).
I cringe anytime there's a mention of "static". IMHO, we have to
support hotplug. That means "meta groups" change dynamically. Maybe
this supports the idea that we should be able to retrieve a new fd from
the group to do mappings. Any groups bound together will return the
same fd and the fd will persist so long as any member of the group is
open.
> That way, any program capable of exploiting VFIO "groups" will
> automatically be able to exploit those "meta groups" (or groups of
> groups) as well as long as they are supported on the system.
>
> If we ever have system specific constraints as to how such groups can be
> created, then it can all be handled at the level of that configuration
> tool without impact on whatever programs know how to exploit them via
> the VFIO interfaces.
I'd prefer to have the constraints be represented in the ioctl to bind
groups. It works or not and the platform gets to define what it
considers compatible. Thanks,
Alex
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Alex Williamson @ 2011-08-23 17:08 UTC (permalink / raw)
To: Roedel, Joerg
Cc: Alexey Kardashevskiy, kvm@vger.kernel.org, Paul Mackerras,
qemu-devel, chrisw, iommu, Avi Kivity, Anthony Liguori,
linux-pci@vger.kernel.org, linuxppc-dev, benve@cisco.com
In-Reply-To: <20110823131441.GN2079@amd.com>
On Tue, 2011-08-23 at 15:14 +0200, Roedel, Joerg wrote:
> On Mon, Aug 22, 2011 at 03:17:00PM -0400, Alex Williamson wrote:
> > On Mon, 2011-08-22 at 19:25 +0200, Joerg Roedel wrote:
>
> > > I am in favour of /dev/vfio/$GROUP. If multiple devices should be
> > > assigned to a guest, there can also be an ioctl to bind a group to an
> > > address-space of another group (certainly needs some care to not allow
> > > that both groups belong to different processes).
> >
> > That's an interesting idea. Maybe an interface similar to the current
> > uiommu interface, where you open() the 2nd group fd and pass the fd via
> > ioctl to the primary group. IOMMUs that don't support this would fail
> > the attach device callback, which would fail the ioctl to bind them. It
> > will need to be designed so any group can be removed from the super-set
> > and the remaining group(s) still works. This feels like something that
> > can be added after we get an initial implementation.
>
> Handling it through fds is a good idea. This makes sure that everything
> belongs to one process. I am not really sure yet if we go the way to
> just bind plain groups together or if we create meta-groups. The
> meta-groups thing seems somewhat cleaner, though.
I'm leaning towards binding because we need to make it dynamic, but I
don't really have a good picture of the lifecycle of a meta-group.
> > > Btw, a problem we havn't talked about yet entirely is
> > > driver-deassignment. User space can decide to de-assign the device from
> > > vfio while a fd is open on it. With PCI there is no way to let this fail
> > > (the .release function returns void last time i checked). Is this a
> > > problem, and yes, how we handle that?
> >
> > The current vfio has the same problem, we can't unbind a device from
> > vfio while it's attached to a guest. I think we'd use the same solution
> > too; send out a netlink packet for a device removal and have the .remove
> > call sleep on a wait_event(, refcnt == 0). We could also set a timeout
> > and SIGBUS the PIDs holding the device if they don't return it
> > willingly. Thanks,
>
> Putting the process to sleep (which would be uninterruptible) seems bad.
> The process would sleep until the guest releases the device-group, which
> can take days or months.
> The best thing (and the most intrusive :-) ) is to change PCI core to
> allow unbindings to fail, I think. But this probably further complicates
> the way to upstream VFIO...
Yes, it's not ideal but I think it's sufficient for now and if we later
get support for returning an error from release, we can set a timeout
after notifying the user to make use of that. Thanks,
Alex
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Aaron Fabbri @ 2011-08-23 17:33 UTC (permalink / raw)
To: Alex Williamson, Benjamin Herrenschmidt
Cc: Alexey Kardashevskiy, kvm, Paul Mackerras,
linux-pci@vger.kernel.org, qemu-devel, chrisw, iommu, Avi Kivity,
Anthony Liguori, linuxppc-dev, benve
In-Reply-To: <1314118861.2859.51.camel@bling.home>
On 8/23/11 10:01 AM, "Alex Williamson" <alex.williamson@redhat.com> wrote:
> On Tue, 2011-08-23 at 16:54 +1000, Benjamin Herrenschmidt wrote:
>> On Mon, 2011-08-22 at 17:52 -0700, aafabbri wrote:
>>
>>> I'm not following you.
>>>
>>> You have to enforce group/iommu domain assignment whether you have the
>>> existing uiommu API, or if you change it to your proposed
>>> ioctl(inherit_iommu) API.
>>>
>>> The only change needed to VFIO here should be to make uiommu fd assignment
>>> happen on the groups instead of on device fds. That operation fails or
>>> succeeds according to the group semantics (all-or-none assignment/same
>>> uiommu).
>>
>> Ok, so I missed that part where you change uiommu to operate on group
>> fd's rather than device fd's, my apologies if you actually wrote that
>> down :-) It might be obvious ... bare with me I just flew back from the
>> US and I am badly jet lagged ...
>
> I missed it too, the model I'm proposing entirely removes the uiommu
> concept.
>
>> So I see what you mean, however...
>>
>>> I think the question is: do we force 1:1 iommu/group mapping, or do we allow
>>> arbitrary mapping (satisfying group constraints) as we do today.
>>>
>>> I'm saying I'm an existing user who wants the arbitrary iommu/group mapping
>>> ability and definitely think the uiommu approach is cleaner than the
>>> ioctl(inherit_iommu) approach. We considered that approach before but it
>>> seemed less clean so we went with the explicit uiommu context.
>>
>> Possibly, the question that interest me the most is what interface will
>> KVM end up using. I'm also not terribly fan with the (perceived)
>> discrepancy between using uiommu to create groups but using the group fd
>> to actually do the mappings, at least if that is still the plan.
>
> Current code: uiommu creates the domain, we bind a vfio device to that
> domain via a SET_UIOMMU_DOMAIN ioctl on the vfio device, then do
> mappings via MAP_DMA on the vfio device (affecting all the vfio devices
> bound to the domain)
>
> My current proposal: "groups" are predefined. groups ~= iommu domain.
This is my main objection. I'd rather not lose the ability to have multiple
devices (which are all predefined as singleton groups on x86 w/o PCI
bridges) share IOMMU resources. Otherwise, 20 devices sharing buffers would
require 20x the IOMMU/ioTLB resources. KVM doesn't care about this case?
> The iommu domain would probably be allocated when the first device is
> bound to vfio. As each device is bound, it gets attached to the group.
> DMAs are done via an ioctl on the group.
>
> I think group + uiommu leads to effectively reliving most of the
> problems with the current code. The only benefit is the group
> assignment to enforce hardware restrictions. We still have the problem
> that uiommu open() = iommu_domain_alloc(), whose properties are
> meaningless without attached devices (groups). Which I think leads to
> the same awkward model of attaching groups to define the domain, then we
> end up doing mappings via the group to enforce ordering.
Is there a better way to allow groups to share an IOMMU domain?
Maybe, instead of having an ioctl to allow a group A to inherit the same
iommu domain as group B, we could have an ioctl to fully merge two groups
(could be what Ben was thinking):
A.ioctl(MERGE_TO_GROUP, B)
The group A now goes away and its devices join group B. If A ever had an
iommu domain assigned (and buffers mapped?) we fail.
Groups cannot get smaller (they are defined as minimum granularity of an
IOMMU, initially). They can get bigger if you want to share IOMMU
resources, though.
Any downsides to this approach?
-AF
>
>> If the separate uiommu interface is kept, then anything that wants to be
>> able to benefit from the ability to put multiple devices (or existing
>> groups) into such a "meta group" would need to be explicitly modified to
>> deal with the uiommu APIs.
>>
>> I tend to prefer such "meta groups" as being something you create
>> statically using a configuration interface, either via sysfs, netlink or
>> ioctl's to a "control" vfio device driven by a simple command line tool
>> (which can have the configuration stored in /etc and re-apply it at
>> boot).
>
> I cringe anytime there's a mention of "static". IMHO, we have to
> support hotplug. That means "meta groups" change dynamically. Maybe
> this supports the idea that we should be able to retrieve a new fd from
> the group to do mappings. Any groups bound together will return the
> same fd and the fd will persist so long as any member of the group is
> open.
>
>> That way, any program capable of exploiting VFIO "groups" will
>> automatically be able to exploit those "meta groups" (or groups of
>> groups) as well as long as they are supported on the system.
>>
>> If we ever have system specific constraints as to how such groups can be
>> created, then it can all be handled at the level of that configuration
>> tool without impact on whatever programs know how to exploit them via
>> the VFIO interfaces.
>
> I'd prefer to have the constraints be represented in the ioctl to bind
> groups. It works or not and the platform gets to define what it
> considers compatible. Thanks,
>
> Alex
>
^ permalink raw reply
* Re: [PATCH] powerpc: fixup QE_General4 errata
From: Timur Tabi @ 2011-08-23 17:48 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Kumar Gala, linuxppc-dev
In-Reply-To: <1314102605-9718-1-git-send-email-Joakim.Tjernlund@transmode.se>
Joakim Tjernlund wrote:
> QE_General4 should only round up the divisor iff divisor is > 3.
> Rounding up lower divisors makes the error too big, causing USB
> on MPC832x to fail.
>
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Acked-by: Timur Tabi <timur@freescale.com>
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Alex Williamson @ 2011-08-23 18:01 UTC (permalink / raw)
To: Aaron Fabbri
Cc: Alexey Kardashevskiy, kvm, Paul Mackerras, qemu-devel, chrisw,
iommu, Avi Kivity, Anthony Liguori, linux-pci@vger.kernel.org,
linuxppc-dev, benve
In-Reply-To: <CA79326A.FB97%aafabbri@cisco.com>
On Tue, 2011-08-23 at 10:33 -0700, Aaron Fabbri wrote:
>
>
> On 8/23/11 10:01 AM, "Alex Williamson" <alex.williamson@redhat.com> wrote:
>
> > On Tue, 2011-08-23 at 16:54 +1000, Benjamin Herrenschmidt wrote:
> >> On Mon, 2011-08-22 at 17:52 -0700, aafabbri wrote:
> >>
> >>> I'm not following you.
> >>>
> >>> You have to enforce group/iommu domain assignment whether you have the
> >>> existing uiommu API, or if you change it to your proposed
> >>> ioctl(inherit_iommu) API.
> >>>
> >>> The only change needed to VFIO here should be to make uiommu fd assignment
> >>> happen on the groups instead of on device fds. That operation fails or
> >>> succeeds according to the group semantics (all-or-none assignment/same
> >>> uiommu).
> >>
> >> Ok, so I missed that part where you change uiommu to operate on group
> >> fd's rather than device fd's, my apologies if you actually wrote that
> >> down :-) It might be obvious ... bare with me I just flew back from the
> >> US and I am badly jet lagged ...
> >
> > I missed it too, the model I'm proposing entirely removes the uiommu
> > concept.
> >
> >> So I see what you mean, however...
> >>
> >>> I think the question is: do we force 1:1 iommu/group mapping, or do we allow
> >>> arbitrary mapping (satisfying group constraints) as we do today.
> >>>
> >>> I'm saying I'm an existing user who wants the arbitrary iommu/group mapping
> >>> ability and definitely think the uiommu approach is cleaner than the
> >>> ioctl(inherit_iommu) approach. We considered that approach before but it
> >>> seemed less clean so we went with the explicit uiommu context.
> >>
> >> Possibly, the question that interest me the most is what interface will
> >> KVM end up using. I'm also not terribly fan with the (perceived)
> >> discrepancy between using uiommu to create groups but using the group fd
> >> to actually do the mappings, at least if that is still the plan.
> >
> > Current code: uiommu creates the domain, we bind a vfio device to that
> > domain via a SET_UIOMMU_DOMAIN ioctl on the vfio device, then do
> > mappings via MAP_DMA on the vfio device (affecting all the vfio devices
> > bound to the domain)
> >
> > My current proposal: "groups" are predefined. groups ~= iommu domain.
>
> This is my main objection. I'd rather not lose the ability to have multiple
> devices (which are all predefined as singleton groups on x86 w/o PCI
> bridges) share IOMMU resources. Otherwise, 20 devices sharing buffers would
> require 20x the IOMMU/ioTLB resources. KVM doesn't care about this case?
We do care, I just wasn't prioritizing it as heavily since I think the
typical model is probably closer to 1 device per guest.
> > The iommu domain would probably be allocated when the first device is
> > bound to vfio. As each device is bound, it gets attached to the group.
> > DMAs are done via an ioctl on the group.
> >
> > I think group + uiommu leads to effectively reliving most of the
> > problems with the current code. The only benefit is the group
> > assignment to enforce hardware restrictions. We still have the problem
> > that uiommu open() = iommu_domain_alloc(), whose properties are
> > meaningless without attached devices (groups). Which I think leads to
> > the same awkward model of attaching groups to define the domain, then we
> > end up doing mappings via the group to enforce ordering.
>
> Is there a better way to allow groups to share an IOMMU domain?
>
> Maybe, instead of having an ioctl to allow a group A to inherit the same
> iommu domain as group B, we could have an ioctl to fully merge two groups
> (could be what Ben was thinking):
>
> A.ioctl(MERGE_TO_GROUP, B)
>
> The group A now goes away and its devices join group B. If A ever had an
> iommu domain assigned (and buffers mapped?) we fail.
>
> Groups cannot get smaller (they are defined as minimum granularity of an
> IOMMU, initially). They can get bigger if you want to share IOMMU
> resources, though.
>
> Any downsides to this approach?
That's sort of the way I'm picturing it. When groups are bound
together, they effectively form a pool, where all the groups are peers.
When the MERGE/BIND ioctl is called on group A and passed the group B
fd, A can check compatibility of the domain associated with B, unbind
devices from the B domain and attach them to the A domain. The B domain
would then be freed and it would bump the refcnt on the A domain. If we
need to remove A from the pool, we call UNMERGE/UNBIND on B with the A
fd, it will remove the A devices from the shared object, disassociate A
with the shared object, re-alloc a domain for A and rebind A devices to
that domain.
This is where it seems like it might be helpful to make a GET_IOMMU_FD
ioctl so that an iommu object is ubiquitous and persistent across the
pool. Operations on any group fd work on the pool as a whole. Thanks,
Alex
^ permalink raw reply
* Re: [PATCH 8/9] arch/powerpc/sysdev/ehv_pic.c: add missing kfree
From: Timur Tabi @ 2011-08-23 18:38 UTC (permalink / raw)
To: Julia Lawall; +Cc: kernel-janitors, linux-kernel, Paul Mackerras, linuxppc-dev
In-Reply-To: <1312802283-9107-8-git-send-email-julia@diku.dk>
Julia Lawall wrote:
> At this point, ehv_pic has been allocated but not stored anywhere, so it
> should be freed before leaving the function.
Acked-by: Timur Tabi <timur@freescale.com>
FYI, Ashish is no longer with Freescale, so I've taken over maintainership of
ehv_pic.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 8/9] arch/powerpc/sysdev/ehv_pic.c: add missing kfree
From: Timur Tabi @ 2011-08-23 19:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Kumar Gala
Cc: kernel-janitors, Julia Lawall, linuxppc-dev, Paul Mackerras,
linux-kernel
In-Reply-To: <CAOZdJXX_BS7GMtmyqiS91QByhrjANtKpbqrstR8g-L80r_N8qg@mail.gmail.com>
Ben, Kumar, can one of you take a look at my question and help me out?
wrote:
> On Mon, Aug 8, 2011 at 7:18 AM, Julia Lawall <julia@diku.dk> wrote:
>
>> diff --git a/arch/powerpc/sysdev/ehv_pic.c b/arch/powerpc/sysdev/ehv_pic.c
>> index af1a5df..b6731e4 100644
>> --- a/arch/powerpc/sysdev/ehv_pic.c
>> +++ b/arch/powerpc/sysdev/ehv_pic.c
>> @@ -280,6 +280,7 @@ void __init ehv_pic_init(void)
>>
>> if (!ehv_pic->irqhost) {
>> of_node_put(np);
>> + kfree(ehv_pic);
>> return;
>> }
>
> Although the fix is correct, I think there is another bug in this
> function. 'np' is not released when the function finishes
> successfully. I've looked at other functions that use
> irq_alloc_host(), and most of them do the same thing: they don't call
> of_node_put() on the device node pointer. The only exception I've
> found is mpc5121_ads_cpld_pic_init().
>
> Ben, Kumar: am I missing something? irq_alloc_host() calls of_node_get():
>
> host->of_node = of_node_get(of_node);
>
> so doesn't that mean that the caller of irq_alloc_host() should
> release the device node pointer?
>
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Alex Williamson @ 2011-08-23 19:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: aafabbri, Alexey Kardashevskiy, kvm, Paul Mackerras,
linux-pci@vger.kernel.org, qemu-devel, David Gibson, chrisw,
iommu, Avi Kivity, Anthony Liguori, linuxppc-dev, benve
In-Reply-To: <1314046904.7662.37.camel@pasglop>
On Tue, 2011-08-23 at 07:01 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2011-08-22 at 09:45 -0600, Alex Williamson wrote:
>
> > Yes, that's the idea. An open question I have towards the configuration
> > side is whether we might add iommu driver specific options to the
> > groups. For instance on x86 where we typically have B:D.F granularity,
> > should we have an option not to trust multi-function devices and use a
> > B:D granularity for grouping?
>
> Or even B or range of busses... if you want to enforce strict isolation
> you really can't trust anything below a bus level :-)
>
> > Right, we can also combine models. Binding a device to vfio
> > creates /dev/vfio$GROUP, which only allows a subset of ioctls and no
> > device access until all the group devices are also bound. I think
> > the /dev/vfio/$GROUP might help provide an enumeration interface as well
> > though, which could be useful.
>
> Could be tho in what form ? returning sysfs pathes ?
I'm at a loss there, please suggest. I think we need an ioctl that
returns some kind of array of devices within the group and another that
maybe takes an index from that array and returns an fd for that device.
A sysfs path string might be a reasonable array element, but it sounds
like a pain to work with.
> > 1:1 group<->process is probably too strong. Not allowing concurrent
> > open()s on the group file enforces a single userspace entity is
> > responsible for that group. Device fds can be passed to other
> > processes, but only retrieved via the group fd. I suppose we could even
> > branch off the dma interface into a different fd, but it seems like we
> > would logically want to serialize dma mappings at each iommu group
> > anyway. I'm open to alternatives, this just seemed an easy way to do
> > it. Restricting on UID implies that we require isolated qemu instances
> > to run as different UIDs. I know that's a goal, but I don't know if we
> > want to make it an assumption in the group security model.
>
> 1:1 process has the advantage of linking to an -mm which makes the whole
> mmu notifier business doable. How do you want to track down mappings and
> do the second level translation in the case of explicit map/unmap (like
> on power) if you are not tied to an mm_struct ?
Right, I threw away the mmu notifier code that was originally part of
vfio because we can't do anything useful with it yet on x86. I
definitely don't want to prevent it where it makes sense though. Maybe
we just record current->mm on open and restrict subsequent opens to the
same.
> > Yes. I'm not sure there's a good ROI to prioritize that model. We have
> > to assume >1 device per guest is a typical model and that the iotlb is
> > large enough that we might improve thrashing to see both a resource and
> > performance benefit from it. I'm open to suggestions for how we could
> > include it though.
>
> Sharing may or may not be possible depending on setups so yes, it's a
> bit tricky.
>
> My preference is to have a static interface (and that's actually where
> your pet netlink might make some sense :-) to create "synthetic" groups
> made of other groups if the arch allows it. But that might not be the
> best approach. In another email I also proposed an option for a group to
> "capture" another one...
I already made some comments on this in a different thread, so I won't
repeat here.
> > > If that's
> > > not what you're saying, how would the domains - now made up of a
> > > user's selection of groups, rather than individual devices - be
> > > configured?
> > >
> > > > Hope that captures it, feel free to jump in with corrections and
> > > > suggestions. Thanks,
> > >
>
> Another aspect I don't see discussed is how we represent these things to
> the guest.
>
> On Power for example, I have a requirement that a given iommu domain is
> represented by a single dma window property in the device-tree. What
> that means is that that property needs to be either in the node of the
> device itself if there's only one device in the group or in a parent
> node (ie a bridge or host bridge) if there are multiple devices.
>
> Now I do -not- want to go down the path of simulating P2P bridges,
> besides we'll quickly run out of bus numbers if we go there.
>
> For us the most simple and logical approach (which is also what pHyp
> uses and what Linux handles well) is really to expose a given PCI host
> bridge per group to the guest. Believe it or not, it makes things
> easier :-)
I'm all for easier. Why does exposing the bridge use less bus numbers
than emulating a bridge?
On x86, I want to maintain that our default assignment is at the device
level. A user should be able to pick single or multiple devices from
across several groups and have them all show up as individual,
hotpluggable devices on bus 0 in the guest. Not surprisingly, we've
also seen cases where users try to attach a bridge to the guest,
assuming they'll get all the devices below the bridge, so I'd be in
favor of making this "just work" if possible too, though we may have to
prevent hotplug of those.
Given the device requirement on x86 and since everything is a PCI device
on x86, I'd like to keep a qemu command line something like -device
vfio,host=00:19.0. I assume that some of the iommu properties, such as
dma window size/address, will be query-able through an architecture
specific (or general if possible) ioctl on the vfio group fd. I hope
that will help the specification, but I don't fully understand what all
remains. Thanks,
Alex
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox