From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
Wei Liu <Wei.Liu2@citrix.com>,
George Dunlap <george.dunlap@citrix.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: 4.7 qemu regression: HVM guests fail to boot from xvda
Date: Tue, 7 Jun 2016 21:06:57 +0200 [thread overview]
Message-ID: <20160607190657.GA10302@aepfle.de> (raw)
In-Reply-To: <22353.28127.934683.210436@mariner.uk.xensource.com>
On Fri, Jun 03, Ian Jackson wrote:
> There are two problems with this `hdtype' approach.
>
> Firstly, it is global. That is, it applies to all disks of the
> particular guest. But then maybe we don't care about that because
> this anomalous major-number-stealing behaviour is probably per-guest
> rather than per-disk.
I think there is no issue with hdtype being a global knob. The
controller type for disks is either piix or ahci.
> Secondly, the proposal above involves changing both the semantics of
> existing `hdtype' parameter values, and the default hdtype value. The
> resulting situation would be that even specifying vdev=hda wouldn't
> get you an emulated device, by default, unless you specified `hdtype'
> too. I don't think that is right.
IMO vdev= should influence hdtype= if it is unset. Just to make sure the
emulated disk with vdev=xvd can be achived with existing config knobs.
I think the situation was like this in xen-4.6:
a) no hdtype=, vdev=hd results in an emulated piix controller
b) no hdtype=, vdev=xvd results in an emulated piix controller
c) hdtype=ide, vdev=hd results in an emulated pixx controller
d) hdtype=ide, vdev=xvd results in an emulated piix controller
e) hdtype=ahci, vdev=hd results in an emulated ahci controller
f) hdtype=ahci, vdev=xvd results in an emulated ahci controller
Each of the above was bootable because the disk was visible to the BIOS.
It was possible to mix hd and xvd for disks as long as the index
(a,b,c,..) is unique.
With xen-4.7 any of the vdev=xvd results in a non-booting guest.
So something has to be changed in domU.cfg anyway.
Currently its like this:
a) no hdtype=, vdev=hd results in an emulated piix controller
b) no hdtype=, vdev=xvd results in PV-only disk
c) hdtype=ide, vdev=hd results in an emulated pixx controller
d) hdtype=ide, vdev=xvd results in PV-only disk
e) hdtype=ahci, vdev=hd results in an emulated ahci controller
f) hdtype=ahci, vdev=xvd results in PV-only disk
This could be added:
hdtype=ide and vdev=xvd gives an emulated piix controller
hdtype=ahci and vdev=xvd gives an emulated ahci controller
To achieve this the default hdtype= should become "UNSET", and a vdev=hd
should set it to IDE if it was "UNSET". That means there could be yet
another state "PVONLY".
As a result the possible configs in xen-4.7 are liks this:
a) no hdtype=, vdev=hd results in an emulated piix controller
b) no hdtype=, vdev=xvd results in PV-only disk
c) hdtype=ide, vdev=hd results in an emulated pixx controller
d) hdtype=ide, vdev=xvd results in an emulated piix controller
e) hdtype=ahci, vdev=hd results in an emulated ahci controller
f) hdtype=ahci, vdev=xvd results in an emulated ahci controller
g) hdtype=pv, vdev=hd results in PV-only disk
h) hdtype=pv, vdev=xvd results in PV-only disk
Existing domU.cfg with variant b) have to be changed to d) to get them
boot again, or rather connect the disks to an emulated controller.
I'm not sure if case g) and h) are really needed.
In my testing with xen-4.6 using hdtype=ahci resulted in no unplug, so I
think ahci was really just for emulated usage. Perhaps the pvops kernel
does a more complete unplug? I have not tested ahci with xen-4.7.
> The possibilities I see are:
>
> (1) New boolean per-guest parameter for this behaviour, meaning
> `provide emulated devices for all xvd* as if they were hd*'.
This would be an backward compatible approach, at least domU.cfg will
work with older toolstack. libvirt needs to know about this.
> (2) New `hdtype=ideforpv' which has the same effect as `hdtype=ide'
> plus the semantics in (1) above. (I'm open to better naming
> suggestions.)
This would be an incompatible change, older toolstacks dont know the
value.
> (3) New disk property parameter `hvm-emulate' in the Deprecated
> section of xl-disk-configuration.txt.
This would be an incompatible change, older toolstacks dont know the
value.
> Open questions:
>
> Do we also need `... as if they were sd*' or `provide ide emulated
> devices where vdev=sd* is specified?'
sd results in an emulated LSI SCSI controller.
> If we have `hdtype=ideinclpv' do we also need `hdtype=ahciinclpv' ?
I think that is not needed given that there is no unplug (in my
testing).
> What should happen if these options are enabled for PV guests - should
> they be silently ignored, or should they be rejected ?
IMO no. Do we have such rejects already for PV or HVM only options?
It has to be noted that libvirt does not seem to know about the hdtype=
knob, which was introduced in xen-4.6.
Olaf
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-06-07 19:06 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-30 20:42 4.7 qemu regression: HVM guests fail to boot from xvda Olaf Hering
2016-05-31 11:02 ` George Dunlap
2016-05-31 11:16 ` Olaf Hering
2016-05-31 11:32 ` George Dunlap
2016-05-31 11:41 ` Olaf Hering
2016-05-31 12:00 ` George Dunlap
2016-05-31 12:04 ` Olaf Hering
2016-06-01 13:17 ` Olaf Hering
2016-06-01 21:40 ` Olaf Hering
2016-06-02 11:49 ` Wei Liu
2016-06-02 12:06 ` Olaf Hering
2016-05-31 12:15 ` Jan Beulich
2016-06-01 9:48 ` Wei Liu
2016-06-01 13:34 ` Olaf Hering
2016-06-01 14:11 ` Wei Liu
2016-06-01 14:32 ` Olaf Hering
2016-06-01 15:36 ` Ian Jackson
2016-06-03 10:13 ` George Dunlap
2016-06-03 11:20 ` Olaf Hering
2016-06-03 11:27 ` George Dunlap
2016-06-03 11:45 ` Ian Jackson
2016-06-06 10:39 ` George Dunlap
2016-06-06 10:52 ` Ian Jackson
2016-06-06 11:43 ` George Dunlap
2016-06-06 12:49 ` George Dunlap
2016-06-07 14:08 ` George Dunlap
2016-06-07 14:27 ` Olaf Hering
2016-06-08 10:17 ` Ian Jackson
2016-06-07 19:06 ` Olaf Hering [this message]
2016-06-08 10:18 ` Ian Jackson
2016-06-08 10:23 ` George Dunlap
2016-06-08 10:30 ` Ian Jackson
2016-06-08 10:49 ` George Dunlap
2016-06-08 11:13 ` Olaf Hering
2016-06-08 15:56 ` Konrad Rzeszutek Wilk
2016-06-03 11:50 ` Olaf Hering
2016-05-31 12:10 ` Jan Beulich
2016-05-31 13:41 ` George Dunlap
2016-05-31 14:10 ` Jan Beulich
2016-05-31 16:15 ` Konrad Rzeszutek Wilk
2016-06-08 11:38 ` Wei Liu
2016-06-08 12:04 ` Olaf Hering
2016-06-08 12:09 ` Wei Liu
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=20160607190657.GA10302@aepfle.de \
--to=olaf@aepfle.de \
--cc=Ian.Jackson@eu.citrix.com \
--cc=Wei.Liu2@citrix.com \
--cc=anthony.perard@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=xen-devel@lists.xen.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).