[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <PU1P153MB01699A21E81D9E8E872A190ABFDF0@PU1P153MB0169.APCP153.PROD.OUTLOOK.COM>
Date: Wed, 31 Jul 2019 00:01:53 +0000
From: Dexuan Cui <decui@...rosoft.com>
To: Michael Kelley <mikelley@...rosoft.com>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
Stephen Hemminger <sthemmin@...rosoft.com>,
Sasha Levin <Alexander.Levin@...rosoft.com>,
"sashal@...nel.org" <sashal@...nel.org>,
Haiyang Zhang <haiyangz@...rosoft.com>,
KY Srinivasan <kys@...rosoft.com>,
"tglx@...utronix.de" <tglx@...utronix.de>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 5/7] Drivers: hv: vmbus: Ignore the offers when resuming
from hibernation
> From: Michael Kelley <mikelley@...rosoft.com>
> Sent: Tuesday, July 30, 2019 4:07 PM
> > +
> > + if (oldchannel != NULL) {
> > + atomic_dec(&vmbus_connection.offer_in_progress);
> > +
> > + /*
> > + * We're resuming from hibernation: we expect the host to send
> > + * exactly the same offers that we had before the hibernation.
> > + */
> > + offer_sz = sizeof(*offer);
> > + if (memcmp(offer, &oldchannel->offermsg, offer_sz) == 0)
> > + return;
>
> The offermsg contains "reserved" and "padding" fields. Does Hyper-V
> guarantee that all these fields are the same in the new offer after resuming
> from hibernation?
Yes. I confirmed this with Hyper-V team. The reserved/padding fields don't change
across hiberantion. BTW, the fields are filled with zeros since they're not used.
> Or should a less stringent check be made? For example,
> I could imagine a newer version of Hyper-V allowing a VM that was
> hibernated on an older version to be resumed. But one of the reserved fields
> might be used in the newer version, and the comparison could fail
> unnecessarily.
Upon resume, Linux VM always uses the same version, which was used when the
VM firstly booted up before suspend, to re-negotiate with the host.
> > +
> > + pr_err("Mismatched offer from the host (relid=%d)!\n",
> > + offer->child_relid);
> > +
> > + print_hex_dump_debug("Old vmbus offer: ", DUMP_PREFIX_OFFSET,
> 4,
> > + 4, &oldchannel->offermsg, offer_sz, false);
> > + print_hex_dump_debug("New vmbus offer: ",
> DUMP_PREFIX_OFFSET, 4,
> > + 4, offer, offer_sz, false);
>
> The third argument to print_hex_dump() is the rowsize and is specified as must
> be 16 or 32.
Thanks! I misunderstood the argument. I'll change it to 16.
Thanks,
-- Dexuan
Powered by blists - more mailing lists