On Wed, Oct 29, 2014 at 05:04:22PM +0530, Prerna Saxena wrote:
>
> On Tuesday 28 October 2014 05:32 PM, Daniel P. Berrange wrote:
> > On Tue, Oct 28, 2014 at 04:43:59PM +0530, Prerna Saxena wrote:
> >>
> >> This patch allows libvirt to extend the "fallback" semantics of cpu model
> >> to
> >> describe this new mode for PowerKVM guests.
> >> As an example:
> >> When a user wants to request a power7 vm to run in compatibility mode on
> >> a Power8 host, this can be described in XML as follows :
> >> <cpu mode='host-model' match='exact'>
> >> <model fallback='compat'>power7</model>
> > I don't really see any point in adding the fallback='compat'
> > attribute. That is basically always implied if you use
> > mode=host-model in combination with a named model.
> Hi Daniel,
> Running in compatibility mode is not identical to running natively on an
> older processor.
> Reproducing the example from :
> http://www.redhat.com/archives/libvir-list/2014-October/msg00359.html
>
> On PowerKVM, we can run VMs in 2 possible vCPU configurations:
> 1) Host native mode: Where host is power7; guest VMs also see power7 vcpus.
> Required qemu command line : "-cpu host"
>
> 2) Compat mode: In this case, the host CPU is Power8, but it can run
> in binary compatibility mode with an older version of ISA(such as
> power7). So it will exhibit only those features that were
> available in an older generation of Power ISA. The guest will see a
> "power7" vCPU even though it is running on a physical "power8" chip.
> This is a hardware feature that is enabled via a qemu/kvm switch.
>
> Required QEMU command line for PowerKVM : "-cpu host,compat=power7"
Sure, I don't debate that this is the QEMU command line syntax. I don't
see any reason why the fact that QEMU uses 'compat' here requires the
addition of 'compat' at the libvit XML level.
>
> My patch attempts to define semantics for this second mode of execution.
>
> A VM running in compat mode will not just differ in terms of qemu command
> line, but also in behaviour when contrasted with the host native mode. In
> other words, applications running on "power7"
> native VM will see different CPU as compared to applications running on a
> compat-mode "power7" VM over a Power8 host. From a VM management perspective,
> this difference needs to be brought out in XML.
>
> Also, "compat" mode is one way of emulating an older processor chip, but it
> may not be the _only_ way.
>
> Hence the virtualization stack needs to explicitly distinguish a compat-mode
> VM.
>
> In my v2 post, you had suggested that model fallback 'compat' be based on
> "host-model" cpu mode in place of "custom". I have sent out v3 and v4 based
> on this suggestion.
>
> Hope this XML schema is acceptable:
> <cpu mode='host-model'>
> <model fallback='compat'>power7</model>
> </cpu>
The current libvirt code only allows for
<cpu mode="host-model"/>
which maps to '-cpu host'
Given this starting point, it is sufficient to just have
<cpu mode='host-model'>
<model>power7</model>
</cpu>
mapping to '-cpu host,compat=power7'
ie the very existance of a <model> against host-model is
sufficient. We don't need to invent a pointless fallback=compat
attribute too.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
