[pull] master from qemu:master#288
Merged
pull[bot] merged 229 commits intohttpsgithu:masterfrom Oct 2, 2021
Merged
Conversation
For now, it's empty! Soon, it won't be. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20210915162955.333025-2-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20210915162955.333025-3-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
'T' is a common TypeVar name, allow its use. See also pylint-dev/pylint#3401 -- In the future, we might be able to have a separate list of acceptable names for TypeVars exclusively. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20210915162955.333025-4-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
Python 3.6 does not have all of the goodies that Python 3.7 does, and we need to support both. Add some compatibility wrappers needed for this purpose. (Note: Python 3.6 is EOL December 2021.) Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20210915162955.333025-5-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
This is the bare minimum that you need to establish a full-duplex async message-based protocol with Python's asyncio. The features to be added in forthcoming commits are: - Runstate tracking - Logging - Support for incoming connections via accept() - _cb_outbound, _cb_inbound message hooks - _readline() method Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20210915162955.333025-6-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
This serves a few purposes: 1. Protect interfaces when it's not safe to call them (via @require) 2. Add an interface by which an async client can determine if the state has changed, for the purposes of connection management. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20210915162955.333025-7-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20210915162955.333025-8-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
Give the connection and the reader/writer tasks nicknames, and add logging statements throughout. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20210915162955.333025-9-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
It's a little messier than connect, because it wasn't designed to accept *precisely one* connection. Such is life. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20210915162955.333025-10-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
QMP can transmit some pretty big messages, and the default limit of 64KB isn't sufficient. Make sure that we can configure it. Reported-by: G S Niteesh Babu <niteesh.gs@gmail.com> Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20210915162955.333025-11-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
Add hooks designed to log/filter incoming/outgoing messages. The primary intent for these is to be able to support iotests which may want to log messages with specific filters for reproducible output. Another use is for plugging into Urwid frameworks; all messages in/out can be automatically added to a rendering list for the purposes of a qmp-shell like tool. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20210915162955.333025-12-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
This is added as a courtesy: many protocols are line-based, including QMP. Putting it in AsyncProtocol lets us keep the QMP class implementation just a pinch more abstract. (And, if we decide to add a QTEST implementation later, it will need this, too. (Yes, I have a QTEST implementation.)) Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20210915162955.333025-13-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
The Message class is here primarily to serve as a solid type to use for mypy static typing for unambiguous annotation and documentation. We can also stuff JSON serialization and deserialization into this class itself so it can be re-used even outside this infrastructure. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20210915162955.333025-14-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
The QMP spec doesn't define very many objects that are iron-clad in their format, but there are a few. This module makes it trivial to validate them without relying on an external third-party library. Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20210915162955.333025-15-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
This class was designed as a "mix-in" primarily so that the feature could be given its own treatment in its own python module. It gets quite a bit too long otherwise. Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20210915162955.333025-16-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
too-many-function-args seems prone to failure when considering things like Method Resolution Order, which mypy gets correct. When dealing with multiple inheritance, pylint doesn't seem to understand which method will actually get called, while mypy does. Remove the less powerful, redundant check. Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20210915162955.333025-17-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
The star of our show! Add most of the QMP protocol, sans support for actually executing commands. No problem, that happens in the next several commits. Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20210915162955.333025-18-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
mypy handles this better -- but we only need the workaround because pylint under Python 3.6 does not understand that a MutableMapping really does have a .get() method attached. We could remove this again once 3.7 is our minimum. Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20210915162955.333025-19-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
Add the ability to handle and route messages in qmp_protocol.py. The interface for actually sending anything still isn't added until next commit. Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20210915162955.333025-20-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
Add execute() and execute_msg(). _execute() is split into _issue() and _reply() halves so that hypothetical subclasses of QMP that want to support different execution paradigms can do so. I anticipate a synchronous interface may have need of separating the send/reply phases. However, I do not wish to expose that interface here and want to actively discourage it, so they remain private interfaces. Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20210915162955.333025-21-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
This is added in anticipation of wanting it for a synchronous wrapper for the iotest interface. Normally, execute() and execute_msg() both raise QMP errors in the form of Python exceptions. Many iotests expect the entire reply as-is. To reduce churn there, add a private execution interface that will ease transition churn. However, I do not wish to encourage its use, so it will remain a private interface. Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20210915162955.333025-22-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
As a convenience. It isn't used by the library itself, but it is used by the test suite. It will also come in handy for users of the library still on Python 3.6. Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20210915162955.333025-23-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
Add a warning whenever AQMP is used to steer people gently away from using it for the time-being. Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20210915162955.333025-24-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
Avocado v90 includes improved support for running async unit tests. The workaround that existed prior to v90 causes the unit tests to fail afterwards, however, so upgrade our minimum version pin to the very latest and greatest. Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20210915162955.333025-25-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
This tests most of protocol.py -- From a hacked up Coverage.py run, it's at about 86%. There's a few error cases that aren't very well tested yet, they're hard to induce artificially so far. I'm working on it. Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20210915162955.333025-26-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
Tests a real connect, a real accept, and really sending and receiving a message over a UNIX socket. Brings coverage of protocol.py up to ~93%. Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20210915162955.333025-27-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
I'm not exposing this via the Makefile help, it's not likely to be useful to passersby. Switch the avocado runner to the 'legacy' runner for now, as the new runner seems to obscure coverage reports, again. Usage is to enter your venv of choice and then: `make check-coverage && xdg-open htmlcov/index.html`. Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20210915162955.333025-28-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
Added dependencies for the upcoming AQMP TUI under the optional 'tui' group. The same dependencies have also been added under the devel group since no work around has been found for optional groups to imply other optional groups. Signed-off-by: G S Niteesh Babu <niteesh.gs@gmail.com> Message-Id: <20210823220746.28295-2-niteesh.gs@gmail.com> Signed-off-by: John Snow <jsnow@redhat.com>
Added AQMP TUI. Implements the follwing basic features: 1) Command transmission/reception. 2) Shows events asynchronously. 3) Shows server status in the bottom status bar. 4) Automatic retries on disconnects and error conditions. Also added type annotations and necessary pylint/mypy configurations. Signed-off-by: G S Niteesh Babu <niteesh.gs@gmail.com> Message-Id: <20210823220746.28295-3-niteesh.gs@gmail.com> Signed-off-by: John Snow <jsnow@redhat.com>
Add an entry point for aqmp-tui. This will allow it to be run from the command line using "aqmp-tui localhost:1234" More options available in the TUI can be found using "aqmp-tui -h" Signed-off-by: G S Niteesh Babu <niteesh.gs@gmail.com> Message-Id: <20210823220746.28295-4-niteesh.gs@gmail.com> Signed-off-by: John Snow <jsnow@redhat.com>
To pave the way for the functional improvement in later patches, make some refactor/cleanup for the smp parsers, including using local maxcpus instead of ms->smp.max_cpus in the calculation, defaulting dies to 0 initially like other members, cleanup the sanity check for dies. We actually also fix a hidden defect by avoiding directly using the provided *zero value* in the calculation, which could cause a segment fault (e.g. using dies=0 in the calculation). Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210929025816.21076-4-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
We are currently using maxcpus to calculate the omitted sockets but using cpus to calculate the omitted cores/threads. This makes cmdlines like: -smp cpus=8,maxcpus=16 -smp cpus=8,cores=4,maxcpus=16 -smp cpus=8,threads=2,maxcpus=16 work fine but the ones like: -smp cpus=8,sockets=2,maxcpus=16 -smp cpus=8,sockets=2,cores=4,maxcpus=16 -smp cpus=8,sockets=2,threads=2,maxcpus=16 break the sanity check. Since we require for a valid config that the product of "sockets * cores * threads" should equal to the maxcpus, we should uniformly use maxcpus to calculate their omitted values. Also the if-branch of "cpus == 0 || sockets == 0" was split into two branches of "cpus == 0" and "sockets == 0" so that we can clearly read that we are parsing the configuration with a preference on cpus over sockets over cores over threads. Note: change in this patch won't affect any existing working cmdlines but improves consistency and allows more incomplete configs to be valid. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210929025816.21076-5-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Currently we directly calculate the omitted cpus based on the given incomplete collection of parameters. This makes some cmdlines like: -smp maxcpus=16 -smp sockets=2,maxcpus=16 -smp sockets=2,dies=2,maxcpus=16 -smp sockets=2,cores=4,maxcpus=16 not work. We should probably set the value of cpus to match maxcpus if it's omitted, which will make above configs start to work. So the calculation logic of cpus/maxcpus after this patch will be: When both maxcpus and cpus are omitted, maxcpus will be calculated from the given parameters and cpus will be set equal to maxcpus. When only one of maxcpus and cpus is given then the omitted one will be set to its counterpart's value. Both maxcpus and cpus may be specified, but maxcpus must be equal to or greater than cpus. Note: change in this patch won't affect any existing working cmdlines but allows more incomplete configs to be valid. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210929025816.21076-6-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
We have two requirements for a valid SMP configuration: the product of "sockets * cores * threads" must represent all the possible cpus, i.e., max_cpus, and then must include the initially present cpus, i.e., smp_cpus. So we only need to ensure 1) "sockets * cores * threads == maxcpus" at first and then ensure 2) "maxcpus >= cpus". With a reasonable order of the sanity check, we can simplify the error reporting code. When reporting an error message we also report the exact value of each topology member to make users easily see what's going on. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210929025816.21076-7-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Since commit 80d7835 (qemu-options: rewrite help for -smp options), the preference of sockets/cores in -smp parsing is considered liable to change, and actually we are going to change it in a coming commit. So it'll be more stable to use detailed -smp CLIs in testing if we have strong dependency on the parsing results. pc_dynamic_cpu_cfg currently assumes/needs that there will be 2 CPU sockets with "-smp 2". To avoid breaking the test because of parsing logic change, now explicitly use "-smp 2,sockets=2". Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210929025816.21076-8-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Since commit 80d7835 (qemu-options: rewrite help for -smp options), the preference of sockets/cores in -smp parsing is considered liable to change, and actually we are going to change it in a coming commit. So it'll be more stable to use detailed -smp CLIs in the testcases that have strong dependency on the parsing results. Currently, test_def_cpu_split use "-smp 8" and will get 8 CPU sockets based on current parsing rule. But if we change to prefer cores over sockets we will get one CPU socket with 8 cores, and this testcase will not get expected numa set by default on x86_64 (Ok on aarch64). So now explicitly use "-smp 8,sockets=8" to avoid affect from parsing logic change. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210929025816.21076-9-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
In the real SMP hardware topology world, it's much more likely that we have high cores-per-socket counts and few sockets totally. While the current preference of sockets over cores in smp parsing results in a virtual cpu topology with low cores-per-sockets counts and a large number of sockets, which is just contrary to the real world. Given that it is better to make the virtual cpu topology be more reflective of the real world and also for the sake of compatibility, we start to prefer cores over sockets over threads in smp parsing since machine type 6.2 for different arches. In this patch, a boolean "smp_prefer_sockets" is added, and we only enable the old preference on older machines and enable the new one since type 6.2 for all arches by using the machine compat mechanism. Suggested-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210929025816.21076-10-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
In the sanity-check of smp_cpus and max_cpus against mc in function machine_set_smp(), we are now using ms->smp.max_cpus for the check but using current_machine->smp.max_cpus in the error message. Tweak this by uniformly using the local ms. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210929025816.21076-11-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Now that all the possible topology parameters are integrated in struct CpuTopology, tweak the order of topology members to be "cpus/sockets/ dies/cores/threads/maxcpus" for readability and consistency. We also tweak the comment by adding explanation of dies parameter. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210929025816.21076-12-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Currently the only difference between smp_parse and pc_smp_parse is the support of dies parameter and the related error reporting. With some arch compat variables like "bool dies_supported", we can make smp_parse generic enough for all arches and the PC specific one can be removed. Making smp_parse() generic enough can reduce code duplication and ease the code maintenance, and also allows extending the topology with more arch specific members (e.g., clusters) in the future. Suggested-by: Andrew Jones <drjones@redhat.com> Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210929025816.21076-13-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Now we have a generic smp parser for all arches, and there will not be any other arch specific ones, so let's remove the callback from MachineClass and call the parser directly. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210929025816.21076-14-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Now we have a common structure SMPCompatProps used to store information about SMP compatibility stuff, so we can also move smp_prefer_sockets there for cleaner code. No functional change intended. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210929025816.21076-15-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Put both sanity-check of the input SMP configuration and sanity-check of the output SMP configuration uniformly in the generic parser. Then machine_set_smp() will become cleaner, also all the invalid scenarios can be tested only by calling the parser. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210929025816.21076-16-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
By default, KVM allows the guest to use all currently supported PV features even when they were not announced in guest visible CPUIDs. Introduce a new "kvm-pv-enforce-cpuid" flag to limit the supported feature set to the exposed features. The feature is supported by Linux >= 5.10 and is not enabled by default in QEMU. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20210902093530.345756-4-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
By default, KVM allows the guest to use all currently supported Hyper-V enlightenments when Hyper-V CPUID interface was exposed, regardless of if some features were not announced in guest visible CPUIDs. hv-enforce-cpuid feature alters this behavior and only allows the guest to use exposed Hyper-V enlightenments. The feature is supported by Linux >= 5.14 and is not enabled by default in QEMU. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20210902093530.345756-5-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
…ds() In preparation to enabling Hyper-V + APICv/AVIC move HV_APIC_ACCESS_RECOMMENDED setting out of kvm_hyperv_properties[]: the 'real' feature bit for the vAPIC features is HV_APIC_ACCESS_AVAILABLE, HV_APIC_ACCESS_RECOMMENDED is a recommendation to use the feature which we may not always want to give. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20210902093530.345756-6-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The enlightenment allows to use Hyper-V SynIC with hardware APICv/AVIC enabled. Normally, Hyper-V SynIC disables these hardware features and suggests the guest to use paravirtualized AutoEOI feature. Linux-4.15 gains support for conditional APICv/AVIC disablement, the feature stays on until the guest tries to use AutoEOI feature with SynIC. With 'HV_DEPRECATING_AEOI_RECOMMENDED' bit exposed, modern enough Windows/ Hyper-V versions should follow the recommendation and not use the (unwanted) feature. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20210902093530.345756-7-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Currently, we hardcode Hyper-V version id (CPUID 0x40000002) to
WS2008R2 and it is known that certain tools in Windows check this. It
seems useful to provide some flexibility by making it possible to change
this info at will. CPUID information is defined in TLFS as:
EAX: Build Number
EBX Bits 31-16: Major Version
Bits 15-0: Minor Version
ECX Service Pack
EDX Bits 31-24: Service Branch
Bits 23-0: Service Number
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20210902093530.345756-8-vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
KVM implements some Hyper-V 2016 functions so providing WS2008R2 version is somewhat incorrect. While generally guests shouldn't care about it and always check feature bits, it is known that some tools in Windows actually check version info. For compatibility reasons make the change for 6.2 machine types only. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20210902093530.345756-9-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Make all documents start with a heading. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Clean up the heading levels to use === --- ~~~, and move the command line building near to the other execution steps. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Clean up the heading levels to use === --- ~~~, and create a new "writing plugins" section. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
gcov testing applies to all tests, not just make check. Move it out of the make check section. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Clean up the heading levels to use === --- ~~~ ^^^ '''. Reorganize the outline for the Avocado part, and always include headings for the class names. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
… staging
* -smp cleanpus
* Hyper-V englightenment functionality
* Documentation cleanups
# gpg: Signature made Fri 01 Oct 2021 01:11:00 PM EDT
# gpg: using RSA key F13338574B662389866C7682BFFBD25F78C7AE83
# gpg: issuer "pbonzini@redhat.com"
# gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full]
# gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full]
* remotes/bonzini/tags/for-upstream: (29 commits)
docs: reorganize testing.rst
docs: move gcov section at the end of testing.rst
docs: reorganize tcg-plugins.rst
docs: reorganize qgraph.rst
docs: put "make" information together in build-system.rst
docs: move notes inside the body of the document
docs: name included files ".rst.inc"
i386: Change the default Hyper-V version to match WS2016
i386: Make Hyper-V version id configurable
i386: Implement pseudo 'hv-avic' ('hv-apicv') enlightenment
i386: Move HV_APIC_ACCESS_RECOMMENDED bit setting to hyperv_fill_cpuids()
i386: Support KVM_CAP_HYPERV_ENFORCE_CPUID
i386: Support KVM_CAP_ENFORCE_PV_FEATURE_CPUID
machine: Put all sanity-check in the generic SMP parser
machine: Use g_autoptr in machine_set_smp
machine: Move smp_prefer_sockets to struct SMPCompatProps
machine: Remove smp_parse callback from MachineClass
machine: Make smp_parse generic enough for all arches
machine: Tweak the order of topology members in struct CpuTopology
machine: Use ms instead of global current_machine in sanity-check
...
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )