All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Long Li <longli@microsoft.com>
Cc: KY Srinivasan <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	"devel@linuxdriverproject.org" <devel@linuxdriverproject.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] hv: retry infinitely on hypercall transient failures
Date: Sat, 7 Jan 2017 08:42:33 +0100	[thread overview]
Message-ID: <20170107074233.GB18087@kroah.com> (raw)
In-Reply-To: <BN3PR03MB22273BCF837FDF575D94CD0CCE620@BN3PR03MB2227.namprd03.prod.outlook.com>

On Sat, Jan 07, 2017 at 07:23:14AM +0000, Long Li wrote:
> > -----Original Message-----
> > From: Greg KH [mailto:greg@kroah.com]
> > Sent: Wednesday, January 04, 2017 11:48 PM
> > To: Long Li <longli@microsoft.com>
> > Cc: KY Srinivasan <kys@microsoft.com>; Haiyang Zhang
> > <haiyangz@microsoft.com>; devel@linuxdriverproject.org; linux-
> > kernel@vger.kernel.org
> > Subject: Re: [PATCH v2] hv: retry infinitely on hypercall transient failures
> > 
> > On Wed, Jan 04, 2017 at 06:12:20PM -0800, Long Li wrote:
> > > From: Long Li <longli@microsoft.com>
> > >
> > > Hyper-v host guarantees that a hypercall will finish in reasonable time.
> > > Retry infinitely on transient failures to avoid returning error to upper layer.
> > 
> > Again, never retry "forever", always have a way out, otherwise you will crash.
> > 
> > And again, why are you making this change?  What problem does it solve?
> 
> The problem it tries to solve is that in this code we are returning
> error prematurely on transient failures. The hypercall is used mostly
> in channel establishment. If we return a transient failure, the VM may
> not boot or not useful after boot due to some devices missing.
> 
> Another approach is to increase the number of retries. But we don't
> know how many retries is safe, and Windows host side expects the guest
> retry infinitely and not return error on transient failures.

That implies a lot of trust in the host side, don't you think?

Worse case, make the delay a minute or so, but give the system a way out
incase there's a bug in the host.  As there will be bugs in the host,
just like there are bugs in the client :)

thanks,

greg k-h

  reply	other threads:[~2017-01-07  7:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-05  2:12 [PATCH v2] hv: retry infinitely on hypercall transient failures Long Li
2017-01-05  7:47 ` Greg KH
2017-01-07  7:23   ` Long Li
2017-01-07  7:42     ` Greg KH [this message]
2017-01-07  8:06       ` Long Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170107074233.GB18087@kroah.com \
    --to=greg@kroah.com \
    --cc=devel@linuxdriverproject.org \
    --cc=haiyangz@microsoft.com \
    --cc=kys@microsoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longli@microsoft.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.