[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH-for-4.12] docs: Fix dm_restrict documentation



On Fri, Jan 25, 2019 at 04:39:35PM +0000, Anthony PERARD wrote:
> On Fri, Jan 25, 2019 at 04:10:55PM +0000, Wei Liu wrote:
> > On Fri, Jan 25, 2019 at 02:47:20PM +0000, George Dunlap wrote:
> > > On 1/25/19 11:33 AM, Wei Liu wrote:
> > > > On Thu, Jan 24, 2019 at 05:48:27PM +0000, George Dunlap wrote:
> > > >> Remove "chatty" and redundant information from the xl man page;
> > > >> restrict it to functional descriptions only, and point instead to
> > > >> qemu-depriv.pandoc and SUPPORT.md as locations for "canonical"
> > > >> information.
> > > >>
> > > >> Add a man page entry for device_model_user.
> > > >>
> > > >> Update qemu-deprivilege.pandoc:
> > > >>
> > > >> Changes in missing feature list:
> > > >> - Migration is functional
> > > >> - But qdisk backends are not
> > > >>
> > > >> Add a missing restriction list.
> > > >>
> > > >> The following statements from the man page are dropped:
> > > >> - Mentioning PV; PV guests never have a device model.
> > > >> - Drop the confusing statement about stdvga and cirrus vga options.
> > > >> - Re-used domain IDs are now handled.
> > > >> - Device models should no longer be able to create world-readable
> > > >>   files on dom0's filesystem.
> > > >>
> > > >> Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxx>
> > > >> ---
> > > >> RFC: I don't know what the 'vga' limitation thing was about -- I tried
> > > >> both 'default' and 'stgvga' with dm_restrict and they worked fine.
> > > > 
> > > > I think until we figure out the situation of vga, the statement should
> > > > stay.
> > > 
> > > How would we do that?
> > 
> > Per my understanding:
> > 
> >   Setting vga option to anything else other than "none" may not work
> > 
> > ?
> 
> Is their an issue with the vga setting and dm_restrict=1 ? I never add
> any problem. Accessing the guest graphic output via VNC while running
> with dm_restrict works fine. (but I only ever use the default.)
> 
> Maybe it's time to blame! And do some archeology ...
> 
> Base on commit 7d278e2115d084a5f78a512ae01ce946c10cff7d
> "xl: Document VGA problems arising from lack of physmap dmop"
> the issue is just that using xc_domain_add_to_physmap doesn't work.
> 
> But that issue has been addressed with a new DMOPS, and QEMU have
> support for it since:
> commit 2cbf8903530b936964dd3af7e2e5bf85c3955d5c
> "xen: Use newly added dmops for mapping VGA memory"
> which is QEMU 3.0.
> 
> qemu-xen-4.12.0 is at least QEMU 3.0. So it should be just a matter of
> documenting that we need QEMU 3.0.
> But based on qemu-deprivilege.pandoc, QEMU 3.0 is required for
> dm_restrict to works, so all is fine. The original mention of problem
> with vga!=none isn't true anymore.
> 
> Version requirement is documented in the man page, which redirect to
> qemu-deprivilege.pandoc which specify QEMU 3.0+. So all is fine.

OK. That's convincing. Thanks for digging.

We can remove the statement for 4.12.

Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.