- 11 8月, 2015 22 次提交
-
-
由 Andrea Bolognani 提交于
Now that all the changes have been implemented we can run the test cases once again, after updating them to reflect the new behaviour.
-
由 Andrea Bolognani 提交于
Unlike what happens on x86, on ppc64 you can't mix and match CPU features to obtain the guest CPU you want regardless of the host CPU, so the concept of model fallback doesn't apply. Make sure CPU definitions emitted by the driver, eg. as output of the cpuBaseline() and cpuUpdate() calls, reflect this fact.
-
由 Andrea Bolognani 提交于
All previously recognized CPU models (POWER7_v2.1, POWER7_v2.3, POWER7+_v2.1 and POWER8_v1.0) are internally converted to the corrisponding generation name so that existing guests don't stop working.
-
由 Andrea Bolognani 提交于
This is yet another variation of POWER8. The PVR information comes from arch/powerpc/kernel/cputable.c in the Linux kernel tree.
-
由 Andrea Bolognani 提交于
Instead of relying on a hard-coded mask value, read it from the CPU map XML and use it when looking up models by PVR.
-
由 Andrea Bolognani 提交于
Use multiple PVRs per CPU model to reduce the number of models we need to keep track of. Remove specific CPU models (eg. POWER7+_v2.1): the corresponding generic CPU model (eg. POWER7) should be used instead to ensure the guest can be booted on any compatible host. Get rid of all the entries that did not match any of the CPU models supported by QEMU, like power8 and power8e. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1250977
-
由 Andrea Bolognani 提交于
This will allow us to perform PVR matching more broadly, eg. consider both POWER8 and POWER8E CPUs to be the same even though they have different PVR values.
-
由 Andrea Bolognani 提交于
Use a typedef instead of the plain struct and heap allocation. This will make it easier to extend the ppc64 specific CPU data later on.
-
由 Andrea Bolognani 提交于
The upcoming commits will make heavy modifications to the ppc64 driver, split so that it's easier to review the changes. Instead of updating the test cases so that they pass, possibly only to update them again with the following commit, disable them for the time being. Another commit will update them all in one go once all required changes are in place.
-
由 Andrea Bolognani 提交于
This ensures comparison of two CPU definitions will be consistent regardless of the fact that it is performed using cpuCompare() or cpuGuestData(). The x86 driver uses the same exact code.
-
由 Andrea Bolognani 提交于
Limitations of the POWER architecture mean that you can't run eg. a POWER7 guest on a POWER8 host when using KVM. This applies to all guests, not just those using VIR_CPU_MATCH_STRICT in the CPU definition; in fact, exact and strict CPU matching are basically the same on ppc64. This means, of course, that hosts using different CPUs have to be considered incompatible as well. Change ppc64Compute(), called by cpuGuestData(), to reflect this fact and update test cases accordingly. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1250977
-
由 Andrea Bolognani 提交于
ppc64Compute(), called by cpuNodeData(), is used not only to retrieve the driver-specific data associated to a guest CPU definition, but also to check whether said guest CPU is compatible with the host CPU. If the user is not interested in the CPU data, it's perfectly fine to pass a NULL pointer instead of a return location, and the compatibility data returned should not be affected by this. One of the checks, specifically the one on CPU model name, was however only performed if the return location was non-NULL.
-
由 Andrea Bolognani 提交于
A test is considered successful if the obtained result matches the expected result: if that's not the case, whether because a test that was expected to succeed failed or because a test that was supposed to fail succeeded, then something's not right and we want the user to know about this. On the other hand, if a failure that's unrelated to the bits we're testing occurs, then the user should be notified even if the test was expected to fail. Use different values to tell these two situations apart. Fix a test case that was wrongly expected to fail as well.
-
由 Andrea Bolognani 提交于
No functional changes.
-
由 Andrea Bolognani 提交于
The information is not used anywhere in libvirt. No functional changes.
-
由 Andrea Bolognani 提交于
Having the functions grouped together this way will avoid further shuffling around down the line. No functional changes.
-
由 Andrea Bolognani 提交于
-
由 Andrea Bolognani 提交于
Use briefer checks, eg. (!model) instead of (model == NULL), and avoid initializing to NULL a pointer that would be assigned in the first line of the function anyway. Also remove a pointless NULL assignment. No functional changes.
-
由 Andrea Bolognani 提交于
Use the ppc64Driver prefix for all functions that are used to fill in the cpuDriverPPC64 structure, ie. those that are going to be called by the generic CPU code. This makes it clear which functions are exported and which are implementation details; it also gets rid of the ambiguity that affected the ppc64DataFree() function which, despite what the name suggested, was not related to ppc64DataCopy() and could not be used to release the memory allocated for a virCPUppc64Data* instance. No functional changes.
-
由 Erik Skultety 提交于
This is a public library, it shouldn't include anything that is internal. Including the library in it's current state to an example application fails the preprocessor phase.
-
由 Laine Stump 提交于
nwfilter uses iptables and ebtables, which only work properly on tap-based network connections (*not* on macvtap, for example), but we just ignore any <filterref> elements for other types of networks, potentially giving users a false sense of security. This patch checks the network type and fails/logs an error if any domain <interface> has a <filterref> when the connection isn't using a tap device. This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1180011
-
由 Laine Stump 提交于
This patch modifies virSocketAddrGetRange() to function properly when the containing network/prefix of the address range isn't known, for example in the case of the NAT range of a virtual network (since it is a range of addresses on the *host*, not within the network itself). We then take advantage of this new functionality to validate the NAT range of a virtual network. Extra test cases are also added to verify that virSocketAddrGetRange() works properly in both positive and negative cases when the network pointer is NULL. This is the *real* fix for: https://bugzilla.redhat.com/show_bug.cgi?id=985653 Commits 1e334a and 48e8b9 had earlier been pushed as fixes for that bug, but I had neglected to read the report carefully, so instead of fixing validation for the NAT range, I had fixed validation for the DHCP range. sigh.
-
- 10 8月, 2015 18 次提交
-
-
由 Martin Kletzander 提交于
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1150484Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
This will be used with a virtio-scsi controller later on. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1022292 The following XML really does not make any sense: <inbound average="-1" burst="-2" peak="-3" floor="-4"/> There can't be a negative packet rate. Well, so far we haven't assigned any meaning to it. So reject it unless users harm themselves, because otherwise we turn the negative numbers into really big values. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Cao jin 提交于
There's no need to set mon->fd to a dummy value since it's initialized to proper value just a few lines below. Signed-off-by: NCao jin <caoj.fnst@cn.fujitsu.com>
-
由 Martin Kletzander 提交于
Since its introduction in 2011 (particularly in commit f4324e32), the option doesn't work. It just effectively disables all incoming connections. That's because the client private data that contain the 'keepalive_supported' boolean, are initialized to zeroes so the bool is false and the only other place where the bool is used is when checking whether the client supports keepalive. Thus, according to the server, no client supports keepalive. Removing this instead of fixing it is better because a) apparently nobody ever tried it since 2011 (4 years without one month) and b) we cannot know whether the client supports keepalive until we get a ping or pong keepalive packet. And that won't happen until after we dispatched the ConnectOpen call. Another two reasons would be c) the keepalive_required was tracked on the server level, but keepalive_supported was in private data of the client as well as the check that was made in the remote layer, thus making all other instances of virNetServer miss this feature unless they all implemented it for themselves and d) we can always add it back in case there is a request and a use-case for it. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Cao jin 提交于
Signed-off-by: NCao jin <caoj.fnst@cn.fujitsu.com>
-
由 Michal Privoznik 提交于
So the API takes @dumpformat argument. This is what makes it special when compared to virDomainCoreDump. The argument is there so that users can choose the format of resulting core dump file. And to ease them the choosing process we even have an enum with supported values across all the hypervisors. But we don't mention the enum in the function description anywhere. Fix it! Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Laine Stump 提交于
By specifying parentIndex in a call to virNetworkUpdate(), it was possible to direct libvirt to add a dhcp range or static host of a non-matching address family to the <dhcp> element of an <ip>. For example, given: <ip address='192.168.122.1' netmask='255.255.255.0'/> <ip family='ipv6' address='2001:db6:ca3:45::1' prefix='64'/> you could provide a static host entry with an IPv4 address, and specify that it be added to the 2nd <ip> element (index 1): virsh net-update default add ip-dhcp-host --parent-index 1 \ '<host mac="52:54:00:00:00:01" ip="192.168.122.45"/>' This would be happily added with no error (and no concern of any possible future consequences). This patch checks that any dhcp range or host element being added to a network ip's <dhcp> subelement has addresses of the same family as the ip element they are being added to. This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1184736
-
由 Laine Stump 提交于
This is backed by the qemu device xio3130-downstream. It can only be connected to a pcie-switch-upstream-port (x3130-upstream) on the upstream side.
-
由 Laine Stump 提交于
This controller can be connected only to a port on a pcie-switch-upstream-port. It provides a single hotpluggable port that will accept any PCI or PCIe device, as well as any device requiring a pcie-*-port (the only current example of such a device is the pcie-switch-upstream-port).
-
由 Laine Stump 提交于
The downstream ports of an x3130-upstream switch can each have one of these plugged into them (and that is the only place they can be connected). Each xio3130-downstream provides a single PCIe port that can have PCI or PCIe devices hotplugged into it. Apparently an entire set of x3130-upstream + several xio3130-downstreams can be hotplugged as a unit, but it's not clear to me yet how that would be done, since qemu only allows attaching a single device at a time. This device will be used to implement the "pcie-switch-downstream-port" model of pci controller.
-
由 Laine Stump 提交于
this is backed by the qemu device x3130-upstream. It can only plug into a pcie-root-port or pcie-switch-downstream-port.
-
由 Laine Stump 提交于
This controller can be connected only to a pcie-root-port or a pcie-switch-downstream-port (which will be added in a later patch), which is the reason for the new connect type VIR_PCI_CONNECT_TYPE_PCIE_PORT. A pcie-switch-upstream-port provides 32 ports (slot=0 to slot=31) on the downstream side, which can only have pci controllers of model "pcie-switch-downstream-port" plugged into them, which is the reason for the other new connect type VIR_PCI_CONNECT_TYPE_PCIE_SWITCH.
-
由 Laine Stump 提交于
This is the upstream part of a PCIe switch. It connects to a PCIe port (but not PCI) on the upstream side, and can have up to 31 xio3130-downstream controllers (but no other types of devices) connected to its downstream side. This device will be used to implement the "pcie-switch-upstream-port" model of pci controller.
-
由 Laine Stump 提交于
This is backed by the qemu device ioh3420. chassis and port from the <target> subelement are used to store/set the respective qemu device options for the ioh3420. Currently, chassis is set to be the index of the controller, and port is set to "(slot << 3) + function" (per suggestion from Alex Williamson).
-
由 Laine Stump 提交于
This controller can be connected (at domain startup time only - not hotpluggable) only to a port on the pcie root complex ("pcie-root" in libvirt config), hence the new connect type VIR_PCI_CONNECT_TYPE_PCIE_ROOT. It provides a hotpluggable port that will accept any PCI or PCIe device. New attributes must be added to the controller <target> subelement for this - chassis and port are guest-visible option values that will be set by libvirt with values derived from the controller's index and pci address information.
-
由 Laine Stump 提交于
This is a PCIE "root port". It connects only to a port of the integrated pcie.0 bus of a Q35 machine (can't be hotplugged), and provides a single PCIe port that can have PCI or PCIe devices hotplugged into it. This device will be used to implement the "pcie-root-port" model of pci controller.
-
由 Laine Stump 提交于
This uses the new subelement/attribute in two ways: 1) If a "pci-bridge" pci controller has no chassisNr attribute, it will automatically be set to the controller's index as soon as the controller's PCI address is known (during qemuDomainAssignPCIAddresses()). 2) when creating the commandline for a pci-bridge device, chassisNr will be used to set qemu's chassis_nr option (rather than the previous practice of hard-coding it to the controller's index).
-