- 18 3月, 2019 4 次提交
-
-
由 Cole Robinson 提交于
Set report=true for all enums currently formatted in the XML Acked-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NCole Robinson <crobinso@redhat.com>
-
由 Cole Robinson 提交于
Only gic->supported needs an explicit BOOL_NO setting, all other 'supported' values are handling things correctly Acked-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NCole Robinson <crobinso@redhat.com>
-
由 Cole Robinson 提交于
Switch most 'supported' handling to use virTristateBool, so eventually we can handle the ABSENT state. For now the XML formatter treats ABSENT the same as FALSE, so there's no functional output change. This will be addressed in later patches Acked-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NCole Robinson <crobinso@redhat.com>
-
由 Cole Robinson 提交于
This code originates from: commit d0aa10fd Author: Daniel P. Berrange <berrange@redhat.com> Date: Tue Mar 3 12:03:44 2009 +0000 QEMU security driver usage for sVirt support (James Morris, Dan Walsh, Daniel Berrange) Originally in the qemudDomainGetSecurityLabel function. It doesn't appear to have done anything useful back then either. The other two instances look like copy+paste Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NCole Robinson <crobinso@redhat.com>
-
- 16 3月, 2019 1 次提交
-
-
由 Eric Blake 提交于
snapshot_conf.h was mixing three separate types: the snapshot definition, the snapshot object, and the snapshot object list. Separate out the snapshot object list code into its own file, and update includes for affected clients. This is just code motion, but done in preparation of sharing a lot of the object list code with checkpoints. Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 15 3月, 2019 10 次提交
-
-
由 Erik Skultety 提交于
By default, qemu user's home dir points to '/' which shouldn't be used at all. We therefore pass the HOME variable from the current variable iff not running as SUID, which means that for systemd we never set it. This patch makes sure, that for system QEMU this is always set to libDir/<driver>, session mode is left untouched. Signed-off-by: NErik Skultety <eskultet@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Erik Skultety 提交于
For session mode, only XDG_CACHE_HOME is set, because we want to remain integrating with services in user session, but for system mode, this would have become reading/writing to '/' which carries the obvious issue with permissions (also, '/' is the wrong location in 99.9% cases anyway). Signed-off-by: NErik Skultety <eskultet@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Peter Krempa 提交于
The functions do basically exactly the same thing modulo few checks. In case of virtio disks we check that the device is not multifunction as that can't be unplugged at once. In case of USB and SCSI disks we checked that no active block job is running. The check for running blockjobs should have also been done for virtio disks. By moving the multifunction check into the common function we fix this case and also simplify the code. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Use the correct type in switch and populate the missing cases. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
We don't have any cleanup section, we can return the value directly. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1623389 If a device is detached twice from the same domain the following race condition may happen: 1) The first DetachDevice() call will issue "device_del" on qemu monitor, but since the DEVICE_DELETED event did not arrive in time, the API ends claiming "Device detach request sent successfully". 2) The second DetachDevice() therefore still find the device in the domain and thus proceeds to detaching it again. It calls EnterMonitor() and qemuMonitorSend() trying to issue "device_del" command again. This gets both domain lock and monitor lock released. 3) At this point, qemu sends us the DEVICE_DELETED event which is going to be handled by the event loop which ends up calling qemuDomainSignalDeviceRemoval() to determine who is going to remove the device from domain definition. Whether it is the caller that marked the device for removal or whether it is going to be the event processing thread. 4) Because the device was marked for removal, qemuDomainSignalDeviceRemoval() returns true, which means the event is to be processed by the thread that has marked the device for removal (and is currently still trying to issue "device_del" command) 5) The thread finally issues the "device_del" command, which fails (obviously) and therefore it calls qemuDomainResetDeviceRemoval() to reset the device marking and quits immediately after, NOT removing any device from the domain definition. At this point, the device is still present in the domain definition but doesn't exist in qemu anymore. Worse, there is no way to remove it from the domain definition. Solution is to note down that we've seen the event and if the second "device_del" fails, not take it as a failure but carry on with the usual execution. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> ACKed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Michal Privoznik 提交于
A caller might be interested in differentiating the cause for error, especially if DeviceNotFound error occurred. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> ACKed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Michal Privoznik 提交于
The aim of this function will be to fix return value of qemuMonitorDelDevice() in one specific case. But that is yet to come. Right now this is nothing but a plain substitution. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> ACKed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Jiri Denemark 提交于
Any job which is able to provide statistics that can be queried via virDomainGetJob{Stats,Info} has to set an appropriate statsType. Without a proper statsType qemuDomainJobInfoToParams and qemuDomainJobInfoToInfo have no idea what statistics should be sent to the API caller. https://bugzilla.redhat.com/show_bug.cgi?id=1688774Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
- 14 3月, 2019 2 次提交
-
-
由 Eric Blake 提交于
Use VIR_AUTOFREE and saner formatting. No semantic change. Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Jim Fehlig 提交于
xenbus is virtual controller (akin to virtio controllers) for Xen paravirtual devices. Although all Xen VMs have a xenbus, it has never been modeled in libvirt, or in Xen native VM config format for that matter. Recently there have been requests to support Xen's max_grant_frames setting in libvirt. max_grant_frames is best modeled as an attribute of xenbus. It describes the maximum IO buffer space (or DMA space) available in xenbus for use by connected paravirtual devices. This patch introduces a new xenbus controller type that includes a maxGrantFrames attribute. Signed-off-by: NJim Fehlig <jfehlig@suse.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 13 3月, 2019 3 次提交
-
-
由 Michal Privoznik 提交于
Luckily, the function returns only 0 or -1 so all the checks work as expected. Anyway, our rule is that a positive value means success so if the function ever returns a positive value these checks will fail. Make them check for a negative value properly. At the same time fix qemuDomainDetachExtensionDevice() reval check. It is somewhat related to the aim of this patch. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
The qemuFirmwareFetchConfigs() function is supposed to fetch all firmware descriptions from paths defined by firmware.json specification. This includes user's $HOME directory. However, it was agreed that if libvirtd is running as privileged user then his $HOME is ignored (thus $HOME is included in the search only for regular users). Well, I got the condition wrong - it should have been reversed. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Eric Blake 提交于
snapshot_conf does all the hard work, the qemu driver just has to accept the new flag. Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 12 3月, 2019 9 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1564270 Now that everything is prepared for qemu driver we can enable parser feature to allow users define such domains. At the same time, introduce bunch of tests to test the feature. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Michal Privoznik 提交于
The firmware selection code will enable the feature if needed. There's no need to require SMM to be enabled in that case. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com> Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
-
由 Michal Privoznik 提交于
When preparing domain call qemuFirmwareFillDomain() to fill in desired firmware. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
And finally the last missing piece. This is what puts it all together. At the beginning, qemuFirmwareFillDomain() loads all possible firmware description files based on algorithm described earlier. Then it tries to find description which matches given domain. The criteria are: - firmware is the right type (e.g. it's bios when bios was requested in domain XML) - firmware is suitable for guest architecture/machine type - firmware allows desired guest features to stay enabled (e.g. if s3/s4 is enabled for guest then firmware has to support it too) Once the desired description has been found it is then used to set various bits of virDomainDef so that proper qemu cmd line is constructed as demanded by the description file. For instance, secure boot enabled firmware might request SMM -> it will be enabled if needed. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
-
由 Michal Privoznik 提交于
Implementation for yet another part of firmware description specification. This one covers selecting which files to parse. There are three locations from which description files can be loaded. In order of preference, from most generic to most specific these are: /usr/share/qemu/firmware /etc/qemu/firmware $XDG_CONFIG_HOME/qemu/firmware If a file is found in two or more locations then the most specific one is used. Moreover, if file is empty then it means it is overriding some generic description and disabling it. Again, this is described in more details and with nice examples in firmware.json specification (qemu commit 3a0adfc9bf). However, there's one slight difference - for the root user the home directory is not searched. This follows rules laid out by similar look up processes, e.g. PKI x509 certs are not searched in /root but they are looked for under /home. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
-
由 Michal Privoznik 提交于
The firmware description is a JSON file which follows specification from qemu.git/docs/interop/firmware.json. The description file basically says: Firmware file X is {bios|uefi}, supports these targets and machine types, requires these features to be enabled on qemu cmd line and this is how you put it onto qemu cmd line. The firmware.json specification covers more (i.e. how to select the right firmware) but that will be covered and implemented in next commits. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Michal Privoznik 提交于
This is going to extend virDomainLoader enum. The reason is that once loader path is NULL its type makes no sense. However, since value of zero corresponds to VIR_DOMAIN_LOADER_TYPE_ROM the following XML would be produced: <os> <loader type='rom'/> ... </os> To solve this, introduce VIR_DOMAIN_LOADER_TYPE_NONE which would correspond to value of zero and then use post parse callback to set the default loader type to 'rom' if needed. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NLaszlo Ersek <lersek@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Michal Privoznik 提交于
In some cases, the string representing architecture is different in qemu and libvirt. That is the reason why we have virQEMUCapsArchFromString() and virQEMUCapsArchToString(). So far, we did not need them outside of qemu_capabilities code, but this will change shortly. Expose them then. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NLaszlo Ersek <lersek@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Michal Privoznik 提交于
Move the code that (possibly) generates filename of NVRAM VAR store into a single function so that it can be re-used later. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NLaszlo Ersek <lersek@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 11 3月, 2019 2 次提交
-
-
由 Andrea Bolognani 提交于
The existing behavior for ppc64 guests is to always add a USB keyboard and mouse combo if graphics are present; unfortunately, this means any attempt to use a USB tablet will cause both pointing devices to show up in the guest, which in turn will result in poor user experience. We can't just stop adding the USB mouse or start adding a USB tablet instead, because existing applications and users might rely on the current behavior; however, we can avoid adding the USB mouse if a USB tablet is already present, thus allowing users and applications to create guests that contain a single pointing device. https://bugzilla.redhat.com/show_bug.cgi?id=1683681Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
由 Andrea Bolognani 提交于
While the parser and schema have to accept all possible models, virtio-(non-)transitional models are only applicable to type=passthrough and should be otherwise rejected. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
- 08 3月, 2019 6 次提交
-
-
由 Eric Blake 提交于
Right now, the only callers of qemuDomainSnapshotDiscardAllMetadata() are right before freeing the virDomainSnapshotObjList, so it did not matter if the list's metaroot (which points to all the defined root snapshots) is left inconsistent. But an upcoming patch will want to clear all snapshots if a bulk redefine fails partway through, in which case things must be reset. Make this work by teaching the existing virDomainSnapshotUpdateRelations() to be safe regardless of the incoming state of the metaroot (since we don't want to leak that internal detail into qemu code), then fixing the qemu code to use it after deleting all snapshots. Additionally, the qemu code must reset vm->current_snapshot if the current snapshot was removed, regardless of whether the overall removal succeeded or failed later. Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Eric Blake 提交于
virDomainSnapshotDefFormat currently takes two sets of knobs: an 'unsigned int flags' argument that can currently just be VIR_DOMAIN_DEF_FORMAT_SECURE, and an 'int internal' argument used as a bool to determine whether to output an additional element. It then reuses the 'flags' knob to call into virDomainDefFormatInternal(), which takes a different set of flags. In fact, prior to commit 0ecd6851 (1.2.12), the 'flags' argument actually took the public VIR_DOMAIN_XML_SECURE, which was even more confusing. Let's borrow from the style of that earlier commit, by introducing a function for translating from the public flags (VIR_DOMAIN_SNAPSHOT_XML_SECURE was just recently introduced) into a new enum specific to snapshot formatting, and adjust all callers to use snapshot-specific enum values when formatting, and where the formatter now uses a new variable 'domainflags' to make it obvious when we are translating from snapshot flags back to domain flags. We don't even have to use the conversion function for drivers that don't accept the public VIR_DOMAIN_SNAPSHOT_XML_SECURE flag. Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Eric Blake 提交于
Clean up the previous patch which abused switch on virDomainState while working with a variable containing virDomainSnapshotState, by converting the two affected switch statements to now use the right enum. Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Eric Blake 提交于
The existing virDomainSnapshotState is a superset of virDomainState, adding one more state (disk-snapshot) on top of valid domain states. But as written, the enum cannot be used for gcc validation that all enum values are covered in a strongly-typed switch condition, because the enum does not explicitly include the values it is adding to. Copy the style used in qemu_blockjob.h of creating new enum names for every inherited value, and update most clients to use the new enum names anywhere snapshot state is referenced. The exception is two switch statements in qemu code, which instead gain a fixme comment about odd type usage (which will be cleaned up in the next patch). The rest of the patch is fairly mechanical (I actually did it by temporarily s/state/xstate/ in snapshot_conf.h to let the compiler find which spots in the code used the field, did the obvious search and replace in those functions, then undid the rename). Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Eric Blake 提交于
qemuDomainSnapshotWriteMetadata does not modify the directory name, and making it const-correct aids in writing an upcoming patch. Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Eric Blake 提交于
The current qemu code rejects the combination of the two flags VIR_DOMAIN_SNAPSHOT_CREATE_LIVE in tandem with VIR_DOMAIN_SNAPSHOT_CREATE_REDEFINE, but rather late in the cycle (after the snapshot was already parsed), and with a rather confusing message (complaining that live snapshots require external storage, even if the redefined snapshot already declares external storage). Hoist the rejection message to occur earlier (before parsing any XML, which also aids upcoming patches that will implement bulk redefine), and with a more typical error message about mutually exclusive flags. Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 07 3月, 2019 3 次提交
-
-
由 Viktor Mihajlovski 提交于
Since qemu 2.13 reports the target architecture in a property called 'target' additionally to the property 'arch', that has been used in qemu 2.12 in the response data of 'query-cpus-fast'. Libvirts monitor code prefers the 'target' property over 'arch'. At least for s390(x), target is reported as 's390x' while arch is 's390'. In a later step a comparison is performed against 's390' which fails for qemu 2.13 and later. In consequence the architecture specific data for s390 won't be extracted from the returned data, leading to incorrect values being reported by virsh domstats --vcpu. Changing to check explicitly for 's390' and 's390x'. Signed-off-by: NViktor Mihajlovski <mihajlov@linux.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
-
由 Daniel Henrique Barboza 提交于
There is a lot of documentation in the comments about how PPC64 handles passthrough VFIO devices to calculate the @memLockLimit. And more will be added with the PPC64 NVLink2 support code. Let's remove the PPC64 code from qemuDomainGetMemLockLimitBytes() body and put it into a helper function. This will simplify the flow of qemuDomainGetMemLockLimitBytes() that handles all the other platforms and improves readability of the PPC64 specifics. Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Daniel Henrique Barboza 提交于
@passthroughLimit is being calculated even if @usesVFIO is false. After that, an if-else conditional is used to check if we're going to sum it up with @baseLimit. This patch initializes @passthroughLimit to zero and always returns @memKB = @baseLimit + @passthroughLimit. The conditional is then used to calculate @passthroughLimit if @usesVFIO == true. This results in some cycles being spared for the @usesVFIO == false scenario, but the real motivation is to make the code simpler to add an alternative formula to calculate @passthroughLimit for NVLink2. Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-