* Re: [PATCH] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig
From: Timur Tabi @ 2011-08-25 18:02 UTC (permalink / raw)
To: Greg KH; +Cc: sfr, linux-next, linux-kernel, linuxppc-dev
In-Reply-To: <20110825163234.GA31629@kroah.com>
Greg KH wrote:
> tested doesn't mean that it shouldn't still build properly for other
> platforms, right?
The problem is the dependency on MSR_GS, which is defined only for Book-E
PowerPC chips, not all PowerPC.
So I gave it some more thought, and technically ePAPR extends beyond Book-E, so
it's wrong for the driver to depend on anything specific to Book-E. I've
removed the code that breaks:
/* Check if we're running as a guest of a hypervisor */
if (!(mfmsr() & MSR_GS))
return;
> What is keeping the driver from building on all PPC, or even all arches
> today?
I've made a few changes, and it builds on all PPC now. I'll post a new patch.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Joerg Roedel @ 2011-08-25 18:05 UTC (permalink / raw)
To: Alex Williamson
Cc: chrisw, Alexey Kardashevskiy, kvm@vger.kernel.org, Paul Mackerras,
Roedel, Joerg, linux-pci@vger.kernel.org, qemu-devel,
Aaron Fabbri, iommu, Avi Kivity, Anthony Liguori, linuxppc-dev,
benve@cisco.com
In-Reply-To: <1314292832.2492.31.camel@x201.home>
On Thu, Aug 25, 2011 at 11:20:30AM -0600, Alex Williamson wrote:
> On Thu, 2011-08-25 at 12:54 +0200, Roedel, Joerg wrote:
> > We need to solve this differently. ARM is starting to use the iommu-api
> > too and this definitly does not work there. One possible solution might
> > be to make the iommu-ops per-bus.
>
> That sounds good. Is anyone working on it? It seems like it doesn't
> hurt to use this in the interim, we may just be watching the wrong bus
> and never add any sysfs group info.
I'll cook something up for RFC over the weekend.
> > Also the return type should not be long but something that fits into
> > 32bit on all platforms. Since you use -ENODEV, probably s32 is a good
> > choice.
>
> The convenience of using seg|bus|dev|fn was too much to resist, too bad
> it requires a full 32bits. Maybe I'll change it to:
> int iommu_device_group(struct device *dev, unsigned int *group)
If we really expect segment numbers that need the full 16 bit then this
would be the way to go. Otherwise I would prefer returning the group-id
directly and partition the group-id space for the error values (s32 with
negative numbers being errors).
> > > @@ -438,6 +439,10 @@ static int __init intel_iommu_setup(char *str)
> > > printk(KERN_INFO
> > > "Intel-IOMMU: disable supported super page\n");
> > > intel_iommu_superpage = 0;
> > > + } else if (!strncmp(str, "no_mf_groups", 12)) {
> > > + printk(KERN_INFO
> > > + "Intel-IOMMU: disable separate groups for multifunction devices\n");
> > > + intel_iommu_no_mf_groups = 1;
> >
> > This should really be a global iommu option and not be VT-d specific.
>
> You think? It's meaningless on benh's power systems.
But it is not meaningless on AMD-Vi systems :) There should be one
option for both.
On the other hand this requires an iommu= parameter on ia64, but thats
probably not that bad.
> > This looks like code duplication in the VT-d driver. It doesn't need to
> > be generalized now, but we should keep in mind to do a more general
> > solution later.
> > Maybe it is beneficial if the IOMMU drivers only setup the number in
> > dev->arch.iommu.groupid and the iommu-api fetches it from there then.
> > But as I said, this is some more work and does not need to be done for
> > this patch(-set).
>
> The iommu-api reaches into dev->arch.iommu.groupid? I figured we should
> at least start out with a lightweight, optional interface without the
> overhead of predefining groupids setup by bus notification callbacks in
> each iommu driver. Thanks,
As I said, this is just an idea for an later optimization. It is fine
for now as it is in this patch.
Joerg
^ permalink raw reply
* [PATCH] [v2] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig
From: Timur Tabi @ 2011-08-25 18:06 UTC (permalink / raw)
To: greg, sfr, linux-next, linux-kernel, linuxppc-dev
The ePAPR hypervisor byte channel driver is supposed to work on all
ePAPR-compliant embedded PowerPC systems, but it had a reference to the MSR_GS
bit, which is available only on Book-E systems.
Also fix a couple integer-to-pointer typecast problems.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
drivers/tty/ehv_bytechan.c | 8 ++------
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/ehv_bytechan.c b/drivers/tty/ehv_bytechan.c
index e67f70b..f733718 100644
--- a/drivers/tty/ehv_bytechan.c
+++ b/drivers/tty/ehv_bytechan.c
@@ -226,10 +226,6 @@ void __init udbg_init_ehv_bc(void)
unsigned int rx_count, tx_count;
unsigned int ret;
- /* Check if we're running as a guest of a hypervisor */
- if (!(mfmsr() & MSR_GS))
- return;
-
/* Verify the byte channel handle */
ret = ev_byte_channel_poll(CONFIG_PPC_EARLY_DEBUG_EHV_BC_HANDLE,
&rx_count, &tx_count);
@@ -286,7 +282,7 @@ static int ehv_bc_console_byte_channel_send(unsigned int handle, const char *s,
static void ehv_bc_console_write(struct console *co, const char *s,
unsigned int count)
{
- unsigned int handle = (unsigned int)co->data;
+ unsigned int handle = (uintptr_t)co->data;
char s2[EV_BYTE_CHANNEL_MAX_BYTES];
unsigned int i, j = 0;
char c;
@@ -352,7 +348,7 @@ static int __init ehv_bc_console_init(void)
CONFIG_PPC_EARLY_DEBUG_EHV_BC_HANDLE);
#endif
- ehv_bc_console.data = (void *)stdout_bc;
+ ehv_bc_console.data = (void *)(uintptr_t)stdout_bc;
/* add_preferred_console() must be called before register_console(),
otherwise it won't work. However, we don't want to enumerate all the
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig
From: Greg KH @ 2011-08-25 18:46 UTC (permalink / raw)
To: Timur Tabi; +Cc: sfr, linux-next, linux-kernel, linuxppc-dev
In-Reply-To: <4E568E19.405@freescale.com>
On Thu, Aug 25, 2011 at 01:02:01PM -0500, Timur Tabi wrote:
> Greg KH wrote:
> > tested doesn't mean that it shouldn't still build properly for other
> > platforms, right?
>
> The problem is the dependency on MSR_GS, which is defined only for Book-E
> PowerPC chips, not all PowerPC.
>
> So I gave it some more thought, and technically ePAPR extends beyond Book-E, so
> it's wrong for the driver to depend on anything specific to Book-E. I've
> removed the code that breaks:
>
> /* Check if we're running as a guest of a hypervisor */
> if (!(mfmsr() & MSR_GS))
> return;
But don't you really want this type of check at runtime? What happens
if you load this driver on a machine that is not a guest? Will things
break? Shouldn't you still refuse to load somehow?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig
From: Timur Tabi @ 2011-08-25 18:51 UTC (permalink / raw)
To: Greg KH; +Cc: sfr, linux-next, linux-kernel, linuxppc-dev
In-Reply-To: <20110825184655.GB1891@kroah.com>
Greg KH wrote:
> But don't you really want this type of check at runtime? What happens
> if you load this driver on a machine that is not a guest? Will things
> break? Shouldn't you still refuse to load somehow?
This is in the udbg code, which falls under the category of, "turn this on only
if you know what you're doing."
The udbg code runs very early, before the device tree is available. There's no
way of knowing at this point whether or not we're running under a hypervisor.
If you turn on udbg support, then it means that you're trying to do some very
specific debugging on a specific platform.
So I'm not removing this code just to fix the build break. It really should
never have been there in the first place.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig
From: Greg KH @ 2011-08-25 19:03 UTC (permalink / raw)
To: Timur Tabi; +Cc: sfr, linux-next, linux-kernel, linuxppc-dev
In-Reply-To: <4E5699A8.1070708@freescale.com>
On Thu, Aug 25, 2011 at 01:51:20PM -0500, Timur Tabi wrote:
> Greg KH wrote:
> > But don't you really want this type of check at runtime? What happens
> > if you load this driver on a machine that is not a guest? Will things
> > break? Shouldn't you still refuse to load somehow?
>
> This is in the udbg code, which falls under the category of, "turn this on only
> if you know what you're doing."
>
> The udbg code runs very early, before the device tree is available. There's no
> way of knowing at this point whether or not we're running under a hypervisor.
> If you turn on udbg support, then it means that you're trying to do some very
> specific debugging on a specific platform.
>
> So I'm not removing this code just to fix the build break. It really should
> never have been there in the first place.
Ok, thanks for the details, I'll queue up the patch in a bit.
greg k-h
^ permalink raw reply
* Re: [PATCH] xics/icp_natives: add __init to marker icp_native_init()
From: Timur Tabi @ 2011-08-25 19:24 UTC (permalink / raw)
To: Arnaud Lacombe; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1314288433-26322-1-git-send-email-lacombar@gmail.com>
Arnaud Lacombe wrote:
> This should fix the following warning:
>
> LD arch/powerpc/sysdev/xics/built-in.o
> WARNING: arch/powerpc/sysdev/xics/built-in.o(.text+0x1310): Section mismatch in
> reference from the function .icp_native_init() to the function
> .init.text:.icp_native_init_one_node()
> The function .icp_native_init() references
> the function __init .icp_native_init_one_node().
> This is often because .icp_native_init lacks a __init
> annotation or the annotation of .icp_native_init_one_node is wrong.
>
> icp_native_init() is only referenced in `arch/powerpc/sysdev/xics/xics-common.c'
> by xics_init() which is itself marked with __init.
>
> = not built-tested =
>
> Reported-by: Timur Tabi <timur@freescale.com>
> Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
Acked-by: Timur Tabi <timur@freescale.com>
This warning still appears, though:
WARNING: arch/powerpc/sysdev/built-in.o(.text+0xf6b8): Section mismatch in
reference from the function .ics_rtas_init() to the function
.init.text:.xics_register_ics()
The function .ics_rtas_init() references
the function __init .xics_register_ics().
This is often because .ics_rtas_init lacks a __init
annotation or the annotation of .xics_register_ics is wrong.
To fix this warning, you'll also need:
diff --git a/arch/powerpc/sysdev/xics/ics-rtas.c b/arch/powerpc/sysdev/xics/ics-
index c782f85..a125721 100644
--- a/arch/powerpc/sysdev/xics/ics-rtas.c
+++ b/arch/powerpc/sysdev/xics/ics-rtas.c
@@ -213,7 +213,7 @@ static int ics_rtas_host_match(struct ics *ics, struct devic
return !of_device_is_compatible(node, "chrp,iic");
}
-int ics_rtas_init(void)
+int __init ics_rtas_init(void)
{
ibm_get_xive = rtas_token("ibm,get-xive");
ibm_set_xive = rtas_token("ibm,set-xive");
However, now we get another similar warning:
WARNING: drivers/built-in.o(.text+0x259c484): Section mismatch in reference from
the function .tc3589x_keypad_open() to the function
.devinit.text:.tc3589x_keypad_init_key_hardware()
The function .tc3589x_keypad_open() references
the function __devinit .tc3589x_keypad_init_key_hardware().
This is often because .tc3589x_keypad_open lacks a __devinit
annotation or the annotation of .tc3589x_keypad_init_key_hardware is wrong.
I'm not sure what to do at this point, because I have a suspicion that adding
__devinit to tc3589x_keypad_open() is wrong.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply related
* Re: Kernel boot up
From: Scott Wood @ 2011-08-25 19:31 UTC (permalink / raw)
To: smitha.vanga; +Cc: linuxppc-dev
In-Reply-To: <07ACDFB8ECA8EF47863A613BC01BBB22035E3A70@HYD-MKD-MBX02.wipro.com>
On 08/25/2011 02:57 AM, smitha.vanga@wipro.com wrote:
> Hi Scott,
>
> I am currently trying to bring up 2.6.39 kernel on a target based on MPC8247
> Processor, using the attched .dts file . I get the below logs while the
> kernel is booting.
> I see that the unflattening of the device tree and the initial loading
> of the kernel and ramdisk file system is happening correctly. Can you
> point me where exactly I can look for this issue. I am attaching the
> .config and .dts file I am using.
Which error are you referring to?
> of-flash ff800000.flash: do_map_probe() failed
What kind of flash chip do you have? Does the node in the device tree
accurately describe it (four interleaved 8-bit chips that only do JEDEC
and not CFI)?
> PPP generic driver version 2.4.2
> PPP Deflate Compression module registered
> tun: Universal TUN/TAP device driver, 1.6
> tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
> eth0: fs_enet: 00:00:00:00:00:00
> eth1: fs_enet: 00:00:00:00:00:00
These MAC addresses should have been set in the device tree. If you're
using U-Boot, it should be doing the fixup.
> Populating /dev using udev: /sbin/udevd: '/lib/libc.so.6' library
> contains unsup
> ported TLS
> /sbin/udevd: '/lib/libc.so.6' library contains unsupported TLS
> /sbin/udevd: can't load library 'libc.so.6'
> FAIL
> /sbin/udevstart: '/lib/libc.so.6' library contains unsupported TLS
> /sbin/udevstart: '/lib/libc.so.6' library contains unsupported TLS
> /sbin/udevstart: can't load library 'libc.so.6'
> FAIL
This is a problem with the root filesystem, not the kernel.
-Scott
^ permalink raw reply
* Re: [PATCH] xics/icp_natives: add __init to marker icp_native_init()
From: Arnaud Lacombe @ 2011-08-25 20:00 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4E56A15D.8070406@freescale.com>
Hi,
On Thu, Aug 25, 2011 at 3:24 PM, Timur Tabi <timur@freescale.com> wrote:
> Arnaud Lacombe wrote:
>> This should fix the following warning:
>>
>> =A0LD =A0 =A0 =A0arch/powerpc/sysdev/xics/built-in.o
>> WARNING: arch/powerpc/sysdev/xics/built-in.o(.text+0x1310): Section mism=
atch in
>> reference from the function .icp_native_init() to the function
>> .init.text:.icp_native_init_one_node()
>> The function .icp_native_init() references
>> the function __init .icp_native_init_one_node().
>> This is often because .icp_native_init lacks a __init
>> annotation or the annotation of .icp_native_init_one_node is wrong.
>>
>> icp_native_init() is only referenced in `arch/powerpc/sysdev/xics/xics-c=
ommon.c'
>> by xics_init() which is itself marked with __init.
>>
>> =3D not built-tested =3D
>>
>> Reported-by: Timur Tabi <timur@freescale.com>
>> Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
>
> Acked-by: Timur Tabi <timur@freescale.com>
>
> This warning still appears, though:
>
> WARNING: arch/powerpc/sysdev/built-in.o(.text+0xf6b8): Section mismatch i=
n
> reference from the function .ics_rtas_init() to the function
> .init.text:.xics_register_ics()
> The function .ics_rtas_init() references
> the function __init .xics_register_ics().
> This is often because .ics_rtas_init lacks a __init
> annotation or the annotation of .xics_register_ics is wrong.
>
he, chain-reaction :)
> To fix this warning, you'll also need:
>
> diff --git a/arch/powerpc/sysdev/xics/ics-rtas.c b/arch/powerpc/sysdev/xi=
cs/ics-
> index c782f85..a125721 100644
> --- a/arch/powerpc/sysdev/xics/ics-rtas.c
> +++ b/arch/powerpc/sysdev/xics/ics-rtas.c
> @@ -213,7 +213,7 @@ static int ics_rtas_host_match(struct ics *ics, struc=
t devic
> =A0 =A0 =A0 =A0return !of_device_is_compatible(node, "chrp,iic");
> =A0}
>
> -int ics_rtas_init(void)
> +int __init ics_rtas_init(void)
> =A0{
> =A0 =A0 =A0 =A0ibm_get_xive =3D rtas_token("ibm,get-xive");
> =A0 =A0 =A0 =A0ibm_set_xive =3D rtas_token("ibm,set-xive");
>
>
> However, now we get another similar warning:
>
> WARNING: drivers/built-in.o(.text+0x259c484): Section mismatch in referen=
ce from
> the function .tc3589x_keypad_open() to the function
> .devinit.text:.tc3589x_keypad_init_key_hardware()
> The function .tc3589x_keypad_open() references
> the function __devinit .tc3589x_keypad_init_key_hardware().
> This is often because .tc3589x_keypad_open lacks a __devinit
> annotation or the annotation of .tc3589x_keypad_init_key_hardware is wron=
g.
>
> I'm not sure what to do at this point, because I have a suspicion that ad=
ding
> __devinit to tc3589x_keypad_open() is wrong.
>
tc3589x_keypad_init_key_hardware() annotation looks plain wrong.
- Arnaud
> --
> Timur Tabi
> Linux kernel developer at Freescale
>
>
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (tty tree related)
From: Stephen Rothwell @ 2011-08-26 0:39 UTC (permalink / raw)
To: Arnaud Lacombe; +Cc: Greg KH, linux-next, ppc-dev, Timur Tabi, linux-kernel
In-Reply-To: <CACqU3MUs_97=MuuKAjr-LeUT7kSRxtzSntwUeKeeH4n8s7SSGg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 604 bytes --]
Hi Arnaud,
On Thu, 25 Aug 2011 12:09:20 -0400 Arnaud Lacombe <lacombar@gmail.com> wrote:
>
> If you could provide an exhaustive list of them, I'd be interested. Do
> you account/reference them in the report you make on each new -next
> tree ?
I don't refer to them at all :-(
If you are not just referring to powerpc ones, then an x86_64
allmodconfig is a good place to start, there are several in there.
Otherwise, I will send you the results of some of my builds this evening.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH] dtc: remove some warnings
From: Stephen Rothwell @ 2011-08-26 1:26 UTC (permalink / raw)
To: David Gibson, jdl; +Cc: John Bonesio, ppc-dev, linux-kernel
I assume that these variables were used in the past but not removed when
their usage was removed.
Fixes these warnings:
scripts/dtc/dtc.c: In function 'main':
scripts/dtc/dtc.c:102:17: warning: variable 'check' set but not used [-Wunused-but-set-variable]
scripts/dtc/flattree.c: In function 'flat_read_mem_reserve':
scripts/dtc/flattree.c:700:14: warning: variable 'p' set but not used [-Wunused-but-set-variable]
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
scripts/dtc/dtc.c | 5 +----
scripts/dtc/flattree.c | 2 --
2 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/scripts/dtc/dtc.c b/scripts/dtc/dtc.c
index cbc0193..fc83355 100644
--- a/scripts/dtc/dtc.c
+++ b/scripts/dtc/dtc.c
@@ -99,7 +99,7 @@ int main(int argc, char *argv[])
const char *inform = "dts";
const char *outform = "dts";
const char *outname = "-";
- int force = 0, check = 0, sort = 0;
+ int force = 0, sort = 0;
const char *arg;
int opt;
FILE *outf = NULL;
@@ -137,9 +137,6 @@ int main(int argc, char *argv[])
case 'f':
force = 1;
break;
- case 'c':
- check = 1;
- break;
case 'q':
quiet++;
break;
diff --git a/scripts/dtc/flattree.c b/scripts/dtc/flattree.c
index ead0332..28d0b23 100644
--- a/scripts/dtc/flattree.c
+++ b/scripts/dtc/flattree.c
@@ -697,7 +697,6 @@ static struct reserve_info *flat_read_mem_reserve(struct inbuf *inb)
{
struct reserve_info *reservelist = NULL;
struct reserve_info *new;
- const char *p;
struct fdt_reserve_entry re;
/*
@@ -706,7 +705,6 @@ static struct reserve_info *flat_read_mem_reserve(struct inbuf *inb)
*
* First pass, count entries.
*/
- p = inb->ptr;
while (1) {
flat_read_chunk(inb, &re, sizeof(re));
re.address = fdt64_to_cpu(re.address);
--
1.7.5.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: [PATCH] [v2] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig
From: Stephen Rothwell @ 2011-08-26 3:33 UTC (permalink / raw)
To: Timur Tabi; +Cc: greg, linux-next, linux-kernel, linuxppc-dev
In-Reply-To: <1314295617-2953-1-git-send-email-timur@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 505 bytes --]
Hi all,
On Thu, 25 Aug 2011 13:06:57 -0500 Timur Tabi <timur@freescale.com> wrote:
>
> The ePAPR hypervisor byte channel driver is supposed to work on all
> ePAPR-compliant embedded PowerPC systems, but it had a reference to the MSR_GS
> bit, which is available only on Book-E systems.
>
> Also fix a couple integer-to-pointer typecast problems.
I applied this to linux-next today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: David Gibson @ 2011-08-26 4:20 UTC (permalink / raw)
To: Roedel, Joerg
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: <20110824110332.GH2079@amd.com>
On Wed, Aug 24, 2011 at 01:03:32PM +0200, Roedel, Joerg wrote:
> On Wed, Aug 24, 2011 at 05:33:00AM -0400, David Gibson wrote:
> > On Wed, Aug 24, 2011 at 11:14:26AM +0200, Roedel, Joerg wrote:
>
> > > I don't see a reason to make this meta-grouping static. It would harm
> > > flexibility on x86. I think it makes things easier on power but there
> > > are options on that platform to get the dynamic solution too.
> >
> > I think several people are misreading what Ben means by "static". I
> > would prefer to say 'persistent', in that the meta-groups lifetime is
> > not tied to an fd, but they can be freely created, altered and removed
> > during runtime.
>
> Even if it can be altered at runtime, from a usability perspective it is
> certainly the best to handle these groups directly in qemu. Or are there
> strong reasons to do it somewhere else?
Funny, Ben and I think usability demands it be the other way around.
If the meta-groups are transient - that is lifetime tied to an fd -
then any program that wants to use meta-groups *must* know the
interfaces for creating one, whatever they are.
But if they're persistent, the admin can use other tools to create the
meta-group then just hand it to a program to use, since the interfaces
for _using_ a meta-group are identical to those for an atomic group.
This doesn't preclude a program from being meta-group aware, and
creating its own if it wants to, of course. My guess is that qemu
would not want to build its own meta-groups, but libvirt probably
would.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: David Gibson @ 2011-08-26 4:24 UTC (permalink / raw)
To: Alexander Graf
Cc: Alex Williamson, Alexey Kardashevskiy, kvm@vger.kernel.org,
Paul Mackerras, Roedel, Joerg, qemu-devel, chrisw, iommu,
Avi Kivity, Anthony Liguori, linux-pci@vger.kernel.org,
linuxppc-dev, benve@cisco.com
In-Reply-To: <EC0C2298-1EC9-42A0-9A71-3671E21BCA56@suse.de>
On Thu, Aug 25, 2011 at 08:25:45AM -0500, Alexander Graf wrote:
>
> On 25.08.2011, at 07:31, Roedel, Joerg wrote:
>
> > On Wed, Aug 24, 2011 at 11:07:46AM -0400, Alex Williamson wrote:
> >> On Wed, 2011-08-24 at 10:52 +0200, Roedel, Joerg wrote:
> >
>
> [...]
>
> >> We need to try the polite method of attempting to hot unplug the device
> >> from qemu first, which the current vfio code already implements. We can
> >> then escalate if it doesn't respond. The current code calls abort in
> >> qemu if the guest doesn't respond, but I agree we should also be
> >> enforcing this at the kernel interface. I think the problem with the
> >> hard-unplug is that we don't have a good revoke mechanism for the mmio
> >> mmaps.
> >
> > For mmio we could stop the guest and replace the mmio region with a
> > region that is filled with 0xff, no?
>
> Sure, but that happens in user space. The question is how does
> kernel space enforce an MMIO region to not be mapped after the
> hotplug event occured? Keep in mind that user space is pretty much
> untrusted here - it doesn't have to be QEMU. It could just as well
> be a generic user space driver. And that can just ignore hotplug
> events.
We're saying you hard yank the mapping from the userspace process.
That is, you invalidate all its PTEs mapping the MMIO space, and don't
let it fault them back in.
As I see it there are two options: (a) make subsequent accesses from
userspace or the guest result in either a SIGBUS that userspace must
either deal with or die, or (b) replace the mapping with a dummy RO
mapping containing 0xff, with any trapped writes emulated as nops.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 2/2] [PowerPC Book3E] Introduce new ptrace debug feature flag
From: David Gibson @ 2011-08-26 4:41 UTC (permalink / raw)
To: Thiago Jung Bauermann; +Cc: linuxppc-dev, K.Prasad, Edjunior Barbosa Machado
In-Reply-To: <1314232903.14168.4.camel@hactar>
On Wed, Aug 24, 2011 at 09:41:43PM -0300, Thiago Jung Bauermann wrote:
> On Wed, 2011-08-24 at 14:00 +1000, David Gibson wrote:
> > On Tue, Aug 23, 2011 at 02:57:56PM +0530, K.Prasad wrote:
> > > On Tue, Aug 23, 2011 at 03:09:31PM +1000, David Gibson wrote:
> > > > On Fri, Aug 19, 2011 at 01:23:38PM +0530, K.Prasad wrote:
> > > > >
> > > > > While PPC_PTRACE_SETHWDEBUG ptrace flag in PowerPC accepts
> > > > > PPC_BREAKPOINT_MODE_EXACT mode of breakpoint, the same is not intimated to the
> > > > > user-space debuggers (like GDB) who may want to use it. Hence we introduce a
> > > > > new PPC_DEBUG_FEATURE_DATA_BP_EXACT flag which will be populated on the
> > > > > "features" member of "struct ppc_debug_info" to advertise support for the
> > > > > same on Book3E PowerPC processors.
> > > >
> > > > I thought the idea was that the BP_EXACT mode was the default - if the
> > > > new interface was supported at all, then BP_EXACT was always
> > > > supported. So, why do you need a new flag?
> > > >
> > >
> > > Yes, BP_EXACT was always supported but not advertised through
> > > PPC_PTRACE_GETHWDBGINFO. We're now doing that.
> >
> > I can see that. But you haven't answered why.
>
> BookS doesn't support BP_EXACT, that's why I suggested this flag.
Surely you can support it with exactly the same sort of filtering
you're using for the 8-byte ranges now?
> A BP_EXACT watchpoint triggers only when there's a memory access exactly
> at the given address. It doesn't trigger when there's (for example) a
> 4-byte write at an address immediately before which also changes the
> memory contents of the byte watched by the BP_EXACT watchpoint. a ranged
> watchpoint would trigger, so the semantics are different.
>
> As a general rule, GDB only sets ranged watchpoints and only uses
> BP_EXACT ones when the user sets a flag. I want GDB to fail when the
> user sets the flag on BookS since it can't provide the feature.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] dtc: remove some warnings
From: David Gibson @ 2011-08-26 4:49 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: John Bonesio, jdl, ppc-dev, linux-kernel
In-Reply-To: <20110826112643.f86132d55edc5d452df3ebd0@canb.auug.org.au>
On Fri, Aug 26, 2011 at 11:26:43AM +1000, Stephen Rothwell wrote:
> I assume that these variables were used in the past but not removed when
> their usage was removed.
>
> Fixes these warnings:
>
> scripts/dtc/dtc.c: In function 'main':
> scripts/dtc/dtc.c:102:17: warning: variable 'check' set but not used [-Wunused-but-set-variable]
> scripts/dtc/flattree.c: In function 'flat_read_mem_reserve':
> scripts/dtc/flattree.c:700:14: warning: variable 'p' set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Yeah, I noticed these gcc 4.6 warnings recently, but didn't get around
to sending a patch.
Jon, please apply. Uh.. except that this is a patch against the in
kernel dtc, rather than upstream.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] dtc: remove some warnings
From: Stephen Rothwell @ 2011-08-26 5:34 UTC (permalink / raw)
To: David Gibson; +Cc: John Bonesio, jdl, ppc-dev, linux-kernel
In-Reply-To: <20110826044902.GJ2308@yookeroo.fritz.box>
[-- Attachment #1: Type: text/plain, Size: 418 bytes --]
Hi David,
On Fri, 26 Aug 2011 14:49:02 +1000 David Gibson <dwg@au1.ibm.com> wrote:
>
> Jon, please apply. Uh.. except that this is a patch against the in
> kernel dtc, rather than upstream.
Yeah, Josh pointed out that these are fixed in upstream. I guess we need
to do another snapshot merge ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* RE: Kernel boot up
From: smitha.vanga @ 2011-08-26 6:00 UTC (permalink / raw)
To: scottwood; +Cc: linuxppc-dev
In-Reply-To: <4E56A30F.4010509@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 12768 bytes --]
Thanks scott.
There was an issue with the file system. Now my board is up with the
linux boot prompt .
But ping is not working. The local loopback ping works. My phy chip
BCM5221 is connected on port A
I am using FCC1 as the MAC. I see that the intrrupt handler is being
registered properly. And even the fs_enet_start_xmit() gets called and
it returns with return NETDEV_TX_OK. When I do a ifconfig -a
I see the TX packets count increases for the loop back device but not
for eth0. I am using the wireshark tool to see any packets on the witr.
But don't see any ARP packets coming out on the wire.
Can you please suggest . Below are the logs. Attache dis the .dts file.
I have commented the bcsr register part in the .dts is this required.
EPN412> bootm 1000000 2000000 c00000
## Current stack ends at 0x03e93cc8
* kernel: cmdline image address = 0x01000000
## Booting kernel from Legacy Image at 01000000 ...
Image Name: Linux-2.6.39
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1765760 Bytes = 1.7 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
kernel data at 0x01000040, len = 0x001af180 (1765760)
* ramdisk: cmdline image address = 0x02000000
## Loading init Ramdisk from Legacy Image at 02000000 ...
Image Name: uboot ext2 ramdisk rootfs
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 3972156 Bytes = 3.8 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
ramdisk start = 0x02000040, ramdisk end = 0x023c9c7c
* fdt: cmdline image address = 0x00c00000
## Checking for 'FDT'/'FDT Image' at 00c00000
* fdt: raw FDT blob
## Flattened Device Tree blob at 00c00000
Booting using the fdt blob at 0xc00000
of_flat_tree at 0x00c00000 size 0x00000f12
Uncompressing Kernel Image ... OK
kernel loaded at 0x00000000, end = 0x0038bd20
## initrd_high = 0xffffffff, copy_to_ram = 1
Loading Ramdisk to 03ac9000, end 03e92c3c ... OK
ramdisk load start = 0x03ac9000, ramdisk load end = 0x03e92c3c
## device tree at 00c00000 ... 00c00f11 (len=16146 [0x3F12])
Loading Device Tree to 007fc000, end 007fff11 ... OK
Updating property 'clock-frequency' = 00 fe 70 b8
Updating property 'bus-frequency' = 03 f9 c2 e0
Updating property 'timebase-frequency' = 00 7f 38 5c
Updating property 'clock-frequency' = 09 f0 67 30
## Transferring control to Linux (at address 00000000) ...
Booting using OF flat tree...
Using Freescale MPC8272 ADS machine description
Linux version 2.6.39 (2.6.39) (ktuser@ktuser) (gcc version 4.4.5
(Buildroot 2011.02) ) #7
Thu Aug 25 20:59:40 IST 2011
Found initrd at 0xc3ac9000:0xc3e92c3c
No bcsr in device tree
Zone PFN ranges:
DMA 0x00000000 -> 0x00004000
Normal empty
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00004000
Built 1 zonelists in Zone order, mobility grouping on. Total pages:
16256
Kernel command line: mem=64M root=/dev/ram rw
PID hash table entries: 256 (order: -2, 1024 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 56244k/65536k available (3528k kernel code, 9292k reserved, 104k
data, 1137k bss,
168k init)
Kernel virtual memory layout:
* 0xfffdf000..0xfffff000 : fixmap
* 0xfdfb6000..0xfe000000 : early ioremap
* 0xc5000000..0xfdfb6000 : vmalloc & ioremap
SLUB: Genslabs=15, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:512 nr_irqs:512 16
No pci pic node in device tree.
clocksource: timebase mult[1dfc2974] shift[22] registered
console [ttyCPM0] enabled
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
bio: create slab <bio-0> at 0
vgaarb: loaded
Switching to clocksource timebase
Switched to NOHz mode on CPU #0
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (no cpio magic); looks like an initrd
Freeing initrd memory: 3879k freed
msgmni has been set to 119
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
f0011a00.serial: ttyCPM0 at MMIO 0xc5014a00 (irq = 40) is a CPM UART
f0011a60.serial: ttyCPM1 at MMIO 0xc5018a60 (irq = 43) is a CPM UART
brd: module loaded
loop: module loaded
of-flash ff800000.flash: do_map_probe() failed
=====raj gem init
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
eth0: fs_enet: 00:00:00:00:00:00
eth1: fs_enet: 00:00:00:00:00:00
CPM2 Bitbanged MII: probed
mousedev: PS/2 mouse device common for all mice
TCP cubic registered
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
Freeing unused kernel memory: 168k init
Mounting /proc and /sys
Setting the hostname to mpc837xemds
Mounting filesystems
mount: mounting usbfs on /proc/bus/usb failed: No such file or directory
Starting syslogd and klogd
Running sysctl
Setting up networking on loopback device:
Setting up networking on eth0:
SIOCSIFFLAGS: Cannot assign requested address
Adding static route for default gateway to 192.168.1.1:
SIOCADDRT: Network is unreachable
Setting nameserver to 192.168.1.1 in /etc/resolv.conf:
Setting up networking on eth1:
SIOCSIFFLAGS: Cannot assign requested address
Adding static route for default gateway to 192.168.1.1:
SIOCADDRT: Network is unreachable
Setting nameserver to 192.168.1.1 in /etc/resolv.conf:
Starting inetd:
Please set the system time using
date <mmddhhmnyyyy>
/sbin/hwclock -w
Welcome to Freescale Semiconductor Embedded Linux Environment
!!!!! WARNING !!!!!!!
The default password for the root account is: root
please change this password using the 'passwd' command
and then edit this message (/etc/issue) to remove this message
mpc837xemds login: root
Password:
[root@mpc837xemds /root]#
[root@mpc837xemds /root]#
[root@mpc837xemds /root]#
[root@mpc837xemds /root]# cat /proc/interrupts
CPU0
40: 55 CPM2 SIU Level cpm_uart
LOC: 3507 Local timer interrupts
SPU: 0 Spurious interrupts
CNT: 0 Performance monitoring interrupts
MCE: 0 Machine check exceptions
[root@mpc837xemds /root]# cat /proc/interrupts
CPU0
40: 67 CPM2 SIU Level cpm_uart
LOC: 3536 Local timer interrupts
SPU: 0 Spurious interrupts
CNT: 0 Performance monitoring interrupts
MCE: 0 Machine check exceptions
[root@mpc837xemds /root]# ping localhost
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: seq=0 ttl=64 time=1.803 ms
64 bytes from 127.0.0.1: seq=1 ttl=64 time=1.784 ms
64 bytes from 127.0.0.1: seq=2 ttl=64 time=1.190 ms
64 bytes from 127.0.0.1: seq=3 ttl=64 time=1.187 ms
--- localhost ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 1.187/1.491/1.803 ms
[root@mpc837xemds /root]# cat /proc/interrupts
CPU0
40: 106 CPM2 SIU Level cpm_uart
LOC: 3636 Local timer interrupts
SPU: 0 Spurious interrupts
CNT: 0 Performance monitoring interrupts
MCE: 0 Machine check exceptions
[root@mpc837xemds /root]# ping l
[root@mpc837xemds /root]# ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:672 (672.0 b) TX bytes:672 (672.0 b)
[root@mpc837xemds /root]# ifconfig eth0 up
SIOCSIFFLAGS: Cannot assign requested address
[root@mpc837xemds /root]# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.1.100 Bcast:192.168.1.255
Mask:255.255.255.0
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
eth1 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.1.101 Bcast:192.168.1.255
Mask:255.255.255.0
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:672 (672.0 b) TX bytes:672 (672.0 b)
sit0 Link encap:UNSPEC HWaddr
00-00-00-00-04-22-10-02-00-00-00-00-00-00-00-00
NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
[root@mpc837xemds /root]# ifconfig eth0 hw ether 00:00:00:00:00:01
[root@mpc837xemds /root]# ifconfig eth0 up
ADDRCONF(NETDEV_UP): eth0: link is not ready
[root@mpc837xemds /root]# ADDRCONF(NETDEV_CHANGE): eth0: link becomes
ready
[root@mpc837xemds /root]#
[root@mpc837xemds /root]#
[root@mpc837xemds /root]#
[root@mpc837xemds /root]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:01
inet addr:192.168.1.100 Bcast:192.168.1.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:5
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:398 (398.0 b)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:672 (672.0 b) TX bytes:672 (672.0 b)
[root@mpc837xemds /root]# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
--- 192.168.1.1 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
[root@mpc837xemds /root]# cat /proc/interrupts
CPU0
32: 9 CPM2 SIU Level fs_enet-mac
40: 384 CPM2 SIU Level cpm_uart
LOC: 4369 Local timer interrupts
SPU: 0 Spurious interrupts
CNT: 0 Performance monitoring interrupts
MCE: 0 Machine check exceptions
[root@mpc837xemds /root]#
Regards,
Smitha
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
[-- Attachment #2: mpc8272ads.dts --]
[-- Type: application/octet-stream, Size: 6684 bytes --]
/*
* MPC8272 ADS Device Tree Source
*
* Copyright 2005,2008 Freescale Semiconductor Inc.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
*/
/dts-v1/;
/ {
model = "MPC8272ADS";
compatible = "fsl,mpc8272ads";
#address-cells = <1>;
#size-cells = <1>;
aliases {
ethernet0 = ð0;
ethernet1 = ð1;
serial0 = &scc1;
serial1 = &scc4;
};
cpus {
#address-cells = <1>;
#size-cells = <0>;
PowerPC,8247@0 {
device_type = "cpu";
reg = <0x0>;
d-cache-line-size = <32>;
i-cache-line-size = <32>;
d-cache-size = <16384>;
i-cache-size = <16384>;
timebase-frequency = <0>;
bus-frequency = <0>;
clock-frequency = <0>;
};
};
memory {
device_type = "memory";
reg = <0x0 0x4000000>;
};
localbus@f0010100 {
compatible = "fsl,mpc8272-localbus",
"fsl,pq2-localbus";
#address-cells = <2>;
#size-cells = <1>;
reg = <0xf0010100 0x40>;
ranges = <0x0 0x0 0xff800000 0x00800000>;
/* 0x1 0x0 0xf4500000 0x8000
0x3 0x0 0xf8200000 0x8000>; */
flash@0,0 {
compatible = "jedec-flash";
reg = <0x0 0x0 0x00800000>;
bank-width = <4>;
device-width = <1>;
};
/*
board-control@1,0 {
reg = <0x1 0x0 0x20>;
compatible = "fsl,mpc8272ads-bcsr";
};
PCI_PIC: interrupt-controller@3,0 {
compatible = "fsl,mpc8272ads-pci-pic",
"fsl,pq2ads-pci-pic";
#interrupt-cells = <1>;
interrupt-controller;
reg = <0x3 0x0 0x8>;
interrupt-parent = <&PIC>;
interrupts = <20 8>;
};
*/ };
/*
pci@f0010800 {
device_type = "pci";
reg = <0xf0010800 0x10c 0xf00101ac 0x8 0xf00101c4 0x8>;
compatible = "fsl,mpc8272-pci", "fsl,pq2-pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
clock-frequency = <66666666>;
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <
/* IDSEL 0x16
0xb000 0x0 0x0 0x1 &PCI_PIC 0
0xb000 0x0 0x0 0x2 &PCI_PIC 1
0xb000 0x0 0x0 0x3 &PCI_PIC 2
0xb000 0x0 0x0 0x4 &PCI_PIC 3
/* IDSEL 0x17
0xb800 0x0 0x0 0x1 &PCI_PIC 4
0xb800 0x0 0x0 0x2 &PCI_PIC 5
0xb800 0x0 0x0 0x3 &PCI_PIC 6
0xb800 0x0 0x0 0x4 &PCI_PIC 7
/* IDSEL 0x18
0xc000 0x0 0x0 0x1 &PCI_PIC 8
0xc000 0x0 0x0 0x2 &PCI_PIC 9
0xc000 0x0 0x0 0x3 &PCI_PIC 10
0xc000 0x0 0x0 0x4 &PCI_PIC 11>;
interrupt-parent = <&PIC>;
interrupts = <18 8>;
ranges = <0x42000000 0x0 0x80000000 0x80000000 0x0 0x20000000
0x2000000 0x0 0xa0000000 0xa0000000 0x0 0x20000000
0x1000000 0x0 0x0 0xf6000000 0x0 0x2000000>;
};
*/
soc@f0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
compatible = "fsl,mpc8272", "fsl,pq2-soc";
ranges = <0x0 0xf0000000 0x53000>;
// Temporary -- will go away once kernel uses ranges for get_immrbase().
reg = <0xf0000000 0x53000>;
cpm@119c0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8272-cpm", "fsl,cpm2";
reg = <0x119c0 0x30>;
ranges;
muram@0 {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x0 0x10000>;
data@0 {
compatible = "fsl,cpm-muram-data";
reg = <0x0 0x2000 0x9800 0x800>;
};
};
brg@119f0 {
compatible = "fsl,mpc8272-brg",
"fsl,cpm2-brg",
"fsl,cpm-brg";
reg = <0x119f0 0x10 0x115f0 0x10>;
};
scc1: serial@11a00 {
device_type = "serial";
compatible = "fsl,mpc8272-scc-uart",
"fsl,cpm2-scc-uart";
reg = <0x11a00 0x20 0x8000 0x100>;
interrupts = <40 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <1>;
fsl,cpm-command = <0x800000>;
};
scc4: serial@11a60 {
device_type = "serial";
compatible = "fsl,mpc8272-scc-uart",
"fsl,cpm2-scc-uart";
reg = <0x11a60 0x20 0x8300 0x100>;
interrupts = <43 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <4>;
fsl,cpm-command = <0xce00000>;
};
/* usb@11b60 {
compatible = "fsl,mpc8272-cpm-usb";
reg = <0x11b60 0x40 0x8b00 0x100>;
interrupts = <11 8>;
interrupt-parent = <&PIC>;
mode = "peripheral";
}; */
mdio@10d40 {
device_type = "mdio";
compatible = "fsl,mpc8272ads-mdio-bitbang",
"fsl,mpc8272-mdio-bitbang",
"fsl,cpm2-mdio-bitbang";
reg = <0x10d40 0x14>;
#address-cells = <1>;
#size-cells = <0>;
fsl,mdio-pin = <23>;
fsl,mdc-pin = <22>;
PHY0: ethernet-phy@0 {
interrupt-parent = <&PIC>;
interrupts = <23 8>;
reg = <0x0>;
device_type = "ethernet-phy";
};
PHY1: ethernet-phy@1 {
interrupt-parent = <&PIC>;
interrupts = <23 8>;
reg = <0x3>;
device_type = "ethernet-phy";
};
};
eth0: ethernet@11300 {
device_type = "network";
compatible = "fsl,mpc8272-fcc-enet",
"fsl,cpm2-fcc-enet";
reg = <0x11300 0x20 0x8400 0x100 0x11390 0x1>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <32 8>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY0>;
linux,network-index = <0>;
fsl,cpm-command = <0x12000300>;
};
eth1: ethernet@11320 {
device_type = "network";
compatible = "fsl,mpc8272-fcc-enet",
"fsl,cpm2-fcc-enet";
reg = <0x11320 0x20 0x8500 0x100 0x113b0 0x1>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <33 8>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY1>;
linux,network-index = <1>;
fsl,cpm-command = <0x16200300>;
};
i2c@11860 {
compatible = "fsl,mpc8272-i2c",
"fsl,cpm2-i2c";
reg = <0x11860 0x20 0x8afc 0x2>;
interrupts = <1 8>;
interrupt-parent = <&PIC>;
fsl,cpm-command = <0x29600000>;
#address-cells = <1>;
#size-cells = <0>;
};
};
PIC: interrupt-controller@10c00 {
#interrupt-cells = <2>;
interrupt-controller;
reg = <0x10c00 0x80>;
compatible = "fsl,mpc8272-pic", "fsl,cpm2-pic";
};
crypto@30000 {
compatible = "fsl,sec1.0";
reg = <0x40000 0x13000>;
interrupts = <47 0x8>;
interrupt-parent = <&PIC>;
fsl,num-channels = <4>;
fsl,channel-fifo-len = <24>;
fsl,exec-units-mask = <0x7e>;
fsl,descriptor-types-mask = <0x1010415>;
};
};
chosen {
linux,stdout-path = "/soc/cpm/serial@11a00";
};
};
^ permalink raw reply
* Re: [PATCH 2/2] mmc: Use mmc_delay() instead of mdelay() for time delay
From: Lan Chunhe @ 2011-08-26 8:45 UTC (permalink / raw)
To: Kyungmin Park, Chunhe Lan
Cc: linuxppc-dev, kumar.gala, Chris Ball, linux-mmc, Shengzhou Liu
In-Reply-To: <CAH9JG2VUA_5c=3LPEvoVmTrYN9WibY87AgEkNgV3uFpAS0euQA@mail.gmail.com>
On Thu, 25 Aug 2011 18:23:35 +0800, Kyungmin Park <kmpark@infradead.org>
wrote:
> On Thu, Aug 25, 2011 at 5:54 PM, Chunhe Lan <Chunhe.Lan@freescale.com>
> wrote:
>> The mmc_delay() is a wrapper function for mdelay() and msleep().
>>
>> o mdelay() -- block the system when busy-waiting.
>> o msleep() -- suspend the currently running task to enable CPU
>> to process other tasks, so it is non-blocking
>> regarding the whole system.
>>
>> When the desired delay time is more than a period of timer interrupt,
>> just use msleep(). Change mdelay() to mmc_delay() to avoid chewing
>> CPU when busy wait.
>>
>> Signed-off-by: Shengzhou Liu <b36685@freescale.com>
>> Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
>> Cc: Chris Ball <cjb@laptop.org>
>> ---
>> drivers/mmc/host/sdhci.c | 11 ++++++-----
>> 1 files changed, 6 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index 0e02cc1..0cb5dc1 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -27,6 +27,7 @@
>> #include <linux/mmc/host.h>
>>
>> #include "sdhci.h"
>> +#include "../core/core.h"
>
> Doesn't better to move the mmc_delay() to "include/linux/mmc/core.h"?
> and include it.
> I think It's not proper include syntax using relative path.
Yes, your suggestion is very good.
I will move the mmc_delay() to "include/linux/mmc/core.h" .
Thanks.
-Jack Lan
> Thank you,
> Kyungmin Park
>>
>> #define DRIVER_NAME "sdhci"
>>
^ permalink raw reply
* RE: [PATCH 2/2 v2] eSDHC: Fix errors when booting kernel with fsl esdhc
From: Zang Roy-R61911 @ 2011-08-26 8:44 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Wood Scott-B07421, Xu Lei-B33228, linux-mmc@vger.kernel.org,
akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20110812100450.GA23333@oksana.dev.rtsoft.ru>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW50b24gVm9yb250c292
IFttYWlsdG86Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbV0NCj4gU2VudDogRnJpZGF5LCBBdWd1c3Qg
MTIsIDIwMTEgMTg6MDUgUE0NCj4gVG86IFphbmcgUm95LVI2MTkxMQ0KPiBDYzogbGludXgtbW1j
QHZnZXIua2VybmVsLm9yZzsgbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7IGFrcG1AbGlu
dXgtDQo+IGZvdW5kYXRpb24ub3JnOyBYdSBMZWktQjMzMjI4OyBLdW1hciBHYWxhOyBXb29kIFNj
b3R0LUIwNzQyMQ0KPiBTdWJqZWN0OiBSZTogW1BBVENIIDIvMiB2Ml0gZVNESEM6IEZpeCBlcnJv
cnMgd2hlbiBib290aW5nIGtlcm5lbCB3aXRoIGZzbCBlc2RoYw0KPiANCj4gSGVsbG8sDQo+IA0K
PiBPbiBGcmksIEF1ZyAxMiwgMjAxMSBhdCAwOTo0NDoyNkFNICswMDAwLCBaYW5nIFJveS1SNjE5
MTEgd3JvdGU6DQo+IFsuLi5dDQo+ID4gPiBXZSB0cnkgdG8gbm90IHBvbGx1dGUgZ2VuZXJpYyBz
ZGhjaS5jIGRyaXZlciB3aXRoIGNoaXAtc3BlY2lmaWMNCj4gPiA+IHF1aXJrcy4NCj4gPiA+DQo+
ID4gPiBNYXliZSB5b3UgY2FuIGRvIHRoZSBmaXh1cHMgdmlhIElPIGFjY2Vzc29ycz8gT3IgYnkg
aW50cm9kdWNpbmcNCj4gPiA+IHNvbWUgYWRkaXRpb25hbCBzZGhjaSBvcD8NCj4gPiBBbnRvbiwN
Cj4gPiB0aGFua3MgZm9yIHRoZSBjb21tZW50LCBhcyB3ZSBkaXNjdXNzZWQsIHRoZSBvcmlnaW5h
bCBjb2RlIHVzZSA4IGJpdCBieXRlDQo+IG9wZXJhdGlvbiwNCj4gPiB3aGlsZSBpbiBmYWN0LCBv
biBzb21lIHBvd2VycGMgcGxhdGZvcm0sIDMyIGJpdCBvcGVyYXRpb24gaXMgbmVlZGVkLg0KPiA+
IHNob3VsZCBpdCBiZSBwb3NzaWJsZSBmaXhlZCBieSBhZGRpbmcgc29tZSB3cmFwcGVyIGluIElP
IGFjY2Vzc29ycyBvcg0KPiBpbnRyb2R1Y2UgYWRkaXRpb25hbCBzZGhjaSBvcD8NCj4gDQo+IEkg
d291bGQgZG8gaXQgaW4gdGhlIElPIGFjY2Vzc29ycy4NCkkgbWF5IG1pc3MgeW91ciBlbWFpbC4g
SSBuZXZlciBzZWUgeW91ciBwYXRjaCBhYm91dCAiIEkgd291bGQgZG8gaXQgaW4gdGhlIElPIGFj
Y2Vzc29ycyAiLg0KVGhhbmtzLg0KUm95DQoNCg==
^ permalink raw reply
* [PATCH 1/3 v2] mmc: Move mmc_delay() to include/linux/mmc/core.h
From: Chunhe Lan @ 2011-08-26 7:52 UTC (permalink / raw)
To: linux-mmc; +Cc: kumar.gala, Chris Ball, linuxppc-dev, Chunhe Lan
Move mmc_delay() from drivers/mmc/core/core.h to
include/linux/mmc/core.h. So when other functions
call it with include syntax using <linux/mmc/core.h>
of absolute path rather than "../core/core.h" of
relative path.
Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
Cc: Chris Ball <cjb@laptop.org>
---
drivers/mmc/core/core.h | 12 ------------
include/linux/mmc/core.h | 11 +++++++++++
2 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
index d9411ed..58c3f10 100644
--- a/drivers/mmc/core/core.h
+++ b/drivers/mmc/core/core.h
@@ -11,8 +11,6 @@
#ifndef _MMC_CORE_CORE_H
#define _MMC_CORE_CORE_H
-#include <linux/delay.h>
-
#define MMC_CMD_RETRIES 3
struct mmc_bus_ops {
@@ -44,16 +42,6 @@ int mmc_set_signal_voltage(struct mmc_host *host, int signal_voltage,
void mmc_set_timing(struct mmc_host *host, unsigned int timing);
void mmc_set_driver_type(struct mmc_host *host, unsigned int drv_type);
-static inline void mmc_delay(unsigned int ms)
-{
- if (ms < 1000 / HZ) {
- cond_resched();
- mdelay(ms);
- } else {
- msleep(ms);
- }
-}
-
void mmc_rescan(struct work_struct *work);
void mmc_start_host(struct mmc_host *host);
void mmc_stop_host(struct mmc_host *host);
diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
index b8b1b7a..7bc2798 100644
--- a/include/linux/mmc/core.h
+++ b/include/linux/mmc/core.h
@@ -10,6 +10,7 @@
#include <linux/interrupt.h>
#include <linux/device.h>
+#include <linux/delay.h>
struct request;
struct mmc_data;
@@ -182,6 +183,16 @@ static inline void mmc_claim_host(struct mmc_host *host)
__mmc_claim_host(host, NULL);
}
+static inline void mmc_delay(unsigned int ms)
+{
+ if (ms < 1000 / HZ) {
+ cond_resched();
+ mdelay(ms);
+ } else {
+ msleep(ms);
+ }
+}
+
extern u32 mmc_vddrange_to_ocrmask(int vdd_min, int vdd_max);
#endif /* LINUX_MMC_CORE_H */
--
1.7.5.1
^ permalink raw reply related
* [PATCH 2/3 v2] mmc: Use mmc_delay() instead of mdelay() for time delay
From: Chunhe Lan @ 2011-08-26 7:54 UTC (permalink / raw)
To: linux-mmc; +Cc: Shengzhou Liu, kumar.gala, Chris Ball, linuxppc-dev, Chunhe Lan
The mmc_delay() is a wrapper function for mdelay() and msleep().
o mdelay() -- block the system when busy-waiting.
o msleep() -- suspend the currently running task to enable CPU
to process other tasks, so it is non-blocking
regarding the whole system.
When the desired delay time is more than a period of timer interrupt,
just use msleep(). Change mdelay() to mmc_delay() to avoid chewing
CPU when busy wait.
Signed-off-by: Shengzhou Liu <b36685@freescale.com>
Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
Cc: Chris Ball <cjb@laptop.org>
---
drivers/mmc/host/sdhci-esdhc.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci-esdhc.h b/drivers/mmc/host/sdhci-esdhc.h
index c3b08f1..b8c0ab1 100644
--- a/drivers/mmc/host/sdhci-esdhc.h
+++ b/drivers/mmc/host/sdhci-esdhc.h
@@ -1,7 +1,7 @@
/*
* Freescale eSDHC controller driver generics for OF and pltfm.
*
- * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ * Copyright (c) 2007, 2011 Freescale Semiconductor, Inc.
* Copyright (c) 2009 MontaVista Software, Inc.
* Copyright (c) 2010 Pengutronix e.K.
* Author: Wolfram Sang <w.sang@pengutronix.de>
@@ -73,7 +73,7 @@ static inline void esdhc_set_clock(struct sdhci_host *host, unsigned int clock)
| (div << ESDHC_DIVIDER_SHIFT)
| (pre_div << ESDHC_PREDIV_SHIFT));
sdhci_writel(host, temp, ESDHC_SYSTEM_CONTROL);
- mdelay(100);
+ mmc_delay(100);
out:
host->clock = clock;
}
--
1.7.5.1
^ permalink raw reply related
* [PATCH 3/3 v2] mmc: Use mmc_delay() instead of mdelay() for time delay
From: Chunhe Lan @ 2011-08-26 7:55 UTC (permalink / raw)
To: linux-mmc; +Cc: Shengzhou Liu, kumar.gala, Chris Ball, linuxppc-dev, Chunhe Lan
The mmc_delay() is a wrapper function for mdelay() and msleep().
o mdelay() -- block the system when busy-waiting.
o msleep() -- suspend the currently running task to enable CPU
to process other tasks, so it is non-blocking
regarding the whole system.
When the desired delay time is more than a period of timer interrupt,
just use msleep(). Change mdelay() to mmc_delay() to avoid chewing
CPU when busy wait.
Signed-off-by: Shengzhou Liu <b36685@freescale.com>
Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
Cc: Chris Ball <cjb@laptop.org>
---
drivers/mmc/host/sdhci.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 0e02cc1..b0cf79f 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -186,7 +186,7 @@ static void sdhci_reset(struct sdhci_host *host, u8 mask)
return;
}
timeout--;
- mdelay(1);
+ mmc_delay(1);
}
if (host->ops->platform_reset_exit)
@@ -957,7 +957,7 @@ static void sdhci_send_command(struct sdhci_host *host, struct mmc_command *cmd)
return;
}
timeout--;
- mdelay(1);
+ mmc_delay(1);
}
mod_timer(&host->timer, jiffies + 10 * HZ);
@@ -1127,7 +1127,7 @@ static void sdhci_set_clock(struct sdhci_host *host, unsigned int clock)
return;
}
timeout--;
- mdelay(1);
+ mmc_delay(1);
}
clk |= SDHCI_CLOCK_CARD_EN;
@@ -1192,7 +1192,7 @@ static void sdhci_set_power(struct sdhci_host *host, unsigned short power)
* can apply clock after applying power
*/
if (host->quirks & SDHCI_QUIRK_DELAY_AFTER_POWER)
- mdelay(10);
+ mmc_delay(10);
}
/*****************************************************************************\
@@ -1712,7 +1712,7 @@ static int sdhci_execute_tuning(struct mmc_host *mmc)
ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
tuning_loop_counter--;
timeout--;
- mdelay(1);
+ mmc_delay(1);
} while (ctrl & SDHCI_CTRL_EXEC_TUNING);
/*
--
1.7.5.1
^ permalink raw reply related
* Re: kvm PCI assignment & VFIO ramblings
From: Roedel, Joerg @ 2011-08-26 9:24 UTC (permalink / raw)
To: Alexander Graf, Alexey Kardashevskiy, kvm@vger.kernel.org,
Paul Mackerras, qemu-devel, iommu, chrisw, Alex Williamson,
Avi Kivity, Anthony Liguori, linux-pci@vger.kernel.org,
linuxppc-dev, benve@cisco.com
In-Reply-To: <20110826042423.GF2308@yookeroo.fritz.box>
On Fri, Aug 26, 2011 at 12:24:23AM -0400, David Gibson wrote:
> On Thu, Aug 25, 2011 at 08:25:45AM -0500, Alexander Graf wrote:
> > On 25.08.2011, at 07:31, Roedel, Joerg wrote:
> > > For mmio we could stop the guest and replace the mmio region with a
> > > region that is filled with 0xff, no?
> >
> > Sure, but that happens in user space. The question is how does
> > kernel space enforce an MMIO region to not be mapped after the
> > hotplug event occured? Keep in mind that user space is pretty much
> > untrusted here - it doesn't have to be QEMU. It could just as well
> > be a generic user space driver. And that can just ignore hotplug
> > events.
>
> We're saying you hard yank the mapping from the userspace process.
> That is, you invalidate all its PTEs mapping the MMIO space, and don't
> let it fault them back in.
>
> As I see it there are two options: (a) make subsequent accesses from
> userspace or the guest result in either a SIGBUS that userspace must
> either deal with or die, or (b) replace the mapping with a dummy RO
> mapping containing 0xff, with any trapped writes emulated as nops.
The biggest problem with this approach is that it has to happen in the
context of the given process. Linux can't really modify an mm which
which belong to another context in a safe way.
The more I think about this, I come to the conclusion that it would be
the best to just kill the process accessing the device if it is manually
de-assigned from vfio. It should be a non-standard path anyway so it
doesn't make a lot of sense to implement complicated handling semantics
for it, no?
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-26 9:33 UTC (permalink / raw)
To: aafabbri, 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: <20110826042000.GE2308@yookeroo.fritz.box>
On Fri, Aug 26, 2011 at 12:20:00AM -0400, David Gibson wrote:
> On Wed, Aug 24, 2011 at 01:03:32PM +0200, Roedel, Joerg wrote:
> > On Wed, Aug 24, 2011 at 05:33:00AM -0400, David Gibson wrote:
> > > On Wed, Aug 24, 2011 at 11:14:26AM +0200, Roedel, Joerg wrote:
> >
> > > > I don't see a reason to make this meta-grouping static. It would harm
> > > > flexibility on x86. I think it makes things easier on power but there
> > > > are options on that platform to get the dynamic solution too.
> > >
> > > I think several people are misreading what Ben means by "static". I
> > > would prefer to say 'persistent', in that the meta-groups lifetime is
> > > not tied to an fd, but they can be freely created, altered and removed
> > > during runtime.
> >
> > Even if it can be altered at runtime, from a usability perspective it is
> > certainly the best to handle these groups directly in qemu. Or are there
> > strong reasons to do it somewhere else?
>
> Funny, Ben and I think usability demands it be the other way around.
The reason is that you mean the usability for the programmer and I mean
it for the actual user of qemu :)
> If the meta-groups are transient - that is lifetime tied to an fd -
> then any program that wants to use meta-groups *must* know the
> interfaces for creating one, whatever they are.
>
> But if they're persistent, the admin can use other tools to create the
> meta-group then just hand it to a program to use, since the interfaces
> for _using_ a meta-group are identical to those for an atomic group.
>
> This doesn't preclude a program from being meta-group aware, and
> creating its own if it wants to, of course. My guess is that qemu
> would not want to build its own meta-groups, but libvirt probably
> would.
Doing it in libvirt makes it really hard for a plain user of qemu to
assign more than one device to a guest. What I want it that a user just
types
qemu -device vfio,host=00:01.0 -device vfio,host=00:02.0 ...
and it just works. Qemu creates the meta-groups and they are
automatically destroyed when qemu exits. That the programs are not aware
of meta-groups is not a big problem because all software using vfio
needs still to be written :)
Btw, with this concept the programmer can still decide to not use
meta-groups and just multiplex the mappings to all open device-fds it
uses.
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
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