From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Ian Jackson <Ian.Jackson@citrix.com>,
Daniel De Graaf <dgdegra@tycho.nsa.gov>,
Jennifer Herbert <jennifer.herbert@citrix.com>,
Wei Liu <wei.liu2@citrix.com>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v4 1/8] public / x86: Introduce __HYPERCALL_dm_op...
Date: Mon, 23 Jan 2017 09:15:22 +0000 [thread overview]
Message-ID: <058b582c-6b43-cc6f-cd76-1466429a18a0@citrix.com> (raw)
In-Reply-To: <2beab20fec434dd38ca636aed123c9f4@AMSPEX02CL03.citrite.net>
On 20/01/2017 15:02, Paul Durrant wrote:
>
>>> + if ( !rc &&
>>> + !copy_buf_to_guest(bufs, nr_bufs, 0, &op, sizeof(op)) )
>> Do all ops need a copyback? If they do, this is fine. If not, it would
>> be better to have a copyback boolean which subops set as necessary.
> I can restrict copy-back using a boolean set for sub-ops that have 'out' params, or when there needs to be a continuation but I didn't really think it was worth the extra complexity.
Extraneous writebacks to PV guests are fairly cheep, but is is certainly
not the case for HVM guests. A writeback to HVM requires a least one
guest pagetable walk (which itself most likely includes an EPT/NPT walk).
From a correctness point of view, it is reasonable for an implementation
which expects a hypercall datastructure to be read only, to put said
structure in read-only memory. The PKRU feature in particular makes it
very easy to set something up, then switch it from RW to RO for use.
Such an implementation should have the hypercall fail with a spurious
-EFAULT after it has otherwise completed successfully.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-01-23 9:15 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-17 17:29 [PATCH v4 0/8] New hypercall for device models Paul Durrant
2017-01-17 17:29 ` [PATCH v4 1/8] public / x86: Introduce __HYPERCALL_dm_op Paul Durrant
2017-01-18 19:18 ` Daniel De Graaf
2017-01-19 9:01 ` Paul Durrant
2017-01-20 14:35 ` Andrew Cooper
2017-01-20 15:02 ` Paul Durrant
2017-01-23 9:15 ` Andrew Cooper [this message]
2017-01-23 9:17 ` Paul Durrant
2017-01-20 15:54 ` Wei Liu
2017-01-20 15:59 ` Paul Durrant
2017-01-20 16:03 ` Wei Liu
2017-01-20 16:17 ` Jan Beulich
2017-01-20 16:20 ` Paul Durrant
2017-01-20 16:38 ` Jan Beulich
2017-01-20 16:39 ` Paul Durrant
2017-01-17 17:29 ` [PATCH v4 2/8] dm_op: convert HVMOP_*ioreq_server* Paul Durrant
2017-01-18 9:55 ` Jan Beulich
2017-01-18 10:10 ` Paul Durrant
2017-01-18 19:19 ` Daniel De Graaf
2017-01-20 15:17 ` Andrew Cooper
2017-01-17 17:29 ` [PATCH v4 3/8] dm_op: convert HVMOP_track_dirty_vram Paul Durrant
2017-01-18 19:20 ` Daniel De Graaf
2017-01-20 16:20 ` Jan Beulich
2017-01-20 16:29 ` Paul Durrant
2017-01-20 16:32 ` Paul Durrant
2017-01-20 16:38 ` Jan Beulich
2017-01-20 17:22 ` Andrew Cooper
2017-01-17 17:29 ` [PATCH v4 4/8] dm_op: convert HVMOP_set_pci_intx_level, HVMOP_set_isa_irq_level, and Paul Durrant
2017-01-18 19:20 ` Daniel De Graaf
2017-01-20 17:31 ` [offlist] " Andrew Cooper
2017-01-17 17:29 ` [PATCH v4 5/8] dm_op: convert HVMOP_modified_memory Paul Durrant
2017-01-18 19:20 ` Daniel De Graaf
2017-01-20 16:24 ` Jan Beulich
2017-01-20 18:15 ` Andrew Cooper
2017-01-17 17:29 ` [PATCH v4 6/8] dm_op: convert HVMOP_set_mem_type Paul Durrant
2017-01-18 19:20 ` Daniel De Graaf
2017-01-20 18:28 ` Andrew Cooper
2017-01-23 8:52 ` Paul Durrant
2017-01-17 17:29 ` [PATCH v4 7/8] dm_op: convert HVMOP_inject_trap and HVMOP_inject_msi Paul Durrant
2017-01-18 19:21 ` Daniel De Graaf
2017-01-20 18:33 ` Andrew Cooper
2017-01-23 8:50 ` Paul Durrant
2017-01-17 17:29 ` [PATCH v4 8/8] x86/hvm: serialize trap injecting producer and consumer 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=058b582c-6b43-cc6f-cd76-1466429a18a0@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=Ian.Jackson@citrix.com \
--cc=Paul.Durrant@citrix.com \
--cc=dgdegra@tycho.nsa.gov \
--cc=jbeulich@suse.com \
--cc=jennifer.herbert@citrix.com \
--cc=wei.liu2@citrix.com \
--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.