* Re: [PATCH hail] const-correctness tweaks
From: Jeff Garzik @ 2010-10-20 8:36 UTC (permalink / raw)
To: Jim Meyering; +Cc: Project Hail
In-Reply-To: <878w1t5m5k.fsf@meyering.net>
On 10/20/2010 04:00 AM, Jim Meyering wrote:
> Jeff Garzik wrote:
>
>> On 10/06/2010 08:07 AM, Jim Meyering wrote:
>>>
>>> Make write_cb callback's buffer parameter const, like all write-like
>>> functions.
>>> Give a few "char *" parameters the "const" attribute.
>>>
>>> Signed-off-by: Jim Meyering<meyering@redhat.com>
>>> ---
>>>
>>> It looks like most of hail's interfaces are const-correct,
>>> but one stood out because it provokes a warning when I tried to
>>> pass a const-correct write_cb function to hstor_get from iwhd:
>>>
>>> proxy.c:382: warning: passing argument 4 of 'hstor_get' from \
>>> incompatible pointer type
>>> /usr/include/hstor.h:173: note: expected \
>>> 'size_t (*)(void *, size_t, size_t, void *)' but argument is of type \
>>> 'size_t (*)(const void *, size_t, size_t, void *)'
>>>
>>> In case you feel comfortable fixing this, here's a patch:
>>
>>
>> Sorry for not getting back to this; I had hoped to solve some
>> additional problems that cropped up, but didn't have time. So, to
>> forestall further delay,
>>
>> libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -pthread
>> -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
>> -I/usr/include/libxml2 -O2 -Wall -Wshadow -g -MT hutil.lo -MD -MP -MF
>> .deps/hutil.Tpo -c hutil.c -o hutil.o
>> hutil.c: In function ‘hreq_hdr_push’:
>> hutil.c:145: warning: assignment discards qualifiers from pointer
>> target type
>> hutil.c:146: warning: assignment discards qualifiers from pointer
>> target type
>>
>> warnings appear after this patch. When solving these warnings with
>> const' markers, it quickly becomes a bit of a rat's nest.
>>
>> At a minimum, the write_cb callback signature must match libcurl's,
>> which does not use 'const'. I can see this makes sense from libcurl
>> implementation's perspective, even if it does not really match the
>> constness one expects from a foo-get function.
>
> Hi Jeff.
>
> Sorry I didn't notice that the first time.
> I built with ./autogen.sh&& ./configure&& make.
> It looks like you recommend -Wall -Wshadow.
>
> The two warnings above are the only ones I see with the patch,
> and they're easy to fix. When storing const pointer params into
> a struct like that, I've found that it's best to cast away the "const",
> which really does reflect the semantics: by using "const" on the
> parameter, I view it as promising not to deref through the pointer
> *in that function*. Since it's usually not reasonable to make
> the struct member "const" (as you saw, it propagates too far
> and often ends up being contradictory), the lesser evil of the cast
> is preferable here.
>
> If you're still game, the following incremental patch seems to be
> enough for me: Let me know and I'll resubmit the full one.
Well, my primary concern now originates from curl_easy_setopt(3)
documentation:
CURLOPT_WRITEFUNCTION
Function pointer that should match the following
prototype: size_t function( void *ptr, size_t size,
size_t nmemb, void *stream);
hstor's callback is passed directly to libcurl, so we seem to be bound
by outside constraints, no?
Jeff
^ permalink raw reply
* Re: [PATCHv4 4/4] iommu: create new api to set valid da range
From: felipe.contreras @ 2010-10-20 8:35 UTC (permalink / raw)
To: Fernando Guzman Lugo
Cc: Hiroshi.DOYU, felipe.contreras, david.cohen, linux-kernel,
linux-omap
In-Reply-To: <1287542932-14206-5-git-send-email-x0095840@ti.com>
On Wed, Oct 20, 2010 at 5:48 AM, Fernando Guzman Lugo <x0095840@ti.com> wrote:
> Some IOMMUs cannot use the whole 0x0 - 0xFFFFFFFF range.
> With this new API the valid range can be set.
>
> Signed-off-by: Fernando Guzman Lugo <x0095840@ti.com>
I don't see the point in having an API. It could be done through
platform data, and the usage of 0xFFFFF000 instead of ULONG_MAX is
independent of this.
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index f5a1aad..db919254 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -43,6 +43,7 @@ static struct iommu_device omap3_devices[] = {
.name = "iva2",
.nr_tlb_entries = 32,
.clk_name = "iva2_ck",
+ .start_addr = 0x11000000,
},
},
#endif
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 33c7d41..94f3a9a 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -50,6 +50,8 @@ struct iommu {
int (*isr)(struct iommu *obj);
void *ctx; /* iommu context: registres saved area */
+
+ u32 start_addr;
};
struct cr_regs {
@@ -103,6 +105,7 @@ struct iommu_platform_data {
const char *name;
const char *clk_name;
const int nr_tlb_entries;
+ u32 start_addr;
};
#if defined(CONFIG_ARCH_OMAP1)
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index 6336ae2..3023d0b 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -926,6 +926,10 @@ static int __devinit omap_iommu_probe(struct
platform_device *pdev)
obj->name = pdata->name;
obj->dev = &pdev->dev;
obj->ctx = (void *)obj + sizeof(*obj);
+ obj->start_addr = pdata->start_addr;
+
+ if (!obj->start_addr)
+ obj->start_addr = PAGE_SIZE;
mutex_init(&obj->iommu_lock);
mutex_init(&obj->mmap_lock);
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index f318476..fd0c93f 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -284,7 +284,7 @@ static struct iovm_struct *alloc_iovm_area(struct
iommu *obj, u32 da,
/*
* Reserve the first page for NULL
*/
- start = PAGE_SIZE;
+ start = obj->start_addr;
if (flags & IOVMF_LINEAR)
alignement = iopgsz_max(bytes);
start = roundup(start, alignement);
--
Felipe Contreras
^ permalink raw reply related
* [patch 1/9] efikamx: read board id
From: Arnaud Patard (Rtp) @ 2010-10-20 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20101020082418.GF28242@pengutronix.de>
Sascha Hauer <s.hauer@pengutronix.de> writes:
> On Tue, Oct 19, 2010 at 04:30:25PM -0500, Matt Sealey wrote:
>> On Tue, Oct 19, 2010 at 4:15 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
>> > On Tue, Oct 19, 2010 at 10:42:54PM +0200, Arnaud Patard wrote:
>> >> read board id value from the GPIO3_16/17/11
>> >>
>> >>
>> >> +/* ? PCBID2 ?PCBID1 PCBID0 ?STATE
>> >> + ? ? 1 ? ? ? 1 ? ? ?1 ? ?ER1:rev1.1
>> >> + ? ? 1 ? ? ? 1 ? ? ?0 ? ?ER2:rev1.2
>> >> + ? ? 1 ? ? ? 0 ? ? ?1 ? ?ER3:rev1.3
>> >> + ? ? 1 ? ? ? 0 ? ? ?0 ? ?ER4:rev1.4
>> >> +*/
>> >> +static void __init mx51_efikamx_board_id(void)
>> >> +{
>> >> + ? ? int id;
>> >> +
>> >> + ? ? /* things are taking time to settle */
>> >> + ? ? msleep(500);
>> >
>> > Is it really necessary to delay the boot process such a long time?
>>
>> Yes. On older boards the PCBID pins are pulled high by IOMUX settings
>> (a pulldown on the board on newer revisions will keep it down). IOMUX
>> and GPIO stuff takes a little while to settle in, so if you do it
>> immediately, it will return some freakish values based on random GPIO
>> setup (it may be high, low, or none of the above at any point before
>> the pad setting kicks in).
>
> Maybe it's possible to delay only the registering of the devices which
> depend on the board revision, perhaps with a workqueue. But ok, I don't
> care much and this won't be a show stopper for this patch.
ok. Will wait a little bit more for comments and send a new patchset.
Thanks,
Arnaud
^ permalink raw reply
* [PATCH 4/4] ARM: S5PV310: Add audio platform devices
From: Kukjin Kim @ 2010-10-20 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1287472517-563-1-git-send-email-jassisinghbrar@gmail.com>
Jassi Brar wrote:
>
> From: Jassi Brar <jassi.brar@samsung.com>
>
> Define platform devices for all audio devices found on S5PV310
>
> Signed-off-by: Jassi Brar <jassi.brar@samsung.com>
> ---
> arch/arm/mach-s5pv310/Makefile | 1 +
> arch/arm/mach-s5pv310/dev-audio.c | 356
> +++++++++++++++++++++++++++++++++++++
> 2 files changed, 357 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-s5pv310/dev-audio.c
>
(snip)
> +static int s5pv310_cfg_i2s(struct platform_device *pdev)
> +{
> + /* configure GPIO for i2s port */
> + switch (pdev->id) {
> + case 0:
> + s3c_gpio_cfgpin(S5PV310_GPZ(0), S3C_GPIO_SFN(2));
> + s3c_gpio_cfgpin(S5PV310_GPZ(1), S3C_GPIO_SFN(2));
> + s3c_gpio_cfgpin(S5PV310_GPZ(2), S3C_GPIO_SFN(2));
> + s3c_gpio_cfgpin(S5PV310_GPZ(3), S3C_GPIO_SFN(2));
> + s3c_gpio_cfgpin(S5PV310_GPZ(4), S3C_GPIO_SFN(2));
> + s3c_gpio_cfgpin(S5PV310_GPZ(5), S3C_GPIO_SFN(2));
> + s3c_gpio_cfgpin(S5PV310_GPZ(6), S3C_GPIO_SFN(2));
s3c_gpio_cfgpin_range(S5PV310_GPZ(0), 7, S3C_GPIO_SFN(2));
(snip)
> +
> +static struct resource s5pv310_iis0_resource[] = {
> + [0] = {
> + .start = S5PV310_PA_IIS0,
^
> + .end = S5PV310_PA_IIS0 + 0x100 - 1,
^^^
> + .flags = IORESOURCE_MEM,
^
It would be better if you could use tab above like following.
.start = S5PV310_PA_IIS0,
.end = S5PV310_PA_IIS0 + 0x100 - 1,
.flags = IORESOURCE_MEM,
(snip)
> +
> +struct platform_device s5pv310_device_iis0 = {
> + .name = "samsung-i2s",
> + .id = 0,
> + .num_resources = ARRAY_SIZE(s5pv310_iis0_resource),
> + .resource = s5pv310_iis0_resource,
> + .dev = {
> + .platform_data = &i2sv5_pdata,
> + },
> +};
> +
I'm thinking about the name of IIS/I2S...Hmm...
(snip)
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* RE: [PATCH 1/2] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
From: Zang Roy-R61911 @ 2010-10-20 8:33 UTC (permalink / raw)
To: Kumar Gala
Cc: Wood Scott-B07421, dedekind1, Lan Chunhe-B25806, linuxppc-dev,
linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <707F7370-D01B-462F-B896-D7F677AED8EB@kernel.crashing.org>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Wednesday, October 20, 2010 14:55 PM
> To: Zang Roy-R61911
> Cc: linux-mtd@lists.infradead.org; Wood Scott-B07421;
dedekind1@gmail.com; Lan
> Chunhe-B25806; linuxppc-dev@ozlabs.org; akpm@linux-foundation.org;
> dwmw2@infradead.org; Gala Kumar-B11780
> Subject: Re: [PATCH 1/2] P4080/eLBC: Make Freescale elbc interrupt
common to
> elbc devices
>
>
> On Oct 20, 2010, at 12:12 AM, Zang Roy-R61911 wrote:
>
> >
> >
> >> -----Original Message-----
> >> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> >> Sent: Tuesday, October 19, 2010 21:19 PM
> >> To: Zang Roy-R61911
> >> Cc: linux-mtd@lists.infradead.org; Wood Scott-B07421;
> > dedekind1@gmail.com; Lan
> >> Chunhe-B25806; linuxppc-dev@ozlabs.org; akpm@linux-foundation.org;
> >> dwmw2@infradead.org; Gala Kumar-B11780
> >> Subject: Re: [PATCH 1/2] P4080/eLBC: Make Freescale elbc interrupt
> > common to
> >> elbc devices
> >>
> >>
> >> On Oct 18, 2010, at 2:22 AM, Roy Zang wrote:
> >>
> >>> Move Freescale elbc interrupt from nand dirver to elbc driver.
> >>> Then all elbc devices can use the interrupt instead of ONLY nand.
> >>>
> >>> For former nand driver, it had the two functions:
> >>>
> >>> 1. detecting nand flash partitions;
> >>> 2. registering elbc interrupt.
> >>>
> >>> Now, second function is removed to fsl_lbc.c.
> >>>
> >>> Signed-off-by: Lan Chunhe-B25806 <b25806@freescale.com>
> >>> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> >>> Reviewed-by: Anton Vorontsov <cbouatmailru@gmail.com>
> >>> Cc: Wood Scott-B07421 <B07421@freescale.com>
> >>> ---
> >>
> >> Roy, this is a nit, but are these really p4080 specific? just
> > wondering why
> >> the subject is P4080/eLBC:...
> > We start these code in P4080 project. Some customer want to track
eLBC
> > error on P4080, but some of the code is limited in nand driver only
...
> > That is why P4080/eLBC ...
> > Roy
>
> sure, but is anything about these patches p4080 specific?
No.
Should I update the subject by a new version.
Thanks.
Roy
^ permalink raw reply
* RE: [PATCH 1/2] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
From: Zang Roy-R61911 @ 2010-10-20 8:33 UTC (permalink / raw)
To: Kumar Gala
Cc: Wood Scott-B07421, dedekind1, Lan Chunhe-B25806, linuxppc-dev,
linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <707F7370-D01B-462F-B896-D7F677AED8EB@kernel.crashing.org>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Wednesday, October 20, 2010 14:55 PM
> To: Zang Roy-R61911
> Cc: linux-mtd@lists.infradead.org; Wood Scott-B07421;
dedekind1@gmail.com; Lan
> Chunhe-B25806; linuxppc-dev@ozlabs.org; akpm@linux-foundation.org;
> dwmw2@infradead.org; Gala Kumar-B11780
> Subject: Re: [PATCH 1/2] P4080/eLBC: Make Freescale elbc interrupt
common to
> elbc devices
>=20
>=20
> On Oct 20, 2010, at 12:12 AM, Zang Roy-R61911 wrote:
>=20
> >
> >
> >> -----Original Message-----
> >> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> >> Sent: Tuesday, October 19, 2010 21:19 PM
> >> To: Zang Roy-R61911
> >> Cc: linux-mtd@lists.infradead.org; Wood Scott-B07421;
> > dedekind1@gmail.com; Lan
> >> Chunhe-B25806; linuxppc-dev@ozlabs.org; akpm@linux-foundation.org;
> >> dwmw2@infradead.org; Gala Kumar-B11780
> >> Subject: Re: [PATCH 1/2] P4080/eLBC: Make Freescale elbc interrupt
> > common to
> >> elbc devices
> >>
> >>
> >> On Oct 18, 2010, at 2:22 AM, Roy Zang wrote:
> >>
> >>> Move Freescale elbc interrupt from nand dirver to elbc driver.
> >>> Then all elbc devices can use the interrupt instead of ONLY nand.
> >>>
> >>> For former nand driver, it had the two functions:
> >>>
> >>> 1. detecting nand flash partitions;
> >>> 2. registering elbc interrupt.
> >>>
> >>> Now, second function is removed to fsl_lbc.c.
> >>>
> >>> Signed-off-by: Lan Chunhe-B25806 <b25806@freescale.com>
> >>> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> >>> Reviewed-by: Anton Vorontsov <cbouatmailru@gmail.com>
> >>> Cc: Wood Scott-B07421 <B07421@freescale.com>
> >>> ---
> >>
> >> Roy, this is a nit, but are these really p4080 specific? just
> > wondering why
> >> the subject is P4080/eLBC:...
> > We start these code in P4080 project. Some customer want to track
eLBC
> > error on P4080, but some of the code is limited in nand driver only
...
> > That is why P4080/eLBC ...
> > Roy
>=20
> sure, but is anything about these patches p4080 specific?
No.
Should I update the subject by a new version.
Thanks.
Roy
^ permalink raw reply
* Re: [Qemu-devel] KVM call minutes for Oct 19
From: Paolo Bonzini @ 2010-10-20 8:25 UTC (permalink / raw)
To: Alexander Graf; +Cc: Chris Wright, qemu-devel, kvm
In-Reply-To: <4DE00079-05FA-40DF-9EA5-9573AD745117@suse.de>
On 10/20/2010 10:21 AM, Alexander Graf wrote:
> Would it be realistic to declare deprecating the qemu-kvm fork for
> 0.14 as goal?
I recall some performance problems with the qemu.git iothread, I'm not
sure all of those have been fixed.
Paolo
^ permalink raw reply
* [U-Boot] [PATCH] ppc4xx: Fix default environment for AMCC boards
From: Stefan Roese @ 2010-10-20 8:31 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1287124861-26381-1-git-send-email-sr@denx.de>
On Friday 15 October 2010 08:41:01 Stefan Roese wrote:
> Commit 0ad7f0950a9bc0a69b3cd5f34ccf7da25fcf1c6d [ppc4xx: cleanup
> default environment for AMCC boards] broke the default env for
> many PPC4xx boards. The '\0' character got removed at the end
> of some environment commands like "update". This patch adds the
> missing '\0' characters again.
Applied to u-boot-ppc4xx/master. Thanks.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de
^ permalink raw reply
* [PATCH] mtd: OneNAND: S5PC110: Fix double call suspend & resume function
From: Kyungmin Park @ 2010-10-20 8:31 UTC (permalink / raw)
To: linux-mtd; +Cc: Artem.Bityutskiy, dwmw2
From: Kyungmin Park <kyungmin.park@samsung.com>
The suspend & resume called from mtd core. So no need to call at driver.
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
diff --git a/drivers/mtd/onenand/samsung.c b/drivers/mtd/onenand/samsung.c
index 214ed1e..0de7a05 100644
--- a/drivers/mtd/onenand/samsung.c
+++ b/drivers/mtd/onenand/samsung.c
@@ -1098,7 +1098,7 @@ static int s3c_pm_ops_suspend(struct device *dev)
struct onenand_chip *this = mtd->priv;
this->wait(mtd, FL_PM_SUSPENDED);
- return mtd->suspend(mtd);
+ return 0;
}
static int s3c_pm_ops_resume(struct device *dev)
@@ -1107,7 +1107,6 @@ static int s3c_pm_ops_resume(struct device *dev)
struct mtd_info *mtd = platform_get_drvdata(pdev);
struct onenand_chip *this = mtd->priv;
- mtd->resume(mtd);
this->unlock_all(mtd);
return 0;
}
^ permalink raw reply related
* [U-Boot] [PATCH] ppc4xx: Enable NOR flash support in sequoia_ramboot target
From: Stefan Roese @ 2010-10-20 8:31 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1286805010-23323-1-git-send-email-sr@denx.de>
On Monday 11 October 2010 15:50:10 Stefan Roese wrote:
> Until now, the Sequoia RAM-booting image disabled NOR flash support
> as this image was mainly created for NAND-only boards. This patch
> now enables NOR flash support for this RAM-booting version as well.
Applied to u-boot-ppc4xx/master. Thanks.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de
^ permalink raw reply
* [U-Boot] [PATCH] ppc4xx/POST: Add board specific UART POST test to lwmon5
From: Stefan Roese @ 2010-10-20 8:30 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1286453785-32612-1-git-send-email-sr@denx.de>
On Thursday 07 October 2010 14:16:25 Stefan Roese wrote:
> Add CONFIG_POST_UART to implement a board specific UART POST test.
> This is done since lwmon5 needs to set POST_ALWAYS to run this
> test on each reboot. And we don't want to change the default
> behavious of this this.
Applied to u-boot-ppc4xx/master. Thanks.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de
^ permalink raw reply
* Re: [Qemu-devel] KVM call minutes for Oct 19
From: Alexander Graf @ 2010-10-20 8:30 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Chris Wright, qemu-devel, kvm
In-Reply-To: <4CBEA790.9050208@redhat.com>
On 20.10.2010, at 10:25, Paolo Bonzini wrote:
> On 10/20/2010 10:21 AM, Alexander Graf wrote:
>> Would it be realistic to declare deprecating the qemu-kvm fork for
>> 0.14 as goal?
>
> I recall some performance problems with the qemu.git iothread, I'm not sure all of those have been fixed.
Yes, hence "declare as goal". Deprecating doesn't mean to declare it void, but to actually work towards eliminating all the shortcomings. Another thing coming to mind there is that the default -accel should be moved to kvm,tcg instead of only tcg as it stands today.
Alex
^ permalink raw reply
* [U-Boot] [PATCH] ppc4xx: Change tsr/tcr macros to upper case
From: Stefan Roese @ 2010-10-20 8:30 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1286183380-27831-1-git-send-email-sr@denx.de>
On Monday 04 October 2010 11:09:40 Stefan Roese wrote:
> Remove uneccessary functions to access the TCR/TSR registers as well.
Applied to u-boot-ppc4xx/master. Thanks.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de
^ permalink raw reply
* Re: [Qemu-devel] KVM call minutes for Oct 19
From: Alexander Graf @ 2010-10-20 8:30 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Chris Wright, kvm, qemu-devel
In-Reply-To: <4CBEA790.9050208@redhat.com>
On 20.10.2010, at 10:25, Paolo Bonzini wrote:
> On 10/20/2010 10:21 AM, Alexander Graf wrote:
>> Would it be realistic to declare deprecating the qemu-kvm fork for
>> 0.14 as goal?
>
> I recall some performance problems with the qemu.git iothread, I'm not sure all of those have been fixed.
Yes, hence "declare as goal". Deprecating doesn't mean to declare it void, but to actually work towards eliminating all the shortcomings. Another thing coming to mind there is that the default -accel should be moved to kvm,tcg instead of only tcg as it stands today.
Alex
^ permalink raw reply
* [Lustre-devel] Queries regarding LDLM_ENQUEUE
From: bzzz.tomas at gmail.com @ 2010-10-20 8:30 UTC (permalink / raw)
To: lustre-devel
In-Reply-To: <9C26CBA7-8DBD-4875-8E14-FB663B749096@oracle.com>
On 10/20/10 12:24 PM, Andreas Dilger wrote:
> I'm reluctant to expose the whole FID namespace to applications, since this completely bypasses all directory permissions and allows opening files only based on their inode permissions. If we require a name_to_handle() syscall to succeed first, before allowing open_by_handle() to work, then at least we know that one of the involved processes was able to do a full path traversal.
yes, this is a good point. can be solved if you use FID +
capability/signature ?
>> another idea was to do whole path traversal on MDS within a single RPC.
>> bug that'd require amount of changes to llite and/or VFS and keep MDS
>> a bottleneck.
>
> This was discussed a long time ago, and has the potential drawback that if one of the path components is over-mounted on the client (e.g. local RAM-based tmpfs on a Lustre root filesystem) then the MDS-side path traversal would be incorrect. It could return an entry underneath the mountpoint, instead of inside it.
yes, and that could be solved if server returns a series of FIDs,
then client could check whether any of those is over-mounted?
thanks, z
^ permalink raw reply
* [PATCH 2/5] qemu-kvm: Ioctl for in-kernel mask support
From: Sheng Yang @ 2010-10-20 8:29 UTC (permalink / raw)
To: Avi Kivity, Marcelo Tosatti; +Cc: Michael S. Tsirkin, kvm, Sheng Yang
In-Reply-To: <1287563395-30039-1-git-send-email-sheng@linux.intel.com>
Signed-off-by: Sheng Yang <sheng@linux.intel.com>
---
qemu-kvm.c | 9 +++++++++
qemu-kvm.h | 4 ++++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/qemu-kvm.c b/qemu-kvm.c
index fbb68f6..bb817d6 100644
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -1108,6 +1108,15 @@ int kvm_assign_set_msix_entry(kvm_context_t kvm,
{
return kvm_vm_ioctl(kvm_state, KVM_ASSIGN_SET_MSIX_ENTRY, entry);
}
+
+#ifdef KVM_CAP_DEVICE_MSIX_MASK
+int kvm_assign_reg_msix_mmio(kvm_context_t kvm,
+ struct kvm_assigned_msix_mmio *msix_mmio)
+{
+ return kvm_vm_ioctl(kvm_state, KVM_ASSIGN_REG_MSIX_MMIO, msix_mmio);
+}
+#endif
+
#endif
#if defined(KVM_CAP_IRQFD) && defined(CONFIG_EVENTFD)
diff --git a/qemu-kvm.h b/qemu-kvm.h
index 5cac0c2..ff8ca00 100644
--- a/qemu-kvm.h
+++ b/qemu-kvm.h
@@ -751,6 +751,10 @@ int kvm_assign_set_msix_nr(kvm_context_t kvm,
struct kvm_assigned_msix_nr *msix_nr);
int kvm_assign_set_msix_entry(kvm_context_t kvm,
struct kvm_assigned_msix_entry *entry);
+#ifdef KVM_CAP_DEVICE_MSIX_MASK
+int kvm_assign_reg_msix_mmio(kvm_context_t kvm,
+ struct kvm_assigned_msix_mmio *msix_mmio);
+#endif
#endif
#else /* !CONFIG_KVM */
--
1.7.0.1
^ permalink raw reply related
* [PATCH 3/5] qemu-kvm: device assignment: Some clean up about MSI-X code
From: Sheng Yang @ 2010-10-20 8:29 UTC (permalink / raw)
To: Avi Kivity, Marcelo Tosatti; +Cc: Michael S. Tsirkin, kvm, Sheng Yang
In-Reply-To: <1287563395-30039-1-git-send-email-sheng@linux.intel.com>
Signed-off-by: Sheng Yang <sheng@linux.intel.com>
---
hw/device-assignment.c | 77 ++++++++++++++++++++++++++++++++---------------
1 files changed, 52 insertions(+), 25 deletions(-)
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index 2605bd1..8a98876 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -1106,15 +1106,10 @@ static void assigned_dev_update_msi(PCIDevice *pci_dev, unsigned int ctrl_pos)
#endif
#ifdef KVM_CAP_DEVICE_MSIX
-static int assigned_dev_update_msix_mmio(PCIDevice *pci_dev)
+static int get_msix_entries_max_nr(AssignedDevice *adev)
{
- AssignedDevice *adev = container_of(pci_dev, AssignedDevice, dev);
- uint16_t entries_nr = 0, entries_max_nr;
- int pos = 0, i, r = 0;
- uint32_t msg_addr, msg_upper_addr, msg_data, msg_ctrl;
- struct kvm_assigned_msix_nr msix_nr;
- struct kvm_assigned_msix_entry msix_entry;
- void *va = adev->msix_table_page;
+ int pos, entries_max_nr;
+ PCIDevice *pci_dev = &adev->dev;
if (adev->cap.available & ASSIGNED_DEVICE_CAP_MSI)
pos = pci_dev->cap.start + PCI_CAPABILITY_CONFIG_MSI_LENGTH;
@@ -1125,6 +1120,17 @@ static int assigned_dev_update_msix_mmio(PCIDevice *pci_dev)
entries_max_nr &= PCI_MSIX_TABSIZE;
entries_max_nr += 1;
+ return entries_max_nr;
+}
+
+static int get_msix_valid_entries_nr(AssignedDevice *adev,
+ uint16_t entries_max_nr)
+{
+ void *va = adev->msix_table_page;
+ uint32_t msg_data, msg_ctrl;
+ uint16_t entries_nr = 0;
+ int i;
+
/* Get the usable entry number for allocating */
for (i = 0; i < entries_max_nr; i++) {
memcpy(&msg_ctrl, va + i * 16 + 12, 4);
@@ -1134,11 +1140,20 @@ static int assigned_dev_update_msix_mmio(PCIDevice *pci_dev)
continue;
entries_nr ++;
}
+ return entries_nr;
+}
+
+static int assigned_dev_update_msix_mmio(PCIDevice *pci_dev,
+ uint16_t entries_nr,
+ uint16_t entries_max_nr)
+{
+ AssignedDevice *adev = container_of(pci_dev, AssignedDevice, dev);
+ int i, r = 0;
+ uint32_t msg_addr, msg_upper_addr, msg_data, msg_ctrl;
+ struct kvm_assigned_msix_nr msix_nr;
+ struct kvm_assigned_msix_entry msix_entry;
+ void *va = adev->msix_table_page;
- if (entries_nr == 0) {
- fprintf(stderr, "MSI-X entry number is zero!\n");
- return -EINVAL;
- }
msix_nr.assigned_dev_id = calc_assigned_dev_id(adev->h_segnr, adev->h_busnr,
(uint8_t)adev->h_devfn);
msix_nr.entry_nr = entries_nr;
@@ -1180,8 +1195,8 @@ static int assigned_dev_update_msix_mmio(PCIDevice *pci_dev)
adev->entry[entries_nr].u.msi.address_lo = msg_addr;
adev->entry[entries_nr].u.msi.address_hi = msg_upper_addr;
adev->entry[entries_nr].u.msi.data = msg_data;
- DEBUG("MSI-X data 0x%x, MSI-X addr_lo 0x%x\n!", msg_data, msg_addr);
- kvm_add_routing_entry(&adev->entry[entries_nr]);
+ DEBUG("MSI-X data 0x%x, MSI-X addr_lo 0x%x!\n", msg_data, msg_addr);
+ kvm_add_routing_entry(&adev->entry[entries_nr]);
msix_entry.gsi = adev->entry[entries_nr].gsi;
msix_entry.entry = i;
@@ -1190,7 +1205,7 @@ static int assigned_dev_update_msix_mmio(PCIDevice *pci_dev)
fprintf(stderr, "fail to set MSI-X entry! %s\n", strerror(-r));
break;
}
- DEBUG("MSI-X entry gsi 0x%x, entry %d\n!",
+ DEBUG("MSI-X entry gsi 0x%x, entry %d!\n",
msix_entry.gsi, msix_entry.entry);
entries_nr ++;
}
@@ -1203,12 +1218,12 @@ static int assigned_dev_update_msix_mmio(PCIDevice *pci_dev)
return r;
}
-static void assigned_dev_update_msix(PCIDevice *pci_dev, unsigned int ctrl_pos)
+static void assigned_dev_update_msix(PCIDevice *pci_dev, int enable_msix)
{
struct kvm_assigned_irq assigned_irq_data;
AssignedDevice *assigned_dev = container_of(pci_dev, AssignedDevice, dev);
- uint16_t *ctrl_word = (uint16_t *)(pci_dev->config + ctrl_pos);
int r;
+ uint16_t entries_nr, entries_max_nr;
memset(&assigned_irq_data, 0, sizeof assigned_irq_data);
assigned_irq_data.assigned_dev_id =
@@ -1219,8 +1234,7 @@ static void assigned_dev_update_msix(PCIDevice *pci_dev, unsigned int ctrl_pos)
* try to catch this by only deassigning irqs if the guest is using
* MSIX or intends to start. */
if ((assigned_dev->irq_requested_type & KVM_DEV_IRQ_GUEST_MSIX) ||
- (*ctrl_word & PCI_MSIX_ENABLE)) {
-
+ enable_msix) {
assigned_irq_data.flags = assigned_dev->irq_requested_type;
free_dev_irq_entries(assigned_dev);
r = kvm_deassign_irq(kvm_context, &assigned_irq_data);
@@ -1231,14 +1245,25 @@ static void assigned_dev_update_msix(PCIDevice *pci_dev, unsigned int ctrl_pos)
assigned_dev->irq_requested_type = 0;
}
- if (*ctrl_word & PCI_MSIX_ENABLE) {
- assigned_irq_data.flags = KVM_DEV_IRQ_HOST_MSIX |
- KVM_DEV_IRQ_GUEST_MSIX;
-
- if (assigned_dev_update_msix_mmio(pci_dev) < 0) {
+ entries_max_nr = get_msix_entries_max_nr(assigned_dev);
+ if (entries_max_nr == 0) {
+ fprintf(stderr, "assigned_dev_update_msix: MSI-X entries_max_nr == 0");
+ return;
+ }
+ entries_nr = get_msix_valid_entries_nr(assigned_dev, entries_max_nr);
+ if (entries_nr == 0) {
+ if (enable_msix)
+ fprintf(stderr, "MSI-X entry number is zero!\n");
+ return;
+ }
+ if (enable_msix) {
+ if (assigned_dev_update_msix_mmio(pci_dev,
+ entries_nr, entries_max_nr) < 0) {
perror("assigned_dev_update_msix_mmio");
return;
}
+ assigned_irq_data.flags = KVM_DEV_IRQ_HOST_MSIX |
+ KVM_DEV_IRQ_GUEST_MSIX;
if (kvm_assign_irq(kvm_context, &assigned_irq_data) < 0) {
perror("assigned_dev_enable_msix: assign irq");
return;
@@ -1254,6 +1279,7 @@ static void assigned_device_pci_cap_write_config(PCIDevice *pci_dev, uint32_t ad
{
AssignedDevice *assigned_dev = container_of(pci_dev, AssignedDevice, dev);
unsigned int pos = pci_dev->cap.start, ctrl_pos;
+ uint16_t *ctrl_word;
pci_default_cap_write_config(pci_dev, address, val, len);
#ifdef KVM_CAP_IRQ_ROUTING
@@ -1270,7 +1296,8 @@ static void assigned_device_pci_cap_write_config(PCIDevice *pci_dev, uint32_t ad
ctrl_pos = pos + 3;
if (address <= ctrl_pos && address + len > ctrl_pos) {
ctrl_pos--; /* control is word long */
- assigned_dev_update_msix(pci_dev, ctrl_pos);
+ ctrl_word = (uint16_t *)(pci_dev->config + ctrl_pos);
+ assigned_dev_update_msix(pci_dev, (*ctrl_word & PCI_MSIX_ENABLE));
}
pos += PCI_CAPABILITY_CONFIG_MSIX_LENGTH;
}
--
1.7.0.1
^ permalink raw reply related
* [PATCH 4/5] qemu-kvm: device assignment: emulate MSI-X mask bits
From: Sheng Yang @ 2010-10-20 8:29 UTC (permalink / raw)
To: Avi Kivity, Marcelo Tosatti; +Cc: Michael S. Tsirkin, kvm, Sheng Yang
In-Reply-To: <1287563395-30039-1-git-send-email-sheng@linux.intel.com>
This patch emulated MSI-X per vector mask bit on assigned device.
Signed-off-by: Sheng Yang <sheng@linux.intel.com>
---
hw/device-assignment.c | 151 ++++++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 145 insertions(+), 6 deletions(-)
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index 8a98876..d1a6282 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -62,6 +62,11 @@ static void assigned_dev_load_option_rom(AssignedDevice *dev);
static void assigned_dev_unregister_msix_mmio(AssignedDevice *dev);
+static uint32_t calc_assigned_dev_id(uint16_t seg, uint8_t bus, uint8_t devfn)
+{
+ return (uint32_t)seg << 16 | (uint32_t)bus << 8 | (uint32_t)devfn;
+}
+
static uint32_t assigned_dev_ioport_rw(AssignedDevRegion *dev_region,
uint32_t addr, int len, uint32_t *val)
{
@@ -824,11 +829,6 @@ static void free_assigned_device(AssignedDevice *dev)
}
}
-static uint32_t calc_assigned_dev_id(uint16_t seg, uint8_t bus, uint8_t devfn)
-{
- return (uint32_t)seg << 16 | (uint32_t)bus << 8 | (uint32_t)devfn;
-}
-
static void assign_failed_examine(AssignedDevice *dev)
{
char name[PATH_MAX], dir[PATH_MAX], driver[PATH_MAX] = {}, *ns;
@@ -1123,6 +1123,7 @@ static int get_msix_entries_max_nr(AssignedDevice *adev)
return entries_max_nr;
}
+#define MSIX_VECTOR_MASK 0x1
static int get_msix_valid_entries_nr(AssignedDevice *adev,
uint16_t entries_max_nr)
{
@@ -1136,7 +1137,11 @@ static int get_msix_valid_entries_nr(AssignedDevice *adev,
memcpy(&msg_ctrl, va + i * 16 + 12, 4);
memcpy(&msg_data, va + i * 16 + 8, 4);
/* Ignore unused entry even it's unmasked */
+#ifdef KVM_CAP_DEVICE_MSIX_MASK
+ if (msg_data == 0 || (msg_ctrl & MSIX_VECTOR_MASK))
+#else
if (msg_data == 0)
+#endif
continue;
entries_nr ++;
}
@@ -1165,6 +1170,8 @@ static int assigned_dev_update_msix_mmio(PCIDevice *pci_dev,
}
free_dev_irq_entries(adev);
+ memset(pci_dev->msix_entry_used, 0, KVM_MAX_MSIX_PER_DEV *
+ sizeof(*pci_dev->msix_entry_used));
adev->irq_entries_nr = entries_nr;
adev->entry = calloc(entries_nr, sizeof(struct kvm_irq_routing_entry));
if (!adev->entry) {
@@ -1179,7 +1186,11 @@ static int assigned_dev_update_msix_mmio(PCIDevice *pci_dev,
break;
memcpy(&msg_ctrl, va + i * 16 + 12, 4);
memcpy(&msg_data, va + i * 16 + 8, 4);
+#ifdef KVM_CAP_DEVICE_MSIX_MASK
+ if (msg_data == 0 || (msg_ctrl & MSIX_VECTOR_MASK))
+#else
if (msg_data == 0)
+#endif
continue;
memcpy(&msg_addr, va + i * 16, 4);
@@ -1200,6 +1211,7 @@ static int assigned_dev_update_msix_mmio(PCIDevice *pci_dev,
msix_entry.gsi = adev->entry[entries_nr].gsi;
msix_entry.entry = i;
+ pci_dev->msix_entry_used[i] = 1;
r = kvm_assign_set_msix_entry(kvm_context, &msix_entry);
if (r) {
fprintf(stderr, "fail to set MSI-X entry! %s\n", strerror(-r));
@@ -1243,6 +1255,8 @@ static void assigned_dev_update_msix(PCIDevice *pci_dev, int enable_msix)
perror("assigned_dev_update_msix: deassign irq");
assigned_dev->irq_requested_type = 0;
+ memset(pci_dev->msix_entry_used, 0, KVM_MAX_MSIX_PER_DEV *
+ sizeof(*pci_dev->msix_entry_used));
}
entries_max_nr = get_msix_entries_max_nr(assigned_dev);
@@ -1250,10 +1264,16 @@ static void assigned_dev_update_msix(PCIDevice *pci_dev, int enable_msix)
fprintf(stderr, "assigned_dev_update_msix: MSI-X entries_max_nr == 0");
return;
}
+ /*
+ * Guest may try to enable MSI-X before setting MSI-X entry done, so
+ * let's wait until guest unmask the entries.
+ */
entries_nr = get_msix_valid_entries_nr(assigned_dev, entries_max_nr);
if (entries_nr == 0) {
+#ifndef KVM_CAP_DEVICE_MSIX_MASK
if (enable_msix)
fprintf(stderr, "MSI-X entry number is zero!\n");
+#endif
return;
}
if (enable_msix) {
@@ -1297,7 +1317,8 @@ static void assigned_device_pci_cap_write_config(PCIDevice *pci_dev, uint32_t ad
if (address <= ctrl_pos && address + len > ctrl_pos) {
ctrl_pos--; /* control is word long */
ctrl_word = (uint16_t *)(pci_dev->config + ctrl_pos);
- assigned_dev_update_msix(pci_dev, (*ctrl_word & PCI_MSIX_ENABLE));
+ assigned_dev_update_msix(pci_dev,
+ (*ctrl_word & PCI_MSIX_ENABLE) && !(*ctrl_word & PCI_MSIX_MASK));
}
pos += PCI_CAPABILITY_CONFIG_MSIX_LENGTH;
}
@@ -1389,6 +1410,104 @@ static uint32_t msix_mmio_readw(void *opaque, target_phys_addr_t addr)
(8 * (addr & 3))) & 0xffff;
}
+#ifdef KVM_CAP_DEVICE_MSIX_MASK
+static void msix_mmio_access_mask_bit(AssignedDevice *adev, int index)
+{
+ void *page = adev->msix_table_page;
+ uint32_t msg_ctrl, msg_data, msg_upper_addr, msg_addr;
+ struct kvm_assigned_msix_entry msix_entry;
+ int r = 0, pos, ctrl_word, entry_idx, entries_max_nr;
+ struct kvm_irq_routing_entry new_entry = {};
+
+ memcpy(&msg_addr, (char *)page + index * 16, 4);
+ memcpy(&msg_upper_addr, (char *)page + index * 16 + 4, 4);
+ memcpy(&msg_data, (char *)page + index * 16 + 8, 4);
+ memcpy(&msg_ctrl, (char *)page + index * 16 + 12, 4);
+ DEBUG("Access mask bit: MSI-X entries index %d: "
+ "msg_addr 0x%x, msg_upper_addr 0x%x, msg_data 0x%x, vec_ctl 0x%x\n",
+ index, msg_addr, msg_upper_addr, msg_data, msg_ctrl);
+
+ if (adev->cap.available & ASSIGNED_DEVICE_CAP_MSI)
+ pos = adev->dev.cap.start + PCI_CAPABILITY_CONFIG_MSI_LENGTH;
+ else
+ pos = adev->dev.cap.start;
+
+ ctrl_word = *(uint16_t *)(adev->dev.config + pos + 2);
+
+ if (!((ctrl_word & PCI_MSIX_ENABLE) && !(ctrl_word & PCI_MSIX_MASK)))
+ return;
+
+ if (!adev->dev.msix_entry_used[index]) {
+ if ((msg_ctrl & MSIX_VECTOR_MASK) == 0) {
+ DEBUG("Try to modify unenabled MSI-X entry %d's mask. "
+ "Reenable MSI-X.\n",
+ index);
+ assigned_dev_update_msix(&adev->dev, 1);
+ }
+ return;
+ }
+
+ /* find the correlated index of adev->entry */
+ entries_max_nr = get_msix_entries_max_nr(adev);
+ entry_idx = 0;
+ while (entry_idx < entries_max_nr) {
+ if (adev->dev.msix_entry_used[entry_idx] && entry_idx == index)
+ break;
+ entry_idx ++;
+ }
+ if (entry_idx >= entries_max_nr) {
+ fprintf(stderr, "msix_mmio_access_mask_bit: Entry idx exceed limit!\n");
+ return;
+ }
+
+ msix_entry.assigned_dev_id = calc_assigned_dev_id(adev->h_segnr,
+ adev->h_busnr,
+ (uint8_t)adev->h_devfn);
+ msix_entry.gsi = adev->entry[entry_idx].gsi;
+ msix_entry.entry = index;
+ if (msg_ctrl & MSIX_VECTOR_MASK)
+ msix_entry.flags = KVM_MSIX_FLAG_MASK;
+ else
+ msix_entry.flags = 0;
+ DEBUG("set MSI-X index %d, esi 0x%x, mask %d\n",
+ index, msix_entry.gsi, msix_entry.flags);
+ r = kvm_assign_set_msix_entry(kvm_context, &msix_entry);
+ if (r) {
+ perror("msix_mmio_access_mask_bit: "
+ "fail to set MSI-X entry!");
+ return;
+ }
+
+ if (msix_entry.flags == 0) {
+ new_entry.gsi = adev->entry[entry_idx].gsi;
+ new_entry.type = KVM_IRQ_ROUTING_MSI;
+ new_entry.flags = 0;
+ new_entry.u.msi.address_lo = msg_addr;
+ new_entry.u.msi.address_hi = msg_upper_addr;
+ new_entry.u.msi.data = msg_data;
+ if (memcmp(&adev->entry[entry_idx].u.msi, &new_entry.u.msi,
+ sizeof new_entry.u.msi)) {
+ int r;
+ r = kvm_update_routing_entry(&adev->entry[entry_idx], &new_entry);
+ if (r) {
+ perror("msix_mmio_access_mask_bit: "
+ "kvm_update_routing_entry failed\n");
+ return;
+ }
+ r = kvm_commit_irq_routes();
+ if (r) {
+ perror("msix_mmio_access_mask_bit: "
+ "kvm_commit_irq_routes failed\n");
+ return;
+ }
+ }
+ adev->entry[entry_idx].u.msi.address_lo = msg_addr;
+ adev->entry[entry_idx].u.msi.address_hi = msg_upper_addr;
+ adev->entry[entry_idx].u.msi.data = msg_data;
+ }
+}
+#endif
+
static void msix_mmio_writel(void *opaque,
target_phys_addr_t addr, uint32_t val)
{
@@ -1399,6 +1518,12 @@ static void msix_mmio_writel(void *opaque,
DEBUG("write to MSI-X entry table mmio offset 0x%lx, val 0x%x\n",
addr, val);
memcpy((void *)((char *)page + offset), &val, 4);
+
+#ifdef KVM_CAP_DEVICE_MSIX_MASK
+ /* Check if mask bit is being accessed */
+ if (offset % 16 == 12)
+ msix_mmio_access_mask_bit(adev, offset / 16);
+#endif
}
static void msix_mmio_writew(void *opaque,
@@ -1425,6 +1550,16 @@ static CPUReadMemoryFunc *msix_mmio_read[] = {
static int assigned_dev_register_msix_mmio(AssignedDevice *dev)
{
+#ifdef KVM_CAP_DEVICE_MSIX_MASK
+#ifndef KVM_CAP_DEVICE_MSIX_EXT
+#error
+#endif
+ /* Request for MSI-X masking support */
+ if (kvm_enable_cap(first_cpu, KVM_CAP_DEVICE_MSIX_EXT) != 0) {
+ fprintf(stderr, "fail to enable MSI-X extending support!\n");
+ return -EFAULT;
+ }
+#endif
dev->msix_table_page = mmap(NULL, 0x1000,
PROT_READ|PROT_WRITE,
MAP_ANONYMOUS|MAP_PRIVATE, 0, 0);
@@ -1436,6 +1571,8 @@ static int assigned_dev_register_msix_mmio(AssignedDevice *dev)
memset(dev->msix_table_page, 0, 0x1000);
dev->mmio_index = cpu_register_io_memory(
msix_mmio_read, msix_mmio_write, dev);
+ dev->dev.msix_entry_used = qemu_mallocz(KVM_MAX_MSIX_PER_DEV *
+ sizeof *dev->dev.msix_entry_used);
return 0;
}
@@ -1452,6 +1589,8 @@ static void assigned_dev_unregister_msix_mmio(AssignedDevice *dev)
strerror(errno));
}
dev->msix_table_page = NULL;
+ free(dev->dev.msix_entry_used);
+ dev->dev.msix_entry_used = NULL;
}
static int assigned_initfn(struct PCIDevice *pci_dev)
--
1.7.0.1
^ permalink raw reply related
* [PATCH 5/5] qemu-kvm: device assignment: Enable in-kernel MSI-X mask support
From: Sheng Yang @ 2010-10-20 8:29 UTC (permalink / raw)
To: Avi Kivity, Marcelo Tosatti; +Cc: Michael S. Tsirkin, kvm, Sheng Yang
In-Reply-To: <1287563395-30039-1-git-send-email-sheng@linux.intel.com>
Signed-off-by: Sheng Yang <sheng@linux.intel.com>
---
hw/device-assignment.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index d1a6282..aa3358e 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -269,6 +269,9 @@ static void assigned_dev_iomem_map(PCIDevice *pci_dev, int region_num,
AssignedDevRegion *region = &r_dev->v_addrs[region_num];
PCIRegion *real_region = &r_dev->real_device.regions[region_num];
int ret = 0;
+#ifdef KVM_CAP_DEVICE_MSIX_MASK
+ struct kvm_assigned_msix_mmio msix_mmio;
+#endif
DEBUG("e_phys=%08" FMT_PCIBUS " r_virt=%p type=%d len=%08" FMT_PCIBUS " region_num=%d \n",
e_phys, region->u.r_virtbase, type, e_size, region_num);
@@ -287,6 +290,16 @@ static void assigned_dev_iomem_map(PCIDevice *pci_dev, int region_num,
cpu_register_physical_memory(e_phys + offset,
TARGET_PAGE_SIZE, r_dev->mmio_index);
+#ifdef KVM_CAP_DEVICE_MSIX_MASK
+ memset(&msix_mmio, 0, sizeof(struct kvm_assigned_msix_mmio));
+ msix_mmio.assigned_dev_id = calc_assigned_dev_id(r_dev->h_segnr,
+ r_dev->h_busnr, r_dev->h_devfn);
+ msix_mmio.base_addr = e_phys + offset;
+ if (kvm_assign_reg_msix_mmio(kvm_context, &msix_mmio))
+ fprintf(stderr, "fail to register in-kernel msix_mmio!\n");
+ /* We can still continue because the MMIO accessing can fall
+ * back to QEmu */
+#endif
}
}
--
1.7.0.1
^ permalink raw reply related
* [PATCH 1/5] qemu-kvm: Add kvm_enable_cap() interface for x86
From: Sheng Yang @ 2010-10-20 8:29 UTC (permalink / raw)
To: Avi Kivity, Marcelo Tosatti; +Cc: Michael S. Tsirkin, kvm, Sheng Yang
In-Reply-To: <1287563395-30039-1-git-send-email-sheng@linux.intel.com>
Signed-off-by: Sheng Yang <sheng@linux.intel.com>
---
qemu-kvm.c | 16 ++++++++++++++++
qemu-kvm.h | 8 ++++++++
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/qemu-kvm.c b/qemu-kvm.c
index 733d0a9..fbb68f6 100644
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -540,6 +540,22 @@ int kvm_set_xcrs(CPUState *env, struct kvm_xcrs *xcrs)
}
#endif
+#ifdef KVM_CAP_ENABLE_CAP
+int kvm_enable_cap(CPUState *env, uint32_t cap)
+{
+ int r = 0;
+ struct kvm_enable_cap enable_cap = {
+ .cap = cap,
+ .flags = 0,
+ };
+
+ r = kvm_ioctl(kvm_state, KVM_CHECK_EXTENSION, KVM_CAP_ENABLE_CAP);
+ if (r > 0)
+ r = kvm_vcpu_ioctl(env, KVM_ENABLE_CAP, &enable_cap);
+ return r;
+}
+#endif
+
static int handle_mmio(CPUState *env)
{
unsigned long addr = env->kvm_run->mmio.phys_addr;
diff --git a/qemu-kvm.h b/qemu-kvm.h
index 9c08ab4..5cac0c2 100644
--- a/qemu-kvm.h
+++ b/qemu-kvm.h
@@ -316,6 +316,14 @@ int kvm_get_xcrs(CPUState *env, struct kvm_xcrs *xcrs);
int kvm_set_xcrs(CPUState *env, struct kvm_xcrs *xcrs);
#endif
+#ifdef KVM_ENABLE_CAP
+/*!
+ * * \brief Enable specific capability of KVM
+ *
+ */
+int kvm_enable_cap(CPUState *env, uint32_t cap);
+#endif
+
/*!
* \brief Simulate an external vectored interrupt
*
--
1.7.0.1
^ permalink raw reply related
* [PATCH 0/5] MSI-X mask support for assigned device on userspace
From: Sheng Yang @ 2010-10-20 8:29 UTC (permalink / raw)
To: Avi Kivity, Marcelo Tosatti; +Cc: Michael S. Tsirkin, kvm, Sheng Yang
Sheng Yang (5):
qemu-kvm: Add kvm_enable_cap() interface for x86
qemu-kvm: Ioctl for in-kernel mask support
qemu-kvm: device assignment: Some clean up about MSI-X code
qemu-kvm: device assignment: emulate MSI-X mask bits
qemu-kvm: device assignment: Enable in-kernel MSI-X mask support
hw/device-assignment.c | 239 ++++++++++++++++++++++++++++++++++++++++++------
qemu-kvm.c | 25 +++++
qemu-kvm.h | 12 +++
3 files changed, 246 insertions(+), 30 deletions(-)
^ permalink raw reply
* [U-Boot] [PATCH] ppc4xx: Add Io and IoCon 405EP board support
From: Stefan Roese @ 2010-10-20 8:27 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1287050350-12705-1-git-send-email-eibach@gdsys.de>
Hi Dirk,
On Thursday 14 October 2010 11:59:10 Dirk Eibach wrote:
> Board support for the Guntermann & Drunck CATCenter Io.
> Board support for the Guntermann & Drunck IoCon.
I just tried to apply this patch, but it doesn't work:
[stefan at quad u-boot-ppc4xx (master)]$ git am -3 -s
patches_update-2010-10-20/\[U-Boot\]\ \[PATCH\]\ ppc4xx_Add\ Io\ and\ IoCon\
405EP\ board\ support.mbox
Applying: ppc4xx: Add Io and IoCon 405EP board support
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging MAINTAINERS
Auto-merging MAKEALL
CONFLICT (content): Merge conflict in MAKEALL
Auto-merging boards.cfg
CONFLICT (content): Merge conflict in boards.cfg
Failed to merge in the changes.
I tried to manually resolve these conflicts but stumbled over other problems
with this patch resulting from the latest changes in the MAKEALL rework done
by Wolfgang. You need to remove your config.mk file and add
CONFIG_SYS_TEXT_BASE to your board config headers now.
Please fix (rebase on current u-boot master) and resubmit. Thanks.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de
^ permalink raw reply
* Re: [Qemu-devel] KVM call minutes for Oct 19
From: Paolo Bonzini @ 2010-10-20 8:25 UTC (permalink / raw)
To: Alexander Graf; +Cc: Chris Wright, kvm, qemu-devel
In-Reply-To: <4DE00079-05FA-40DF-9EA5-9573AD745117@suse.de>
On 10/20/2010 10:21 AM, Alexander Graf wrote:
> Would it be realistic to declare deprecating the qemu-kvm fork for
> 0.14 as goal?
I recall some performance problems with the qemu.git iothread, I'm not
sure all of those have been fixed.
Paolo
^ permalink raw reply
* Re: xtables-addons ACCOUNT
From: Maarten Vanraes @ 2010-10-20 8:25 UTC (permalink / raw)
To: netfilter; +Cc: Bob Miller
In-Reply-To: <1287506749.13167.1042.camel@laplaplian>
Op dinsdag 19 oktober 2010 18:45:49 schreef Bob Miller:
> Hi
>
> > where exactly should i use the ACCOUNT module? does that matter?
>
> Assuming you mean in your iptables rule set, yes, it matters, and you
> should put it where you want it to count. Based on my my understanding,
> limited though it is; in theory, for the 0/0 subnet, the mangle
> table/prerouting chain will catch all traffic between you and the ISP
> that has tcp/ip qualities (ie address and netmask). If you are trying
> to count data used to the ISP by computers on a LAN, then placing the
> rule in the filter table/forward chain should count that traffic.
>
> > error message when trying to use it now:
> >
> >
> > ACCOUNT: Table publicnet found, but IP/netmask mismatch. IP/netmask
> > found: 194.0.234.0/255.255.255.0
> > ACCOUNT: Table insert problem. Aborting
>
> Seems your configuration doesn't match your situation? without knowing
> more about your environment and how you configured this box, it is hard
> to say, maybe your interface address is not in 194.0.234.0/24 or
> something?
> Jan's response might seem to indicate this is an issue of the way you
> built this up or a software mismatch of some sort. Given the fun I had
> making this work before it all came out in debian packages with debian
> methods of building it, I would not be one bit surprised if that is the
> case.
this error message is due to a previous publicnet rule, and it can't seem to
find the matching network. even though it is the same one. (i suspect it is due
to network being 194.0.234.0/24 and the matcher is checking
194.0.234.0/255.255.255.0 ). also i suspect there is a another bug when
removing the rule that the matcher can't find the correct one (also due to
different netmask notations?) and thus not everything is removed which means
that i can't reinsert that one.
Well, i looked at the distromap, seen which versions of what packages work
well and put those working ones on this lenny: for instance; this lenny has
pretty much all relevant packages from the squeeze (which is green in that
map)
furthermore, i don't have any problem with the module; it loads fine
> > when trying to remove the rule with iptables:
> >
> >
> > ACCOUNT: Table publicnet not found for destroy
> >
> >
> > "iptaccount -a" does show the nets fine; but the -l publicnet always
> > gives:
> >
> >
> > Showing table: publicnet
> > Run #0 - 0 items found
> > Finished.
>
> If the other two nets are working as expected, I would think that means
> your software is working, but I dont' know why you would have this
> problem on the one net.
no, i am testing manually with iptables and this is after the first entry
(there is only one tname here.
but no amount of traffic is having any effect here.
i mean; where do i get all the results? it always says 0.
Kind regards,
Maarten
^ permalink raw reply
* [PATCH 2/8] irq: Export irq_to_desc() to modules
From: Sheng Yang @ 2010-10-20 8:26 UTC (permalink / raw)
To: Avi Kivity, Marcelo Tosatti
Cc: kvm, Michael S. Tsirkin, Sheng Yang, linux-kernel
In-Reply-To: <1287563192-29685-1-git-send-email-sheng@linux.intel.com>
KVM need to execute mask/unmask directly on MSI/MSI-X devices. The alternative
way of doing this is export mask_msi_irq(), but it lacks of checking if IRQ
type was really MSI.
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Sheng Yang <sheng@linux.intel.com>
---
kernel/irq/handle.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c
index 27e5c69..1ea2a24 100644
--- a/kernel/irq/handle.c
+++ b/kernel/irq/handle.c
@@ -139,6 +139,7 @@ struct irq_desc *irq_to_desc(unsigned int irq)
{
return radix_tree_lookup(&irq_desc_tree, irq);
}
+EXPORT_SYMBOL_GPL(irq_to_desc);
void replace_irq_desc(unsigned int irq, struct irq_desc *desc)
{
@@ -276,6 +277,7 @@ struct irq_desc *irq_to_desc(unsigned int irq)
{
return (irq < NR_IRQS) ? irq_desc + irq : NULL;
}
+EXPORT_SYMBOL_GPL(irq_to_desc);
struct irq_desc *irq_to_desc_alloc_node(unsigned int irq, int node)
{
--
1.7.0.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.