From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: Doug Goldstein <cardoe@cardoe.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
"Tian, Kevin" <kevin.tian@intel.com>,
Wei Liu <wei.liu2@citrix.com>, Jan Beulich <JBeulich@suse.com>,
Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH RFC 00/10] x86 passthrough code cleanup
Date: Mon, 26 Feb 2018 01:47:38 +0100 [thread overview]
Message-ID: <20180226004738.GO2023@mail-itl> (raw)
In-Reply-To: <a4d4900e-ba01-bde2-b2a4-79dcf0d8bebb@cardoe.com>
[-- Attachment #1.1: Type: text/plain, Size: 2243 bytes --]
On Fri, Feb 23, 2018 at 10:39:20PM -0600, Doug Goldstein wrote:
> On 2/22/18 11:12 PM, Tian, Kevin wrote:
> >> From: Wei Liu
> >> Sent: Thursday, February 22, 2018 5:47 AM
> >>
> >> Hi all
> >>
> >> At some point I would like to make CONFIG_HVM and CONFIG_PV work.
> >> The
> >> passthrough code is one of the road blocks for that work.
> >
> > Can you elaborate the motivation of this change? why does someone
> > want to disable HVM or PV logic completely from hypervisor?
>
> I can say I recall advocating for this at Xen Summit in Cambridge. I
> believe I talked about it in Toronto as well. There are a number of
> users of Xen that would certainly want to ship without all the code
> associated with PV compiled in. Given the nature of design "compromises"
> in many parts of x86 systems there is certainly a non-zero sum of people
> that would likely utilize the ability to remove code that doesn't need
> to be there. I think every individual on this list who has been involved
> in the security has been in a room of @intel.com folks has seen features
> vs security win out many times.
>
> I don't think its a hard stretch of the imagination to see people
> disabling PV in data centers running newer workloads on PVH and HVM
> only.
Yes, definitely disabling PV will be useful. Right after being able to
use PCI passthrough with PVH.
> I can see the real question being why HVM? That I would say lies
> with the direction of discretionary access controls in Xen vs mandatory
> access controls. To solve for the lack of functionality we've grown
> things like "dmops" and I could certainly see a product like Qubes
> running only PVH domains in the future.
>
> Since I picked on Qubes I've CC'd Marek.
So, is it going to be an option to have CONFIG_HVM=n and CONFIG_PVH=y at
the same time? While currently we do support Windows, so need
CONFIG_HVM=y, but I can see in some future/alternative version we could
have even that disabled. For example right now we do have
CONFIG_SHADOW_PAGING disabled.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2018-02-26 0:48 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-21 21:46 [PATCH RFC 00/10] x86 passthrough code cleanup Wei Liu
2018-02-21 21:46 ` [PATCH RFC 01/10] passthrough: rearrange x86 code Wei Liu
2018-04-23 15:27 ` Jan Beulich
2018-02-21 21:46 ` [PATCH RFC 02/10] passthrough: split out x86 PCI code to x86/pci.c Wei Liu
2018-02-26 10:57 ` Julien Grall
2018-04-23 15:34 ` Jan Beulich
2018-04-24 9:08 ` Julien Grall
2018-02-21 21:46 ` [PATCH RFC 03/10] x86/passthrough: io.c is used for HVM only Wei Liu
2018-04-23 15:37 ` Jan Beulich
2018-02-21 21:46 ` [PATCH RFC 04/10] x86/passthrough: arch_pci_clean_irqs is " Wei Liu
2018-02-21 21:46 ` [PATCH RFC 05/10] x86/passthrough: move hvm_dpci_isairq_eoi Wei Liu
2018-04-23 15:39 ` Jan Beulich
2018-02-21 21:46 ` [PATCH RFC 06/10] passthrough/amd: remove guest iommu support Wei Liu
2018-05-02 17:10 ` Suravee Suthikulpanit
2018-02-21 21:46 ` [PATCH RFC 07/10] passthrough/amd: split out hvm code from iommu_map.c Wei Liu
2018-04-23 15:43 ` Jan Beulich
2018-05-02 17:32 ` Suravee Suthikulpanit
2018-02-21 21:46 ` [PATCH RFC 08/10] passthrough/amd: make clear_iommu_pte_present static Wei Liu
2018-02-21 21:47 ` [PATCH RFC 09/10] passthrough/intel: put some code under CONFIG_HVM Wei Liu
2018-04-23 15:47 ` Jan Beulich
2018-02-21 21:47 ` [PATCH RFC 10/10] x86: check hvm domain before calling pt_irq_destroy_bind Wei Liu
2018-02-23 5:12 ` [PATCH RFC 00/10] x86 passthrough code cleanup Tian, Kevin
2018-02-23 16:08 ` Wei Liu
2018-02-24 3:23 ` Tian, Kevin
2018-02-26 8:20 ` Jan Beulich
2018-02-26 12:45 ` Wei Liu
2018-02-24 4:39 ` Doug Goldstein
2018-02-26 0:47 ` Marek Marczykowski-Górecki [this message]
2018-02-26 12:49 ` Wei Liu
2018-03-08 12:18 ` Wei Liu
2018-03-08 12:37 ` Jan Beulich
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=20180226004738.GO2023@mail-itl \
--to=marmarek@invisiblethingslab.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=cardoe@cardoe.com \
--cc=kevin.tian@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).