From: Paul Durrant <xadimgnik@gmail.com>
To: "'Julien Grall'" <julien@xen.org>, <xen-devel@lists.xenproject.org>
Cc: 'Stefano Stabellini' <sstabellini@kernel.org>,
'Wei Liu' <wl@xen.org>,
'Andrew Cooper' <andrew.cooper3@citrix.com>,
'Ian Jackson' <ian.jackson@eu.citrix.com>,
'George Dunlap' <george.dunlap@citrix.com>,
'Jan Beulich' <jbeulich@suse.com>
Subject: RE: [PATCH 1/5] xen/common: introduce a new framework for save/restore of 'domain' context
Date: Mon, 6 Apr 2020 11:34:39 +0100 [thread overview]
Message-ID: <002801d60bfe$fab5de70$f0219b50$@xen.org> (raw)
In-Reply-To: <ac273b12-36f4-ca5c-c18b-7a59d2b84e2e@xen.org>
> -----Original Message-----
[snip]
> >> * The name of the hypercall does not say anything about "PV". So a
> >> contributor could think it would be fine to save/restore new HVM state
> >> in the new generic hypercall. Is it going to be an issue? If so, how do
> >> we prevent it?
> >
> > The commit message says:
> >
> > "Domain context is state held in the hypervisor that does not come under
> > the category of 'HVM state' but is instead 'PV state' that is common
> > between PV guests and enlightened HVM guests (i.e. those that have PV
> > drivers) such as event channel state, grant entry state, etc."
>
> This does not seem to cover all the cases. For instance, where would you
> save IOREQ servers information?
>
Ok, I agree that is ambiguous. I'd still call it PV state but of course it does only relate to HVM guests.
> >
> > Do you think this should also appear in a comment? Do we really care? Nothing fundamentally prevents
> the mechanism being used for HVM state, but that may introduce an ordering dependency.
>
> I don't particularly like the idea to let the contributor decide where
> "HVM context" or as part of the "Domain context".
>
> This is going to result to unwanted dependency and possibly
> bikeshedding on where they should be saved.
>
> My preference would be to mark the existing framework as deprecated and
> force all the new states to be saved as part of the new "Domain Context".
>
I'm ok with that. Any others have any opinion to the contrary?
> >
> >> * Are we going to deprecate the existing framework?
> >>
> >
> > There is no intention as yet.
> >
> >> I am not suggesting we should not go with two frameworks, but the
> >> reasons and implications are not clear to me. Hence, why I think the
> >> commit message should be expanded with some rationale.
> >>
> >
> > Ok, I can add a paragraph to try to explain a little more.
>
> That would be appreciated. Thank you!
>
I'll mention the deprecation of the HVM context interface there too.
Paul
next prev parent reply other threads:[~2020-04-06 10:35 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-27 18:50 [Xen-devel] [PATCH 0/5] domain context infrastructure Paul Durrant
2020-03-27 18:50 ` [Xen-devel] [PATCH 1/5] xen/common: introduce a new framework for save/restore of 'domain' context Paul Durrant
2020-04-01 12:00 ` Julien Grall
2020-04-01 12:07 ` Jan Beulich
2020-04-01 12:16 ` Julien Grall
2020-04-01 12:23 ` Jan Beulich
2020-04-03 15:55 ` Paul Durrant
2020-04-03 17:24 ` Julien Grall
2020-04-06 8:27 ` Paul Durrant
2020-04-06 9:08 ` Julien Grall
2020-04-06 9:18 ` Paul Durrant
2020-04-06 9:50 ` Julien Grall
2020-04-06 10:34 ` Paul Durrant [this message]
2020-04-06 12:43 ` Jan Beulich
2020-04-01 14:50 ` Jan Beulich
2020-04-02 9:58 ` Paul Durrant
2020-04-02 11:08 ` Jan Beulich
2020-04-02 14:00 ` Paul Durrant
2020-04-03 8:38 ` Jan Beulich
2020-03-27 18:50 ` [Xen-devel] [PATCH 2/5] xen/common/domctl: introduce XEN_DOMCTL_get/setdomaincontext Paul Durrant
2020-04-01 13:42 ` Julien Grall
2020-04-06 9:07 ` Paul Durrant
2020-04-06 12:46 ` Jan Beulich
2020-04-01 13:46 ` Julien Grall
2020-03-27 18:50 ` [Xen-devel] [PATCH 3/5] tools/misc: add xen-ctx to present domain context Paul Durrant
2020-03-30 10:54 ` Jan Beulich
2020-04-03 15:20 ` Paul Durrant
2020-04-03 15:29 ` Jan Beulich
2020-04-03 16:08 ` Paul Durrant
2020-03-27 18:50 ` [Xen-devel] [PATCH 4/5] common/domain: add a domain context record for shared_info Paul Durrant
2020-04-01 14:27 ` Julien Grall
2020-03-27 18:50 ` [Xen-devel] [PATCH 5/5] tools/libxc: make use of domain context SHARED_INFO record Paul Durrant
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='002801d60bfe$fab5de70$f0219b50$@xen.org' \
--to=xadimgnik@gmail.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=paul@xen.org \
--cc=sstabellini@kernel.org \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/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.