* [PATCH 4/4] Staging: zram: simplify zram_make_request
From: Jerome Marchand @ 2010-12-17 16:04 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Linux Kernel Mailing List, Nitin Gupta
In-Reply-To: <4D0B88E5.4040005@redhat.com>
zram_read() and zram_write() always return zero, so make them return
void to simplify the code.
Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
---
zram_drv.c | 19 ++++++++-----------
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
index 4085958..54577b0 100644
--- a/drivers/staging/zram/zram_drv.c
+++ b/drivers/staging/zram/zram_drv.c
@@ -200,7 +200,7 @@ static void handle_uncompressed_page(struct zram *zram,
flush_dcache_page(page);
}
-static int zram_read(struct zram *zram, struct bio *bio)
+static void zram_read(struct zram *zram, struct bio *bio)
{
int i;
@@ -209,7 +209,7 @@ static int zram_read(struct zram *zram, struct bio *bio)
if (unlikely(!zram->init_done)) {
bio_endio(bio, -ENXIO);
- return 0;
+ return;
}
zram_stat64_inc(zram, &zram->stats.num_reads);
@@ -271,14 +271,13 @@ static int zram_read(struct zram *zram, struct bio *bio)
set_bit(BIO_UPTODATE, &bio->bi_flags);
bio_endio(bio, 0);
- return 0;
+ return;
out:
bio_io_error(bio);
- return 0;
}
-static int zram_write(struct zram *zram, struct bio *bio)
+static void zram_write(struct zram *zram, struct bio *bio)
{
int i, ret;
u32 index;
@@ -402,11 +401,10 @@ memstore:
set_bit(BIO_UPTODATE, &bio->bi_flags);
bio_endio(bio, 0);
- return 0;
+ return;
out:
bio_io_error(bio);
- return 0;
}
/*
@@ -431,7 +429,6 @@ static inline int valid_io_request(struct zram *zram, struct bio *bio)
*/
static int zram_make_request(struct request_queue *queue, struct bio *bio)
{
- int ret = 0;
struct zram *zram = queue->queuedata;
if (unlikely(!zram->init_done)) {
@@ -448,15 +445,15 @@ static int zram_make_request(struct request_queue *queue, struct bio *bio)
switch (bio_data_dir(bio)) {
case READ:
- ret = zram_read(zram, bio);
+ zram_read(zram, bio);
break;
case WRITE:
- ret = zram_write(zram, bio);
+ zram_write(zram, bio);
break;
}
- return ret;
+ return 0;
}
void zram_reset_device(struct zram *zram)
^ permalink raw reply related
* [PATCH] regulator: Clean up logging a bit
From: Mark Brown @ 2010-12-17 16:05 UTC (permalink / raw)
To: Liam Girdwood; +Cc: patches, linux-kernel, Mark Brown
The recent introduction of standard regulator API logging macros means
that all our log messages have at least the function name in them and
logging that the constraints are for the regulator API is probably a
bit much.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
drivers/regulator/core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index ab419f8..911b774 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -739,7 +739,7 @@ static void print_constraints(struct regulator_dev *rdev)
if (constraints->valid_modes_mask & REGULATOR_MODE_STANDBY)
count += sprintf(buf + count, "standby");
- rdev_info(rdev, "regulator: %s\n", buf);
+ rdev_info(rdev, "%s\n", buf);
}
static int machine_constraints_voltage(struct regulator_dev *rdev,
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v3 2/4] genirq: Inform handler about line sharing state
From: Jan Kiszka @ 2010-12-17 16:06 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Jan Kiszka, Avi Kivity, Marcelo Tosatti,
linux-kernel@vger.kernel.org, kvm, Tom Lyon, Alex Williamson,
Michael S. Tsirkin
In-Reply-To: <alpine.LFD.2.00.1012171315260.12146@localhost6.localdomain6>
Am 17.12.2010 16:25, Thomas Gleixner wrote:
> On Fri, 17 Dec 2010, Jan Kiszka wrote:
>
>> Am 17.12.2010 11:41, Thomas Gleixner wrote:
>>> On Fri, 17 Dec 2010, Jan Kiszka wrote:
>>>> Am 17.12.2010 11:23, Thomas Gleixner wrote:
>>>>> OTOH, if we have to disable anyway, then we could simply keep it
>>>>> disabled across the installation of a new handler. That would make the
>>>>> notification business go away, wouldn't it ?
>>>>
>>>> No, the notification is still necessary in case the registered handler
>>>> keeps the line off after returning from both hard and threaded handler.
>>>
>>> And how should that happen? If it is in oneshot mode then the line is
>>> reenabled when the thread handler returns.
>>
>> disable_irq_nosync is called by the handler before returning. And it's
>> the handler's job to revert this, properly synchronizing it internally.
>
> disable_irq_nosync() is really the worst thing to do. That's simply
> not going to work without a lot of fuglyness.
>
> What about the following:
>
> primary_handler(....)
> {
> if (!shared)
> return IRQ_WAKE_THREAD;
>
> spin_lock(dev->irq_lock);
>
> if (from_my_device() || dev->irq_thread_waiting) {
> mask_dev();
> dev->masked = true;
> ret = IRQ_WAKE_THREAD;
> } else
> ret = IRQ_NONE;
>
> spin_unlock(dev->irq_lock);
> return ret;
> }
>
> check_timeout()
> {
> if (dev->irq_active && wait_longer())
> return IRQ_WAKE_THREAD;
> return IRQ_HANDLED;
> }
>
> unmask_dev_if_necessary()
> {
> if (dev->masked && dev->irq_active)
> umask_dev();
> }
>
> threaded_handler(....)
> {
> if (!dev->irq_thread_waiting) {
> spin_lock_irq(dev->irq_lock);
> wake_user = do_magic_stuff_with_the_dev();
> dev->irq_thread_waiting = wake_user;
> spin_unlock(dev->irq_lock);
> if (wake_user)
> wake_up(user);
> }
>
> if (!dev->irq_thread_waiting) {
> spin_lock_irq(dev->irq_lock);
> unmask_dev_if_necessary();
> spin_unlock(dev->irq_lock);
> return IRQ_HANDLED;
> }
>
> /*
> * Wait for user space to complete. Timeout is to
> * avoid starvation of the irq line when
> * something goes wrong
> */
> wait_for_completion_timeout(dev->compl, SENSIBLE_TIMEOUT);
>
> spin_lock_irq(dev->irq_lock);
> if (timedout) {
> mask_dev();
> dev->masked = true;
> /*
> * Leave dev->irq_thread_waiting untouched and let
> * the core code reschedule us when check_timeout
> * decides it's worth to wait. In any case we leave
> * the device masked at the device level, so we don't
> * cause an interrupt storm.
> */
> ret = check_timeout();
> } else {
> unmask_dev_if_necessary();
> dev->irq_thread_waiting = false;
> ret = IRQ_HANDLED;
> }
> spin_unlock(dev->irq_lock);
> return ret;
> }
>
> userspace_complete()
> {
> complete(dev->irq_compl);
> }
>
> Your aproach with disable_irq_nosync() is completely flawed, simply
> because you try to pretend that your interrupt handler is done, while
> it is not done at all. The threaded interrupt handler is done when
> user space completes. Everything else is just hacking around the
> problem and creates all that nasty transitional problems.
disable_irq_nosync is the pattern currently used in KVM, it's nothing
new in fact.
The approach looks interesting but requires separate code for
non-PCI-2.3 devices, i.e. when we have no means to mask at device level.
Further drawbacks - unless I missed something on first glance:
- prevents any future optimizations that would work without IRQ thread
ping-pong (ie. once we allow guest IRQ injection from hardirq context
for selected but typical setups)
- two additional, though light-weight, context switches on each
interrupt completion
- continuous polling if user space decides to leave the interrupt
unhandled (e.g. because the virtual IRQ line is masked)
Maybe the latter can be solved in a nicer way, but I don't think we can
avoid the first two. I'm not saying yet that they are killing this
approach, we just need to asses their relevance.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply
* Re: [PATCH] stemodem: Fix for MT call not working when caller id is hidden.
From: Denis Kenzior @ 2010-12-17 16:09 UTC (permalink / raw)
To: ofono
In-Reply-To: <1292507791-23495-1-git-send-email-maritsofie.henriksen8@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]
Hi Marit,
On 12/16/2010 07:56 AM, Marit Henriksen wrote:
> From: Marit Henriksen <marit.henriksen@stericsson.com>
>
> In *ECAV, the number will not be included if caller id is hidden.
> Set it to an empty string in that case.
> ---
> drivers/stemodem/voicecall.c | 10 +++++++---
> 1 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/stemodem/voicecall.c b/drivers/stemodem/voicecall.c
> index b9d91d2..d900666 100644
> --- a/drivers/stemodem/voicecall.c
> +++ b/drivers/stemodem/voicecall.c
> @@ -442,10 +442,14 @@ static void ecav_notify(GAtResult *result, gpointer user_data)
> if (status == CALL_STATUS_DIALING ||
> status == CALL_STATUS_WAITING ||
> status == CALL_STATUS_INCOMING) {
> + /*
> + * If caller uses hidden id, the number and
> + * number type might not be present. Don't
> + * look for type if number is not present.
> + */
> if (!g_at_result_iter_next_string(&iter, &num))
> - return;
> -
> - if (!g_at_result_iter_next_number(&iter, &num_type))
> + num = "";
> + else if (!g_at_result_iter_next_number(&iter, &num_type))
> return;
One small nitpick, but you're not initializing num_type if the number is
missing. While this probably works out, I'd rather be a bit more
pedantic inside the driver. Can you initialize it to unknown number
type (I think 128 is preferred by 27.007) in this case?
> }
>
I also notice that you're not ever able to report the clip_validity == 1
case (e.g. number withheld). Since oFono does make a distinction
between the various clip_validity types, it would be nice if there was a
way around this limitation.
Regards,
-Denis
^ permalink raw reply
* Re: [PATCH 0/4] cifs: CONFIG_CIFS_EXPERIMENTAL removal (try #2)
From: Suresh Jayaraman @ 2010-12-17 16:11 UTC (permalink / raw)
To: Jeff Layton
Cc: smfrench-Re5JQEeQqe8AvxtiuMwx3w,
linux-cifs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20101217103717.22ce07b1-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
On 12/17/2010 09:07 PM, Jeff Layton wrote:
> On Fri, 17 Dec 2010 20:58:22 +0530
> Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org> wrote:
>
>> On 12/08/2010 08:33 PM, Jeff Layton wrote:
>>> This is the second version of this patchset. The changes since the last
>>> set are:
>>>
>>> 1) The patch to remove "/proc/fs/cifs/Experimental" did not remove the
>>> deregistration of that file, which caused a warning on rmmod.
>>>
>>> 2) The patch to remove "/proc/fs/cifs/Experimental" now adds a new
>>> module parameter so that people relying on it to allow zero-copy
>>> writes with signing have a way to continue using that.
>>>
>>> A modified description of the set follows...
>>>
>>> The CONFIG_CIFS_EXPERIMENTAL KConfig option is the sort of thing that
>>> gives distro packagers nightmares. The things that live under it are
>>> impossible to predict for someone who isn't following development
>>> upstream.
>>
>> In general, I like the overall idea of removing heavily overloaded
>> CIFS_EXPERIMENTAL config option. It's true that it was at times hard to
>> narrow down suspect once this option is enabled.
>>
>> However, the dependency of a few options on EXPERIMENTAL (fscache and
>> acl) is not removed. CIFS_FSCACHE can be marked as not dependent on
>> EXPERIMENTAL. Not sure about CIFS_ACL though.
>>
>> Can you make this patchset or a subsequent patch accomodates this change
>> too?
>>
>
> There's a difference between CONFIG_CIFS_EXPERIMENTAL and
> CONFIG_EXPERIMENTAL. Those options depend on the latter. I'm removing
> the former. I think it's still appropriate to mark these new features
> as EXPERIMENTAL and to leave them dependent on CONFIG_EXPERIMENTAL.
Doh, I missed it. Indeed they are different. Sorry about the noise.
> Note, that I don't necessarily think we must leave these features
> tagged CONFIG_EXPERIMENTAL just that if we want to remove those labels,
> we should do that in the context of a separate discussion...
>
Agreed.
--
Suresh Jayaraman
^ permalink raw reply
* Re: [RFC 1/5] user namespaces: Add a user_namespace as creator/owner of uts_namespace
From: Serge Hallyn @ 2010-12-17 16:12 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Michael Kerrisk, kernel list, LSM, Eric W. Biederman, Kees Cook
In-Reply-To: <AANLkTinPBAPjeEdhn21JN6zVpAKDHR9=3gszj84CyyNx-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Quoting Alexey Dobriyan (adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
> On Fri, Dec 17, 2010 at 5:24 PM, Serge E. Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> wrote:
> > +/*
> > + * userns count is 1 for root user, 1 for init_uts_ns,
> > + * and 1 for... ?
> > + */
> > struct user_namespace init_user_ns = {
> > .kref = {
> > - .refcount = ATOMIC_INIT(2),
> > + .refcount = ATOMIC_INIT(3),
>
> +1 is for init_nsproxy ;-)
Hmm, actually user_namespace isn't in struct nsproxy any more,
since 18b6e0414e42d95183f07d8177e3ff0241abd825.
I think my original thought was that init_user_ns is pinned twice by
root_user - once as creator and once as the root user in it. In
which case it isn't right - the user_ns pins the task which created
it, the creator does not pin the user_ns it creates.
-serge
^ permalink raw reply
* [U-Boot] u-boot hang after we changed the flash chip
From: raymond zhao @ 2010-12-17 16:12 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20101213231138.07733D172D3@gemini.denx.de>
Just FYI.
It is not the hardware problem. I update the u-boot to latest version and
port all the configuration files. It just works. Must be something improved
(or fixed) in the new u-boot version. So I learned the lesson, always use
latest stable u-boot version. :-)
Thanks for the help.
Raymond
On Mon, Dec 13, 2010 at 6:11 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear raymond zhao,
>
> In message <AANLkTik9PHqAAvvE1fpGVMh5EYVBb=LitaxA2dG7Y_SA@mail.gmail.com>
> you wrote:
> >
> > I have a AMCC PowerPC 405EX based board. The u-boot version is U-Boot
> > 1.3.2-RELEASE_11. It works fine until we have to change the NOR-Flash
> chip
>
> There has never been any such release. There was v1.3.2, followed by
> v1.3.3. Note that these are more than 2.5 years old, so I strongly
> recommend to update to current code instead.
>
> > static int init_func_i2c (void)
> > {
> > puts ("I2C: ");
> > i2c_init (CFG_I2C_SPEED, CFG_I2C_SLAVE);
> > puts ("ready\n");
> > return (0);
> > }
> > In debug console: I actually see the out put I2C: . The codes fly away
> > inside i2c_init (CFG_I2C_SPEED, CFG_I2C_SLAVE); and never come back to
> > put("ready\n");
>
> This does not really look like a flash related issue to me.
>
> > Another interesting thing is when I am in function init_func_i2c, I used
> bt
> > full in GDB to check the stack. I get the following:
> > (gdb) bt full
> > #0 <signal handler called>
> > No locals.
> > #1 0x00000000 in ?? ()
> > No symbol table info available.
> > #2 0x00000000 in ?? ()
> > No symbol table info available.
> > Previous frame inner to this frame (corrupt stack?)
>
> Neither does this.
>
> > Does this mean the stack is corrupted? There should have a stack already
> in
> > this moment, right?
> >
> >
> > Does anyone has any idea which direction I should go?
>
> Check your voltages, as close to the flash chips as possible. The new
> ones may draw higher currents (especially higher and steeper peaks).
> If your voltages are not clean you may see data corruption, which
> would explain the effects you describe (and a lot more).
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> On the subject of C program indentation: "In My Egotistical Opinion,
> most people's C programs should be indented six feet downward and
> covered with dirt." - Blair P. Houghton
>
^ permalink raw reply
* Re: [RFC 1/5] user namespaces: Add a user_namespace as creator/owner of uts_namespace
From: Serge Hallyn @ 2010-12-17 16:12 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: Serge E. Hallyn, LSM, James Morris, Kees Cook, containers,
kernel list, Eric W. Biederman, Michael Kerrisk
In-Reply-To: <AANLkTinPBAPjeEdhn21JN6zVpAKDHR9=3gszj84CyyNx@mail.gmail.com>
Quoting Alexey Dobriyan (adobriyan@gmail.com):
> On Fri, Dec 17, 2010 at 5:24 PM, Serge E. Hallyn <serge@hallyn.com> wrote:
> > +/*
> > + * userns count is 1 for root user, 1 for init_uts_ns,
> > + * and 1 for... ?
> > + */
> > struct user_namespace init_user_ns = {
> > .kref = {
> > - .refcount = ATOMIC_INIT(2),
> > + .refcount = ATOMIC_INIT(3),
>
> +1 is for init_nsproxy ;-)
Hmm, actually user_namespace isn't in struct nsproxy any more,
since 18b6e0414e42d95183f07d8177e3ff0241abd825.
I think my original thought was that init_user_ns is pinned twice by
root_user - once as creator and once as the root user in it. In
which case it isn't right - the user_ns pins the task which created
it, the creator does not pin the user_ns it creates.
-serge
^ permalink raw reply
* [U-Boot] [PATCH 2/2] PowerPC, nand_spl: Add relocation support for -fpic
From: Wolfgang Denk @ 2010-12-17 16:13 UTC (permalink / raw)
To: u-boot
In-Reply-To: <OF3301F88E.E61F6369-ONC12577FC.00573EBC-C12577FC.00576AF2@transmode.se>
Dear Joakim Tjernlund,
In message <OF3301F88E.E61F6369-ONC12577FC.00573EBC-C12577FC.00576AF2@transmode.se> you wrote:
>
> > Great! then we got:
> > [PATCH] PowerPC: Move -fPIC flag to common place
> > [PATCH] PowerPC: Add support for -msingle-pic-base
>
> How about the above 2 patches?
I think I have them on my list for "next", but I got other things to
do first.
This will definitely not go into v2010.12.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
... The prejudices people feel about each other disappear when then
get to know each other.
-- Kirk, "Elaan of Troyius", stardate 4372.5
^ permalink raw reply
* Re: Networking issue with "conntracking" after upgrade Xen 3.2 > 4.0
From: Keir Fraser @ 2010-12-17 16:14 UTC (permalink / raw)
To: Olivier Hanesse, xen-devel
In-Reply-To: <AANLkTimdyw=9ZGGBYPUCMNC2QeW4Oc3rA0n7Wx+93mkc@mail.gmail.com>
iptables stuff has been there a while, even in Xen 3.2. The difference is a
new rule that requires conntrack to be loaded and used. I think the best
thing is to remove that requirement and be more permissive about what can be
sent to the domU. After all the domU can run its own firewall if it cares.
I have fixed this as xen-unstable:22573 and xen-4.0-testing:21415.
Thanks,
Keir
On 17/12/2010 15:48, "Olivier Hanesse" <olivier.hanesse@gmail.com> wrote:
> Hi,
>
> I recently upgraded a debian xen 3.2 system to xen 4.
> Then I started to see some strange kernel logs : "nf_conntrack: table full,
> dropping packet."
>
> I was pretty sure not to have enable conntracking in my dom0.
> I find out that it was the revision "19540" of the "vif-common.sh" script that
> load the nf_conntrack module.
>
> So now my dom0 logs every connection my domU are doing. With a few domUs, I am
> reaching the limit of conntrack table very quickly.
> On debian the default "net.netfilter.nf_conntrack_max" is set to "16400".
> I set it to "65536" to temporary resolve my network issue but that's not the
> point.
>
> Is it possible to add an option in the xend-config.sxp configuration files,
> something like (handle_iptable yes/no), if we want to handle iptable or not ?
>
> Moreover, for example on on debian, FORWARD policy is set to ACCEPT by
> default. So adding theses rules are useless BUT they are loading some modules
> which can lead to a network issue :(
>
> Regards
>
> Olivier
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: Re: [xen-unstable test] 4041: regressions - FAIL
From: Ian Jackson @ 2010-12-17 16:14 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel@lists.xensource.com
In-Reply-To: <C9313459.297A6%keir@xen.org>
Keir Fraser writes ("Re: [Xen-devel] Re: [xen-unstable test] 4041: regressions - FAIL"):
> Boots for me, with my own dom0 kernel. Could be a Linux dom0 regression? If
> not, will need to wait for this to be bisected to less than a 100-changeset
> range.
No, it's not a dom0 regression because (a) it's using the same dom0 kernel
as passed last time - specifically, it's using 862ef97190f6b54d35c7 -
and (b) it happens with the XCP 2.6.27 too.
I'm not sure whether we're going to get very clean output from the
bisection attempt given how many other brokennesses there have been in
the tree lately, but I'll take a look and see how the bisector is
doing.
Ian.
^ permalink raw reply
* finance
From: Access finance @ 2010-12-18 8:05 UTC (permalink / raw)
Do you need 100% Finance? Steve Barry,a financial lender and consultant,Access finance,
For Debt Consolidation Loan, Business Loan, Private loan, Home Refinancing Loan etc...
Contact Person: mr steve barry Email:finance225@kkwl.ac.th
^ permalink raw reply
* Re: kdump broken on 2.6.37-rc4
From: Vivek Goyal @ 2010-12-17 16:15 UTC (permalink / raw)
To: Yinghai Lu
Cc: H. Peter Anvin, Eric W. Biederman, Stanislaw Gruszka, Ingo Molnar,
Thomas Gleixner, Maxim Uvarov, linux-kernel, Neil Horman
In-Reply-To: <4D0A9986.4080209@kernel.org>
On Thu, Dec 16, 2010 at 02:58:14PM -0800, Yinghai Lu wrote:
> On 12/16/2010 02:01 PM, Vivek Goyal wrote:
> > On Thu, Dec 16, 2010 at 09:28:49AM -0800, Yinghai Lu wrote:
> >> On 12/16/2010 08:28 AM, H. Peter Anvin wrote:
> >>> On 12/16/2010 06:39 AM, Vivek Goyal wrote:
> >>>> On Wed, Dec 15, 2010 at 08:29:01PM -0800, Yinghai Lu wrote:
> >>>>> please check
> >>>>>
> >>>>> [PATCH] x86, crashkernel, 32bit: only try to get range under 512M
> >>>>>
> >>>>> Steanishlaw report kdump is 32bit is broken.
> >>>>>
> >>>>> in misc.c for decompresser, it will do sanity checking to make sure heap
> >>>>> heap under 512M.
> >>>>
> >>>> Thanks Yinghai. I am wondering why on 32bit heap has to be with-in 512MB.
> >>>> I think you are referring to following check in
> >>>> arch/x86/boot/compressed/misc.c.
> >>>>
> >>>> if (end > ((-__PAGE_OFFSET-(512 <<20)-1) & 0x7fffffff))
> >>>> error("Destination address too large");
> >>>>
> >>>> It was introduced here.
> >>>>
> >>>> commit 968de4f02621db35b8ae5239c8cfc6664fb872d8
> >>>> Author: Eric W. Biederman <ebiederm@xmission.com>
> >>>> Date: Thu Dec 7 02:14:04 2006 +0100
> >>>>
> >>>> [PATCH] i386: Relocatable kernel support
> >>>>
> >>>> Eric,
> >>>>
> >>>> It has been long. By any chance would you remember where does above
> >>>> constraint come from?
> >>>>
> >>>
> >>> It might, in fact, be bogus; specifically a proxy for the fact that we
> >>> need the kernel memory including bss and brk below the lowmem boundary,
> >>> which isn't well-defined.
> >>
> >> the brk is complaining if i change that to
> >>
> >> if (end > ((-__PAGE_OFFSET-(128 <<20)-1) & 0x7fffffff))
> >> error("Destination address too large");
> >>
> >
> > Yinghai,
> >
> > On my system above change works fine and I can boot into second kernel. So
> > it will boil down to knowing what are the exact constraints on heap for
> > decompression and for 32bit can we allow heap upto 896MB or not.
>
> really? what is you CONFIG_PAGE_OFFSET? 0x40000000 or 0xc0000000?
>
I am using CONFIG_PAGE_OFFSET=0xC0000000
Thanks
Vivek
^ permalink raw reply
* Re: [RFC 1/5] user namespaces: Add a user_namespace as creator/owner of uts_namespace
From: Serge Hallyn @ 2010-12-17 16:17 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Michael Kerrisk, kernel list, LSM, Eric W. Biederman, Kees Cook
In-Reply-To: <AANLkTik2ry7zbRMgiwhrXMYfQ4tr07BW0ODCNbKBMWmc-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Quoting Alexey Dobriyan (adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
> On Fri, Dec 17, 2010 at 5:56 PM, Alexey Dobriyan <adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Fri, Dec 17, 2010 at 5:24 PM, Serge E. Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> wrote:
> >> +/*
> >> + * userns count is 1 for root user, 1 for init_uts_ns,
> >> + * and 1 for... ?
> >> + */
> >> struct user_namespace init_user_ns = {
> >> .kref = {
> >> - .refcount = ATOMIC_INIT(2),
> >> + .refcount = ATOMIC_INIT(3),
> >
> > +1 is for init_nsproxy ;-)
>
> Err, no.
>
> +1 is to ensure it's never freed, but since allocator will BUG_ON (?) if fed
> with static object, maybe it's completely bogus.
Right. On the one hand so long as it's high enough it doesn't really matter.
But I think it's worth getting the # exactly right in order to help document
what's going on. So I'll try dropping it back down to 2.
thanks,
-serge
^ permalink raw reply
* Re: [RFC 1/5] user namespaces: Add a user_namespace as creator/owner of uts_namespace
From: Serge Hallyn @ 2010-12-17 16:17 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: Serge E. Hallyn, LSM, James Morris, Kees Cook, containers,
kernel list, Eric W. Biederman, Michael Kerrisk
In-Reply-To: <AANLkTik2ry7zbRMgiwhrXMYfQ4tr07BW0ODCNbKBMWmc@mail.gmail.com>
Quoting Alexey Dobriyan (adobriyan@gmail.com):
> On Fri, Dec 17, 2010 at 5:56 PM, Alexey Dobriyan <adobriyan@gmail.com> wrote:
> > On Fri, Dec 17, 2010 at 5:24 PM, Serge E. Hallyn <serge@hallyn.com> wrote:
> >> +/*
> >> + * userns count is 1 for root user, 1 for init_uts_ns,
> >> + * and 1 for... ?
> >> + */
> >> struct user_namespace init_user_ns = {
> >> .kref = {
> >> - .refcount = ATOMIC_INIT(2),
> >> + .refcount = ATOMIC_INIT(3),
> >
> > +1 is for init_nsproxy ;-)
>
> Err, no.
>
> +1 is to ensure it's never freed, but since allocator will BUG_ON (?) if fed
> with static object, maybe it's completely bogus.
Right. On the one hand so long as it's high enough it doesn't really matter.
But I think it's worth getting the # exactly right in order to help document
what's going on. So I'll try dropping it back down to 2.
thanks,
-serge
^ permalink raw reply
* Reading/writing controls from different classes in a single VIDIOC_[GS]_EXT_CTRLS call
From: Laurent Pinchart @ 2010-12-17 16:17 UTC (permalink / raw)
To: Hans Verkuil; +Cc: linux-media
Hi Hans,
I've recently run into an issue when porting a sensor driver to the control
framework.
A userspace application using that driver using VIDIOC_G_EXT_CTRLS to retrieve
the value of a bunch of controls in a single call. Those controls don't belong
to the same class, and the application started failing.
What's the rationale behind forbidding that ?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: kernel SRCREV and meta series woes re new preempt_rt recipe
From: Darren Hart @ 2010-12-17 16:17 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: poky@yoctoproject.org
In-Reply-To: <AANLkTi=Ydq_ttWB6=P8F9wCx06Q6zWMzCuT4FwvdmWL7@mail.gmail.com>
On 12/17/2010 05:53 AM, Bruce Ashfield wrote:
> On Thu, Dec 16, 2010 at 6:51 PM, Darren Hart<dvhart@linux.intel.com> wrote:
>> Hey Bruce,
>>
>> (lots of logs, explanation all through to the end)
>>
>> I'm running into a couple issues I haven't been able to explain.
>> I'm building from poky-contrib dvhart/rt which I rebased against
>> zedd/kernel today (646be7efc3c2a966607526439e3ad812cb4ae3f8). My
>> local.conf has 'MACHINE?=qemux86-64'.
>
> This repo is missing a paired up kernel repo modification, but it should
> be sane.
>
>>
>> You can see the linux-yocto-rt recipe in my contrib branch mentioned
>> above, but for quick reference, here's the diff from linux-yocto-stable:
>
> one demerit point fine for a non-unified diff ;)
Heh, in this case I thought the simple diff did a better job
highlighting the only significant change was:
LINUX_KERNEL_TYPE = "preempt_rt"
>
>>
>> $ diff linux-yocto-stable_git.bb linux-yocto-rt_stablegit.bb
>> 14a15
>> > LINUX_KERNEL_TYPE = "preempt_rt"
>> 21c22
>> < COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64|atom-pc|routerstationpro|mpc8315e-rdb|beagleboard)"
>> ---
>> > COMPATIBLE_MACHINE = "(qemux86-64)"
>> 32a34
>> > print "LINUX_KERNEL_TYPE_EXTENSION: ", bb.data.getVar("LINUX_KERNEL_TYPE_EXTENSION", d)
>> 37a40,41
>> > #SRCREV_machine_pn-linux-yocto-rt_qemux86-64 = "f49444f06875894389e640bcda6c3f6ceb1f0c3e"
>> > #SRCREV = "f49444f06875894389e640bcda6c3f6ceb1f0c3e"
>>
>> I determined the SRCREV from:
>> $ git log --pretty=oneline origin/common_pc_64-preempt_rt -1
>> f49444f06875894389e640bcda6c3f6ceb1f0c3e Merge branch 'standard' into common_pc_
>>
>
> That should be the right rev.
>
Richard,
Any thoughts on this first error - from here down to Bruce's comment?
>> First, bitbake is complaining about SRCREV while parsing
>> linux-yocto-rt_stablegit.bb:
>>
>> $ bitbake linux-yocto-rt
>> NOTE: Handling BitBake files: | (0236/0803) [29 %]
>> LINUX_KERNEL_TYPE_EXTENSION: preempt-rt # dvhart debug
>> NOTE:<class 'bb.fetch.InvalidSRCREV'>:Please set SRCREV to a valid value while evaluating:
>> ${@bb.fetch.get_srcrev(d)}
>> NOTE:<class 'bb.fetch.InvalidSRCREV'>:Please set SRCREV to a valid value while evaluating:
>> ${LINUX_VERSION}+git${SRCPV}
>> NOTE:<class 'bb.fetch.InvalidSRCREV'>:Please set SRCREV to a valid value while evaluating:
>> ${PN}-${EXTENDPE}${PV}-${PR}
>> NOTE:<class 'bb.fetch.InvalidSRCREV'>:Please set SRCREV to a valid value while evaluating:
>> ${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PF}
>> NOTE:<class 'bb.fetch.InvalidSRCREV'>:Please set SRCREV to a valid value while evaluating:
>> ${WORKDIR}/linux
>> NOTE:<class 'bb.fetch.InvalidSRCREV'>:Please set SRCREV to a valid value while evaluating:
>> cd ${S}
>> if [ -f ${WORKDIR}/defconfig ]; then
>> defconfig=${WORKDIR}/defconfig
>> fi
>>
>> kbranch=${KBRANCH}
>>
>> # simply ensures that a branch of the right name has been created
>> createme ${ARCH} ${kbranch} ${defconfig}
>> if [ $? -ne 0 ]; then
>> echo "ERROR. Could not create ${kbranch}"
>> exit 1
>> fi
>>
>> # updates or generates the target description
>> if [ -n "${KERNEL_FEATURES}" ]; then
>> addon_features="--features ${KERNEL_FEATURES}"
>> fi
>> updateme ${addon_features} ${ARCH} ${WORKDIR}
>> if [ $? -ne 0 ]; then
>> echo "ERROR. Could not update ${kbranch}"
>> exit 1
>> fi
>>
>> # executes and modifies the source tree as required
>> patchme ${kbranch}
>> if [ $? -ne 0 ]; then
>> echo "ERROR. Could not modify ${kbranch}"
>> exit 1
>> fi
>>
>> NOTE: Error expanding variable do_patch
>> ERROR: Please set SRCREV to a valid value while parsing /home/dvhart/data/poky.git/meta/recipes-kernel/linux/linux-yocto-rt_stablegit.bb
>> NOTE: Handling BitBake files: - (0802/0803) [99 %]Command execution failed: Traceback (most recent call last):
>> File "/vol/1/dvhart/poky.git/scripts/..//bitbake/lib/bb/command.py", line 85, in runAsyncCommand
>> self.cooker.updateCache()
>> File "/vol/1/dvhart/poky.git/scripts/..//bitbake/lib/bb/cooker.py", line 804, in updateCache
>> if not self.parser.parse_next():
>> File "/vol/1/dvhart/poky.git/scripts/..//bitbake/lib/bb/cooker.py", line 1036, in parse_next
>> raise ParsingErrorsFound
>> ParsingErrorsFound
>>
>
>> I have added a SRC_REV in poky-default-revisions:
>> +# preempt_rt SRCREVs
>> +SRCREV_machine_pn-linux-yocto-rt_qemux86-64 ?= "f49444f06875894389e640bcda6c3f6ceb1f0c3e"
>
> I've seen this man times, and typically it has always had to do with
> processing order of the files related to the fetcher. I'm hoping
> Richard reads this and can jump in with more details, since this is
> something internal to BB and not something I've had the pleasure
> of adding or digging into very much.
>
>>
>>
>> If I add the following to linux-yocto-rt_stablegit.bb:
>> SRCREV = "f49444f06875894389e640bcda6c3f6ceb1f0c3e"
>
> This hits it with a hammer .. yes. Because you set this, we aren't
> counting on the machine specific override of SRCREV to set the
> variable. So this ensures that the variable has *something*, just
> not something that the fetcher will use properly.
But will it send the proper information to the kernel tools? I
understand something needs to get fixed in bitbake or the linux-yocto
recipe components, but does this short-cut that to allow us to examine
the kernel-tools issues?
>>
>>
>> I get passed the parse error, but do_patch fails:
>>
>> Unstaged changes after reset:
>> M .gitignore
>> M Documentation/DocBook/kgdb.tmpl
<snip>
>> Aborting
>> warning: could not find ktypes/temp.scc
>> ./0-wrs_meta-temp-33ebe31bfbabe8a7793524c85ea65707.sco: line 14: temp_68b329da9893e34099c7d8ad5cb9c940: command not found
>> ERROR. Could not locate meta series for common_pc_64-preempt_rt
>> ERROR: Task failed: ('function do_patch failed', '/vol/1/dvhart/poky.git/build/tmp/work/qemux86-64-poky-linux/linux-yocto-rt-2.6.34+git1+f49444f06875894389e640bcda6c3f6ceb1f0c3e_2+f49444f06875894389e640bcda6c3f6ceb1f0c3e-r0/temp/log.do_patch.30710')
>
>
> This means you built a random temporary board and when the branch
> validation steps kicked in, they declared that patches were not present,
> and tried to re-push changes (which were really there) and hence caused
> your failure.
>
> It implies that your tools weren't up to date to me. Since I made changes
> to allow it to locate the proper meta series adapting for the _ vs -
> in the name.
I thought we left the _ in the kernel repository and only munged it to -
in the bitbake string. The log mentions "common_pc_64-preempt_rt" which
I took to mean it was looking for the right thing. Is this not the case?
>
> I'll check the SRCREV I pushed for the tools and see if it is out of date.
>
>>
>>
>> I look at look at the linux directory:
>> $ cd tmp/work/qemux86-64-poky-linux/linux-yocto-rt-2.6.34+git1+f49444f06875894389e640bcda6c3f6ceb1f0c3e_2+f49444f06875894389e640bcda6c3f6ceb1f0c3e-r0/linux/
>> $ git branch
>> arm_versatile_926ejs-standard
>> atom-pc-standard
>> beagleboard-standard
>> blacksand-standard
>> common_pc-preempt_rt
>> common_pc-standard
>> common_pc_64-preempt_rt
>> common_pc_64-standard
>> crownbay-standard
>> davinci-consolidated-2.6.34-merge
>> emenlow-standard
>> fsl-mpc8315e-rdb-standard
>> kgdb-2.6.34-base-merge
>> master
>> mti_malta32_be-standard
>> mti_malta32_le-standard
>> omap-base-merge
>> preempt_rt
>> qemu_ppc32-standard
>> routerstationpro-standard
>> rt-2.6.34-base-merge
>> standard
>> wrs_base
>> wrs_meta
>> wrs_meta-orig
>> * wrs_meta-temp
>>
>> This suggests to me that I'm not hitting the previous
>> no-local-branches-after-clone issues, and that "common_pc-preempt_rt"
>> does indeed exist. A quick review of the linux-2.6-wrs.git wrs_meta
>> branch wrs directory suggests all the preempt-rt meta data exists and
>> matches the expected naming.
>>
>> $ find wrs -name "*preempt_rt*"
>> wrs/cfg/kernel-cache/bsp/common_pc/common_pc-preempt_rt.scc
>> wrs/cfg/kernel-cache/bsp/common_pc_64/common_pc_64-preempt_rt.scc
>> wrs/cfg/kernel-cache/ktypes/preempt_rt
>> wrs/cfg/kernel-cache/ktypes/preempt_rt/preempt_rt.cfg
>> wrs/cfg/kernel-cache/ktypes/preempt_rt/preempt_rt.scc
>> wrs/cfg/meta/common_pc-preempt_rt-meta
>> wrs/cfg/meta/common_pc_64-preempt_rt-meta
>> wrs/patches/common_pc_64-preempt_rt
>> wrs/patches/preempt_rt
>> wrs/patches/common_pc-preempt_rt
>>
>>
>> Any thoughts on what might be going wrong?
>
> Just the tools :) Since I just built the same thing here and it worked. I'll
> grab your recipe and have a look at the SRCREV and hopefully send a
> consolidated series ASAP.
dvhart@doubt:wr-kernel-tools.git$ git log --pretty=oneline -1
796d7fef92b2eed449c17c14441587ff0c465368 configme: check alternate
meta-series
$ grep kern-tools
../../../meta/conf/distro/include/poky-default-revisions.inc
SRCREV_pn-kern-tools-native ??= "796d7fef92b2eed449c17c14441587ff0c465368"
They appear to be in agreement, and that SRCREV is for the META_ALT
patch - but it wasn't obvious to me if that was the one to account for
-_ mangling.
--
Darren Hart
Yocto Linux Kernel
^ permalink raw reply
* Re: [PATCH] Enable pci=bfsort by default on future Dell systems
From: Narendra_K @ 2010-12-17 16:17 UTC (permalink / raw)
To: linux-kernel, linux-pci; +Cc: Matt_Domsch, Jordan_Hargrave, Charles_Rose
In-Reply-To: <20101214175048.GC31345@fedora-14-r710.oslab.blr.amer.dell.com>
On Tue, Dec 14, 2010 at 11:21:19PM +0530, K, Narendra wrote:
> Hello,
>
> This patch enables pci=bfsort by default on future Dell systems.
> Please consider for inclusion if acceptable.
>
> From: Jordan Hargrave <jordan_hargrave@dell.com>
> Subject: [PATCH] Enable pci=bfsort by default on future Dell systems
>
> This patch enables pci=bfsort by default on future Dell systems.
> It reads SMBIOS type 0xB1 vendor specific record and sets pci=bfsort accordingly.
>
> Offset Name Length Value Description
>
> 04 Flags0 Word Varies Bits 9-10
> - 10:9 = 00 Unknown
> - 10:9 = 01 Breadth First
> - 10:9 = 10 Depth First
> - 10:9 = 11 Reserved
>
> 1. Any time pci=bfsort has to be enabled on a system, we need to add the model
> number of the system to the white list. With this patch, that is not required.
>
> 2. Typically, model number has to be added to the white list when the system is
> under development. With this change, that is not required.
>
> Signed-off-by: Jordan Hargrave <jordan_hargrave@dell.com>
> Signed-off-by: Narendra K <narendra_k@dell.com>
> ---
Hello Jesse,
Please let us know if there are any concerns with this patch. If the
patch is acceptable, please consider it for inclusion.
With regards,
Narendra K
^ permalink raw reply
* Re: [PATCH 11/21] ioport: insert event_tap_ioport() to ioport_write().
From: Yoshiaki Tamura @ 2010-12-17 16:19 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: Michael S. Tsirkin, kvm, qemu-devel, avi, anthony, aliguori,
mtosatti, dlaor, ananth, psuriset, vatsa, stefanha, ohmura.kei
In-Reply-To: <AANLkTinrZCa9zyrp=PVoAp_H-tUH=CNpcbu5vnjQP+oF@mail.gmail.com>
2010/12/17 Stefan Hajnoczi <stefanha@gmail.com>:
> On Thu, Dec 16, 2010 at 9:50 AM, Yoshiaki Tamura
> <tamura.yoshiaki@lab.ntt.co.jp> wrote:
>> 2010/12/16 Michael S. Tsirkin <mst@redhat.com>:
>>> On Thu, Dec 16, 2010 at 04:37:41PM +0900, Yoshiaki Tamura wrote:
>>>> 2010/11/28 Yoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>:
>>>> > 2010/11/28 Michael S. Tsirkin <mst@redhat.com>:
>>>> >> On Thu, Nov 25, 2010 at 03:06:50PM +0900, Yoshiaki Tamura wrote:
>>>> >>> Record ioport event to replay it upon failover.
>>>> >>>
>>>> >>> Signed-off-by: Yoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>
>>>> >>
>>>> >> Interesting. This will have to be extended to support ioeventfd.
>>>> >> Since each eventfd is really just a binary trigger
>>>> >> it should be enough to read out the fd state.
>>>> >
>>>> > Haven't thought about eventfd yet. Will try doing it in the next
>>>> > spin.
>>>>
>>>> Hi Michael,
>>>>
>>>> I looked into eventfd and realized it's only used with vhost now.
>>>
>>> There are patches on list to use it for block/userspace net.
>>
>> Thanks. Now I understand.
>> In that case, inserting an even-tap function to the following code
>> should be appropriate?
>>
>> int event_notifier_test_and_clear(EventNotifier *e)
>> {
>> uint64_t value;
>> int r = read(e->fd, &value, sizeof(value));
>> return r == sizeof(value);
>> }
>>
>>>
>>>> However, I
>>>> believe vhost bypass the net layer in qemu, and there is no way for Kemari to
>>>> detect the outputs. To me, it doesn't make sense to extend this patch to
>>>> support eventfd...
>
> Here is the userspace ioeventfd patch series:
> http://www.mail-archive.com/qemu-devel@nongnu.org/msg49208.html
>
> Instead of switching to QEMU userspace to handle the virtqueue kick
> pio write, we signal the eventfd inside the kernel and resume guest
> code execution. The I/O thread can then process the virtqueue kick in
> parallel to guest code execution.
>
> I think this can still be tied into Kemari. If you are switching to a
> pure net/block-layer event tap instead of pio/mmio, then I think it
> should just work.
That should take a while until we solve how to set correct
callbacks to the secondary upon failover. BTW, do you have a
plan to move the eventfd framework to the upper layer as
pio/mmio. Not only Kemari works for free, other emulators should
be able to benefit from it.
> For vhost it would be more difficult to integrate with Kemari.
At this point, it's impossible. As Michael said, I should
prevent starting Kemari when vhost=on.
Yoshi
>
> Stefan
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [Qemu-devel] Re: [PATCH 11/21] ioport: insert event_tap_ioport() to ioport_write().
From: Yoshiaki Tamura @ 2010-12-17 16:19 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: aliguori, dlaor, ananth, kvm, Michael S. Tsirkin, mtosatti,
qemu-devel, vatsa, ohmura.kei, avi, psuriset, stefanha
In-Reply-To: <AANLkTinrZCa9zyrp=PVoAp_H-tUH=CNpcbu5vnjQP+oF@mail.gmail.com>
2010/12/17 Stefan Hajnoczi <stefanha@gmail.com>:
> On Thu, Dec 16, 2010 at 9:50 AM, Yoshiaki Tamura
> <tamura.yoshiaki@lab.ntt.co.jp> wrote:
>> 2010/12/16 Michael S. Tsirkin <mst@redhat.com>:
>>> On Thu, Dec 16, 2010 at 04:37:41PM +0900, Yoshiaki Tamura wrote:
>>>> 2010/11/28 Yoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>:
>>>> > 2010/11/28 Michael S. Tsirkin <mst@redhat.com>:
>>>> >> On Thu, Nov 25, 2010 at 03:06:50PM +0900, Yoshiaki Tamura wrote:
>>>> >>> Record ioport event to replay it upon failover.
>>>> >>>
>>>> >>> Signed-off-by: Yoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>
>>>> >>
>>>> >> Interesting. This will have to be extended to support ioeventfd.
>>>> >> Since each eventfd is really just a binary trigger
>>>> >> it should be enough to read out the fd state.
>>>> >
>>>> > Haven't thought about eventfd yet. Will try doing it in the next
>>>> > spin.
>>>>
>>>> Hi Michael,
>>>>
>>>> I looked into eventfd and realized it's only used with vhost now.
>>>
>>> There are patches on list to use it for block/userspace net.
>>
>> Thanks. Now I understand.
>> In that case, inserting an even-tap function to the following code
>> should be appropriate?
>>
>> int event_notifier_test_and_clear(EventNotifier *e)
>> {
>> uint64_t value;
>> int r = read(e->fd, &value, sizeof(value));
>> return r == sizeof(value);
>> }
>>
>>>
>>>> However, I
>>>> believe vhost bypass the net layer in qemu, and there is no way for Kemari to
>>>> detect the outputs. To me, it doesn't make sense to extend this patch to
>>>> support eventfd...
>
> Here is the userspace ioeventfd patch series:
> http://www.mail-archive.com/qemu-devel@nongnu.org/msg49208.html
>
> Instead of switching to QEMU userspace to handle the virtqueue kick
> pio write, we signal the eventfd inside the kernel and resume guest
> code execution. The I/O thread can then process the virtqueue kick in
> parallel to guest code execution.
>
> I think this can still be tied into Kemari. If you are switching to a
> pure net/block-layer event tap instead of pio/mmio, then I think it
> should just work.
That should take a while until we solve how to set correct
callbacks to the secondary upon failover. BTW, do you have a
plan to move the eventfd framework to the upper layer as
pio/mmio. Not only Kemari works for free, other emulators should
be able to benefit from it.
> For vhost it would be more difficult to integrate with Kemari.
At this point, it's impossible. As Michael said, I should
prevent starting Kemari when vhost=on.
Yoshi
>
> Stefan
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH V2] softfloat: Rename float*_is_nan() functions to float*_is_quiet_nan()
From: Andreas Färber @ 2010-12-17 16:19 UTC (permalink / raw)
To: Peter Maydell; +Cc: Edgar E. Iglesias, qemu-devel, Nathan Froyd
In-Reply-To: <1292601366-990-1-git-send-email-peter.maydell@linaro.org>
Hello Peter,
Am 17.12.2010 um 16:56 schrieb Peter Maydell:
> The softfloat functions float*_is_nan() were badly misnamed,
> because they return true only for quiet NaNs, not for all NaNs.
> Rename them to float*_is_quiet_nan() to more accurately reflect
> what they do.
>
> This change was produced by:
> perl -p -i -e 's/_is_nan/_is_quiet_nan/g' $(git grep -l is_nan)
> (with the results manually checked.)
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> Reviewed-by: Nathan Froyd <froydnj@codesourcery.com>
> Acked-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
> ---
> This is just a refresh of the first patch against current master;
> the only difference is that the addition of
> float32_maybe_silence_nan()
> meant that the context for the hunk in softfloat.h changing the
> prototypes is slightly different. I've therefore retained the
> reviewed-by/acked-by lines from the first time around.
>
> Can this patch be applied? (There are more ARM/softfloat patches
> in my queue which will break it again otherwise...)
If we're engaging into refactoring the softfloat library, I still have
a large'ish patch lying around to fix signature mismatches between
header and sources wrt to integer arguments and migrating to POSIX
integer types (BeOS/Haiku system headers define int32 etc.
differently). Browsing through your patch it shouldn't conflict, but I
guess it'll be best to have it go through your queue to avoid troubles.
Regards,
Andreas
^ permalink raw reply
* Re: [PATCH] netfilter: ebt_ip6: allow matching on ipv6-icmp types/codes
From: Florian Westphal @ 2010-12-17 16:21 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Florian Westphal, netfilter-devel
In-Reply-To: <alpine.LNX.2.01.1012171654410.29660@obet.zrqbmnf.qr>
Jan Engelhardt <jengelh@medozas.de> wrote:
> On Friday 2010-12-17 16:27, Florian Westphal wrote:
> >
> >+++ ebt_ip6.c
> > if (info->bitmask & EBT_IP6_DPORT) {
> >- u32 dst = ntohs(pptr->dst);
> >+ u32 dst = ntohs(pptr->tcpudphdr.dst);
>
> The actual field however is smaller, so to me, this looks itching
> to be changed to
> uint16_t dst = ntohs(pptr->tcpudphdr.dst);
Indeed.
> >@@ -103,6 +115,14 @@ static int ebt_ip6_mt_check(const struct xt_mtchk_param *par)
> > return -EINVAL;
> > if (info->bitmask & EBT_IP6_SPORT && info->sport[0] > info->sport[1])
> > return -EINVAL;
> >+ if (info->bitmask & EBT_IP6_ICMP6) {
> >+ if ((info->invflags & EBT_IP6_PROTO ||
> >+ info->protocol != IPPROTO_ICMPV6))
> >+ return -EINVAL;
>
> Your parenthesis are a little out of balance, it's the & and | that
> are commonly guarded. That probably should have been:
>
> if ((info->invflags & EBT_IP6_PROTO) ||
> info->protocol != IPPROTO_ICMPV6)
Right.
> /* check other places too */
You are right,
If (foo & bar && baz)
is used in other places as well.
But I would prefer to keep cleanups and functional changes separated.
I will make the u16 and the () changes, however I'll wait a couple of
hours to give others time to speak up.
Thanks for reviewing.
Florian
^ permalink raw reply
* oFono release plan?
From: Sjur BRENDELAND @ 2010-12-17 16:21 UTC (permalink / raw)
To: ofono
[-- Attachment #1: Type: text/plain, Size: 134 bytes --]
Hi Denis and Marcel.
Do you have a release plan defined for oFono?
When will you release oFono 1.0?
Thanks,
Regards
Sjur
^ permalink raw reply
* Re: [ANNOUNCE] TCM/LIO v4.0.0-rc6 for 2.6.37-rc6
From: James Bottomley @ 2010-12-17 16:21 UTC (permalink / raw)
To: Vladislav Bolkhovitin
Cc: Nicholas A. Bellinger, linux-scsi, LKML, Christoph Hellwig,
Patil, Kiran, Mike Christie, FUJITA Tomonori, Hannes Reinecke,
Boaz Harrosh, Joe Eykholt, J.H., H. Peter Anvin, Linus Torvalds
In-Reply-To: <4D0B8975.1040206@vlnb.net>
On Fri, 2010-12-17 at 19:01 +0300, Vladislav Bolkhovitin wrote:
> James Bottomley, on 12/17/2010 06:22 PM wrote:
> > OK, I think this has reached the stage where it's been polished enough
> > outside mainline to the point where we can complete any remaining todo
> > items in-tree.
> >
> > So lets begin merging with the minimal target core and the TCM_Loop as
> > two separate commits. I think the target core may just fit under the
> > reflector mail length limits, but if not, you can send it as multiple
> > patches and I'll recombine them.
>
> Well, could somebody eventually explain what are advantages of LIO over
> SCST so you are choosing it?
>
> LIO is obviously worse all technically (see
> http://scst.sourceforge.net/comparison.html) as well as in the number of
> users and size of the community. Current in-rush attempts to make LIO
> _look_ not worse than SCST changed nothing in this area.
To be honest, I don't really give a toss about niche feature
comparisons: both products have niche features the other doesn't. The
basic requirements in both products are solid. If the niche feature has
customer value, my estimation is that it can easily be added (to either
product).
> In the resent threads how many people voted for LIO? Nobody. How many
> for SCST? Many. Moreover, has any real user of LIO participated in those
> threads? None?
This isn't a democracy ... it's about choosing the most community
oriented code base so that it's easily maintainable and easy to add
feature requests and improvements as and when they come along. In the
past six months, LIO has made genuine efforts to clean up its act,
streamline its code and support the other community projects that would
need to go above and around it. You seem to have spent a lot of the
intervening time arguing with the sysfs maintainer about why you're
right and he's wrong.
James
> Doesn't that matter for you? Which code is the best doesn't matter for
> Linux anymore?
>
> Undercover games are going on?
>
> Vlad
^ permalink raw reply
* Re: [PATCH 05/21] virtio: modify save/load handler to handle inuse varialble.
From: Yoshiaki Tamura @ 2010-12-17 16:22 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Marcelo Tosatti, kvm, qemu-devel, avi, anthony, aliguori, dlaor,
ananth, psuriset, vatsa, stefanha, ohmura.kei
In-Reply-To: <AANLkTikspsLyUeTHQ3b0nyo=bXkFqhxYn_LBqwzNLNC7@mail.gmail.com>
2010/12/17 Yoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>:
> 2010/12/16 Michael S. Tsirkin <mst@redhat.com>:
>> On Thu, Dec 16, 2010 at 11:28:46PM +0900, Yoshiaki Tamura wrote:
>>> 2010/12/16 Michael S. Tsirkin <mst@redhat.com>:
>>> > On Thu, Dec 16, 2010 at 04:36:16PM +0900, Yoshiaki Tamura wrote:
>>> >> 2010/12/3 Yoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>:
>>> >> > 2010/12/2 Michael S. Tsirkin <mst@redhat.com>:
>>> >> >> On Wed, Dec 01, 2010 at 05:03:43PM +0900, Yoshiaki Tamura wrote:
>>> >> >>> 2010/11/28 Michael S. Tsirkin <mst@redhat.com>:
>>> >> >>> > On Sun, Nov 28, 2010 at 08:27:58PM +0900, Yoshiaki Tamura wrote:
>>> >> >>> >> 2010/11/28 Michael S. Tsirkin <mst@redhat.com>:
>>> >> >>> >> > On Thu, Nov 25, 2010 at 03:06:44PM +0900, Yoshiaki Tamura wrote:
>>> >> >>> >> >> Modify inuse type to uint16_t, let save/load to handle, and revert
>>> >> >>> >> >> last_avail_idx with inuse if there are outstanding emulation.
>>> >> >>> >> >>
>>> >> >>> >> >> Signed-off-by: Yoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>
>>> >> >>> >> >
>>> >> >>> >> > This changes migration format, so it will break compatibility with
>>> >> >>> >> > existing drivers. More generally, I think migrating internal
>>> >> >>> >> > state that is not guest visible is always a mistake
>>> >> >>> >> > as it ties migration format to an internal implementation
>>> >> >>> >> > (yes, I know we do this sometimes, but we should at least
>>> >> >>> >> > try not to add such cases). I think the right thing to do in this case
>>> >> >>> >> > is to flush outstanding
>>> >> >>> >> > work when vm is stopped. Then, we are guaranteed that inuse is 0.
>>> >> >>> >> > I sent patches that do this for virtio net and block.
>>> >> >>> >>
>>> >> >>> >> Could you give me the link of your patches? I'd like to test
>>> >> >>> >> whether they work with Kemari upon failover. If they do, I'm
>>> >> >>> >> happy to drop this patch.
>>> >> >>> >>
>>> >> >>> >> Yoshi
>>> >> >>> >
>>> >> >>> > Look for this:
>>> >> >>> > stable migration image on a stopped vm
>>> >> >>> > sent on:
>>> >> >>> > Wed, 24 Nov 2010 17:52:49 +0200
>>> >> >>>
>>> >> >>> Thanks for the info.
>>> >> >>>
>>> >> >>> However, The patch series above didn't solve the issue. In
>>> >> >>> case of Kemari, inuse is mostly > 0 because it queues the
>>> >> >>> output, and while last_avail_idx gets incremented
>>> >> >>> immediately, not sending inuse makes the state inconsistent
>>> >> >>> between Primary and Secondary.
>>> >> >>
>>> >> >> Hmm. Can we simply avoid incrementing last_avail_idx?
>>> >> >
>>> >> > I think we can calculate or prepare an internal last_avail_idx,
>>> >> > and update the external when inuse is decremented. I'll try
>>> >> > whether it work w/ w/o Kemari.
>>> >>
>>> >> Hi Michael,
>>> >>
>>> >> Could you please take a look at the following patch?
>>> >
>>> > Which version is this against?
>>>
>>> Oops. It should be very old.
>>> 67f895bfe69f323b427b284430b6219c8a62e8d4
>>>
>>> >> commit 36ee7910059e6b236fe9467a609f5b4aed866912
>>> >> Author: Yoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>
>>> >> Date: Thu Dec 16 14:50:54 2010 +0900
>>> >>
>>> >> virtio: update last_avail_idx when inuse is decreased.
>>> >>
>>> >> Signed-off-by: Yoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>
>>> >
>>> > It would be better to have a commit description explaining why a change
>>> > is made, and why it is correct, not just repeating what can be seen from
>>> > the diff anyway.
>>>
>>> Sorry for being lazy here.
>>>
>>> >> diff --git a/hw/virtio.c b/hw/virtio.c
>>> >> index c8a0fc6..6688c02 100644
>>> >> --- a/hw/virtio.c
>>> >> +++ b/hw/virtio.c
>>> >> @@ -237,6 +237,7 @@ void virtqueue_flush(VirtQueue *vq, unsigned int count)
>>> >> wmb();
>>> >> trace_virtqueue_flush(vq, count);
>>> >> vring_used_idx_increment(vq, count);
>>> >> + vq->last_avail_idx += count;
>>> >> vq->inuse -= count;
>>> >> }
>>> >>
>>> >> @@ -385,7 +386,7 @@ int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
>>> >> unsigned int i, head, max;
>>> >> target_phys_addr_t desc_pa = vq->vring.desc;
>>> >>
>>> >> - if (!virtqueue_num_heads(vq, vq->last_avail_idx))
>>> >> + if (!virtqueue_num_heads(vq, vq->last_avail_idx + vq->inuse))
>>> >> return 0;
>>> >>
>>> >> /* When we start there are none of either input nor output. */
>>> >> @@ -393,7 +394,7 @@ int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
>>> >>
>>> >> max = vq->vring.num;
>>> >>
>>> >> - i = head = virtqueue_get_head(vq, vq->last_avail_idx++);
>>> >> + i = head = virtqueue_get_head(vq, vq->last_avail_idx + vq->inuse);
>>> >>
>>> >> if (vring_desc_flags(desc_pa, i) & VRING_DESC_F_INDIRECT) {
>>> >> if (vring_desc_len(desc_pa, i) % sizeof(VRingDesc)) {
>>> >>
>>> >
>>> > Hmm, will virtio_queue_empty be wrong now? What about virtqueue_avail_bytes?
>>>
>>> I think there are two problems.
>>>
>>> 1. When to update last_avail_idx.
>>> 2. The ordering issue you're mentioning below.
>>>
>>> The patch above is only trying to address 1 because last time you
>>> mentioned that modifying last_avail_idx upon save may break the
>>> guest, which I agree. If virtio_queue_empty and
>>> virtqueue_avail_bytes are only used internally, meaning invisible
>>> to the guest, I guess the approach above can be applied too.
>>
>> So IMHO 2 is the real issue. This is what was problematic
>> with the save patch, otherwise of course changes in save
>> are better than changes all over the codebase.
>
> All right. Then let's focus on 2 first.
>
>>> > Previous patch version sure looked simpler, and this seems functionally
>>> > equivalent, so my question still stands: here it is rephrased in a
>>> > different way:
>>> >
>>> > assume that we have in avail ring 2 requests at start of ring: A and B in this order
>>> >
>>> > host pops A, then B, then completes B and flushes
>>> >
>>> > now with this patch last_avail_idx will be 1, and then
>>> > remote will get it, it will execute B again. As a result
>>> > B will complete twice, and apparently A will never complete.
>>> >
>>> >
>>> > This is what I was saying below: assuming that there are
>>> > outstanding requests when we migrate, there is no way
>>> > a single index can be enough to figure out which requests
>>> > need to be handled and which are in flight already.
>>> >
>>> > We must add some kind of bitmask to tell us which is which.
>>>
>>> I should understand why this inversion can happen before solving
>>> the issue.
>>
>> It's a fundamental thing in virtio.
>> I think it is currently only likely to happen with block, I think tap
>> currently completes things in order. In any case relying on this in the
>> frontend is a mistake.
>>
>>> Currently, how are you making virio-net to flush
>>> every requests for live migration? Is it qemu_aio_flush()?
>>
>> Think so.
>
> If qemu_aio_flush() is responsible for flushing the outstanding
> virtio-net requests, I'm wondering why it's a problem for Kemari.
> As I described in the previous message, Kemari queues the
> requests first. So in you example above, it should start with
>
> virtio-net: last_avai_idx 0 inuse 2
> event-tap: {A,B}
>
> As you know, the requests are still in order still because net
> layer initiates in order. Not about completing.
>
> In the first synchronization, the status above is transferred. In
> the next synchronization, the status will be as following.
>
> virtio-net: last_avai_idx 1 inuse 1
> event-tap: {B}
>
> Why? Because Kemari flushes the first virtio-net request using
> qemu_aio_flush() before each synchronization. If
> qemu_aio_flush() doesn't guarantee the order, what you pointed
> should be problematic. So in the final synchronization, the
> state should be,
>
> virtio-net: last_avai_idx 2 inuse 0
> event-tap: {}
>
> where A,B were completed in order.
>
> Yoshi
Hi Michael,
Please let me know if the discussion has gone wrong or my
explanation was incorrect. I believe live migration shouldn't be
a problem either because it would flush until inuse gets 0.
Yoshi
>
>
>>
>>> >
>>> >> >
>>> >> >>
>>> >> >>> I'm wondering why
>>> >> >>> last_avail_idx is OK to send but not inuse.
>>> >> >>
>>> >> >> last_avail_idx is at some level a mistake, it exposes part of
>>> >> >> our internal implementation, but it does *also* express
>>> >> >> a guest observable state.
>>> >> >>
>>> >> >> Here's the problem that it solves: just looking at the rings in virtio
>>> >> >> there is no way to detect that a specific request has already been
>>> >> >> completed. And the protocol forbids completing the same request twice.
>>> >> >>
>>> >> >> Our implementation always starts processing the requests
>>> >> >> in order, and since we flush outstanding requests
>>> >> >> before save, it works to just tell the remote 'process only requests
>>> >> >> after this place'.
>>> >> >>
>>> >> >> But there's no such requirement in the virtio protocol,
>>> >> >> so to be really generic we could add a bitmask of valid avail
>>> >> >> ring entries that did not complete yet. This would be
>>> >> >> the exact representation of the guest observable state.
>>> >> >> In practice we have rings of up to 512 entries.
>>> >> >> That's 64 byte per ring, not a lot at all.
>>> >> >>
>>> >> >> However, if we ever do change the protocol to send the bitmask,
>>> >> >> we would need some code to resubmit requests
>>> >> >> out of order, so it's not trivial.
>>> >> >>
>>> >> >> Another minor mistake with last_avail_idx is that it has
>>> >> >> some redundancy: the high bits in the index
>>> >> >> (> vq size) are not necessary as they can be
>>> >> >> got from avail idx. There's a consistency check
>>> >> >> in load but we really should try to use formats
>>> >> >> that are always consistent.
>>> >> >>
>>> >> >>> The following patch does the same thing as original, yet
>>> >> >>> keeps the format of the virtio. It shouldn't break live
>>> >> >>> migration either because inuse should be 0.
>>> >> >>>
>>> >> >>> Yoshi
>>> >> >>
>>> >> >> Question is, can you flush to make inuse 0 in kemari too?
>>> >> >> And if not, how do you handle the fact that some requests
>>> >> >> are in flight on the primary?
>>> >> >
>>> >> > Although we try flushing requests one by one making inuse 0,
>>> >> > there are cases when it failovers to the secondary when inuse
>>> >> > isn't 0. We handle these in flight request on the primary by
>>> >> > replaying on the secondary.
>>> >> >
>>> >> >>
>>> >> >>> diff --git a/hw/virtio.c b/hw/virtio.c
>>> >> >>> index c8a0fc6..875c7ca 100644
>>> >> >>> --- a/hw/virtio.c
>>> >> >>> +++ b/hw/virtio.c
>>> >> >>> @@ -664,12 +664,16 @@ void virtio_save(VirtIODevice *vdev, QEMUFile *f)
>>> >> >>> qemu_put_be32(f, i);
>>> >> >>>
>>> >> >>> for (i = 0; i < VIRTIO_PCI_QUEUE_MAX; i++) {
>>> >> >>> + uint16_t last_avail_idx;
>>> >> >>> +
>>> >> >>> if (vdev->vq[i].vring.num == 0)
>>> >> >>> break;
>>> >> >>>
>>> >> >>> + last_avail_idx = vdev->vq[i].last_avail_idx - vdev->vq[i].inuse;
>>> >> >>> +
>>> >> >>> qemu_put_be32(f, vdev->vq[i].vring.num);
>>> >> >>> qemu_put_be64(f, vdev->vq[i].pa);
>>> >> >>> - qemu_put_be16s(f, &vdev->vq[i].last_avail_idx);
>>> >> >>> + qemu_put_be16s(f, &last_avail_idx);
>>> >> >>> if (vdev->binding->save_queue)
>>> >> >>> vdev->binding->save_queue(vdev->binding_opaque, i, f);
>>> >> >>> }
>>> >> >>>
>>> >> >>>
>>> >> >>
>>> >> >> This looks wrong to me. Requests can complete in any order, can they
>>> >> >> not? So if request 0 did not complete and request 1 did not,
>>> >> >> you send avail - inuse and on the secondary you will process and
>>> >> >> complete request 1 the second time, crashing the guest.
>>> >> >
>>> >> > In case of Kemari, no. We sit between devices and net/block, and
>>> >> > queue the requests. After completing each transaction, we flush
>>> >> > the requests one by one. So there won't be completion inversion,
>>> >> > and therefore won't be visible to the guest.
>>> >> >
>>> >> > Yoshi
>>> >> >
>>> >> >>
>>> >> >>>
>>> >> >>> >
>>> >> >>> >> >
>>> >> >>> >> >> ---
>>> >> >>> >> >> hw/virtio.c | 8 +++++++-
>>> >> >>> >> >> 1 files changed, 7 insertions(+), 1 deletions(-)
>>> >> >>> >> >>
>>> >> >>> >> >> diff --git a/hw/virtio.c b/hw/virtio.c
>>> >> >>> >> >> index 849a60f..5509644 100644
>>> >> >>> >> >> --- a/hw/virtio.c
>>> >> >>> >> >> +++ b/hw/virtio.c
>>> >> >>> >> >> @@ -72,7 +72,7 @@ struct VirtQueue
>>> >> >>> >> >> VRing vring;
>>> >> >>> >> >> target_phys_addr_t pa;
>>> >> >>> >> >> uint16_t last_avail_idx;
>>> >> >>> >> >> - int inuse;
>>> >> >>> >> >> + uint16_t inuse;
>>> >> >>> >> >> uint16_t vector;
>>> >> >>> >> >> void (*handle_output)(VirtIODevice *vdev, VirtQueue *vq);
>>> >> >>> >> >> VirtIODevice *vdev;
>>> >> >>> >> >> @@ -671,6 +671,7 @@ void virtio_save(VirtIODevice *vdev, QEMUFile *f)
>>> >> >>> >> >> qemu_put_be32(f, vdev->vq[i].vring.num);
>>> >> >>> >> >> qemu_put_be64(f, vdev->vq[i].pa);
>>> >> >>> >> >> qemu_put_be16s(f, &vdev->vq[i].last_avail_idx);
>>> >> >>> >> >> + qemu_put_be16s(f, &vdev->vq[i].inuse);
>>> >> >>> >> >> if (vdev->binding->save_queue)
>>> >> >>> >> >> vdev->binding->save_queue(vdev->binding_opaque, i, f);
>>> >> >>> >> >> }
>>> >> >>> >> >> @@ -711,6 +712,11 @@ int virtio_load(VirtIODevice *vdev, QEMUFile *f)
>>> >> >>> >> >> vdev->vq[i].vring.num = qemu_get_be32(f);
>>> >> >>> >> >> vdev->vq[i].pa = qemu_get_be64(f);
>>> >> >>> >> >> qemu_get_be16s(f, &vdev->vq[i].last_avail_idx);
>>> >> >>> >> >> + qemu_get_be16s(f, &vdev->vq[i].inuse);
>>> >> >>> >> >> +
>>> >> >>> >> >> + /* revert last_avail_idx if there are outstanding emulation. */
>>> >> >>> >> >> + vdev->vq[i].last_avail_idx -= vdev->vq[i].inuse;
>>> >> >>> >> >> + vdev->vq[i].inuse = 0;
>>> >> >>> >> >>
>>> >> >>> >> >> if (vdev->vq[i].pa) {
>>> >> >>> >> >> virtqueue_init(&vdev->vq[i]);
>>> >> >>> >> >> --
>>> >> >>> >> >> 1.7.1.2
>>> >> >>> >> >>
>>> >> >>> >> >> --
>>> >> >>> >> >> To unsubscribe from this list: send the line "unsubscribe kvm" in
>>> >> >>> >> >> the body of a message to majordomo@vger.kernel.org
>>> >> >>> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> >> >>> >> > --
>>> >> >>> >> > To unsubscribe from this list: send the line "unsubscribe kvm" in
>>> >> >>> >> > the body of a message to majordomo@vger.kernel.org
>>> >> >>> >> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> >> >>> >> >
>>> >> >>> > --
>>> >> >>> > To unsubscribe from this list: send the line "unsubscribe kvm" in
>>> >> >>> > the body of a message to majordomo@vger.kernel.org
>>> >> >>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> >> >>> >
>>> >> >> --
>>> >> >> To unsubscribe from this list: send the line "unsubscribe kvm" in
>>> >> >> the body of a message to majordomo@vger.kernel.org
>>> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> >> >>
>>> >> >
>>> > --
>>> > To unsubscribe from this list: send the line "unsubscribe kvm" in
>>> > the body of a message to majordomo@vger.kernel.org
>>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> >
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
^ permalink raw reply
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.