[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200721001736.GB19610@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com>
Date: Tue, 21 Jul 2020 00:17:36 +0000
From: Anchal Agarwal <anchalag@...zon.com>
To: Roger Pau Monné <roger.pau@...rix.com>
CC: Boris Ostrovsky <boris.ostrovsky@...cle.com>, <tglx@...utronix.de>,
<mingo@...hat.com>, <bp@...en8.de>, <hpa@...or.com>,
<x86@...nel.org>, <jgross@...e.com>, <linux-pm@...r.kernel.org>,
<linux-mm@...ck.org>, <kamatam@...zon.com>,
<sstabellini@...nel.org>, <konrad.wilk@...cle.com>,
<axboe@...nel.dk>, <davem@...emloft.net>, <rjw@...ysocki.net>,
<len.brown@...el.com>, <pavel@....cz>, <peterz@...radead.org>,
<eduval@...zon.com>, <sblbir@...zon.com>,
<xen-devel@...ts.xenproject.org>, <vkuznets@...hat.com>,
<netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<dwmw@...zon.co.uk>, <benh@...nel.crashing.org>
Subject: Re: [PATCH v2 01/11] xen/manage: keep track of the on-going suspend mode
On Mon, Jul 20, 2020 at 11:37:05AM +0200, Roger Pau Monné wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> On Sat, Jul 18, 2020 at 09:47:04PM -0400, Boris Ostrovsky wrote:
> > (Roger, question for you at the very end)
> >
> > On 7/17/20 3:10 PM, Anchal Agarwal wrote:
> > > On Wed, Jul 15, 2020 at 05:18:08PM -0400, Boris Ostrovsky wrote:
> > >> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> > >>
> > >>
> > >>
> > >> On 7/15/20 4:49 PM, Anchal Agarwal wrote:
> > >>> On Mon, Jul 13, 2020 at 11:52:01AM -0400, Boris Ostrovsky wrote:
> > >>>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 7/2/20 2:21 PM, Anchal Agarwal wrote:
> > >>>> And PVH dom0.
> > >>> That's another good use case to make it work with however, I still
> > >>> think that should be tested/worked upon separately as the feature itself
> > >>> (PVH Dom0) is very new.
> > >>
> > >> Same question here --- will this break PVH dom0?
> > >>
> > > I haven't tested it as a part of this series. Is that a blocker here?
> >
> >
> > I suspect dom0 will not do well now as far as hibernation goes, in which
> > case you are not breaking anything.
> >
> >
> > Roger?
>
> I sadly don't have any box ATM that supports hibernation where I
> could test it. We have hibernation support for PV dom0, so while I
> haven't done anything specific to support or test hibernation on PVH
> dom0 I would at least aim to not make this any worse, and hence the
> check should at least also fail for a PVH dom0?
>
> if (!xen_hvm_domain() || xen_initial_domain())
> return -ENODEV;
>
> Ie: none of this should be applied to a PVH dom0, as it doesn't have
> PV devices and hence should follow the bare metal device suspend.
>
So from what I understand you meant for any guest running on pvh dom0 should not
hibernate if hibernation is triggered from within the guest or should they?
> Also I would contact the QubesOS guys, they rely heavily on the
> suspend feature for dom0, and that's something not currently tested by
> osstest so any breakages there go unnoticed.
>
Was this for me or Boris? If its the former then I have no idea how to?
> Thanks, Roger.
Thanks,
Anchal
Powered by blists - more mailing lists