On Sun, 2015-05-10 at 17:50 -0400, Cole Robinson wrote:
devicespanic is about a specific device though, which qemu ppc doesn't
support. Even if the firmware provides the logical feature (getting PANICKED
notifications from qemu), it doesn't support the device or any explicit qemu
CLI config,
On 14.05.2015 21:38, Laine Stump wrote:
The kernel won't complain if you set the mac address and vlan tag for
an SRIOV VF via its PF, and it will even let you assign the PF to a
guest using PCI device assignment or macvtap passthrough. But if the
PF isn't online, the device won't be usable in
The guest firmware provides the same functionality as the pvpanic
device, which is not available in QEMU on pSeries: make sure the
XML reflects this fact by automatically adding a panic/ element
when not already present.
On the other hand, unlike the pvpanic device, the guest firmware
can't be
On Thu, May 14, 2015 at 17:55:22 +0200, Michal Privoznik wrote:
On 13.05.2015 14:28, Jiri Denemark wrote:
Version 2:
- move QEMU-only data from virDomainDiskDef to a private data object
Jiri Denemark (5):
Add privateData to virDomainDiskDef
Rename virDomainHasBlockjob as
When we change system clock to years ago, a certain CPU may use up 100% cputime.
The reason is that in function virEventPollCalculateTimeout(), we assign the
unsigned long long result to an INT variable,
*timeout = then - now; // timeout is INT, and then/now are long long
if
On Fri, May 15, 2015 at 01:09:09PM +0200, Michal Privoznik wrote:
On 15.05.2015 08:26, zhang bo wrote:
When we change system clock to years ago, a certain CPU may use up 100%
cputime.
The reason is that in function virEventPollCalculateTimeout(), we assign
the
unsigned long long
On 15.05.2015 08:26, zhang bo wrote:
When we change system clock to years ago, a certain CPU may use up 100%
cputime.
The reason is that in function virEventPollCalculateTimeout(), we assign the
unsigned long long result to an INT variable,
*timeout = then - now; // timeout is INT,
Replace more than 30 ad-hoc error messages with a single, generic one
that contains the name of the option being processed and some hints
to help the user understand what could have gone wrong.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1207043
---
tests/vcpupin| 4
The option didn't have VSH_OT_INT type even thought it's expected
to be numeric, as shown by the fact that vshCommandOptInt() is later
used to retrieve its value.
---
tools/virsh-domain-monitor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/virsh-domain-monitor.c
The first commit improves error messages by making them much more
consistent and a little bit more helpful to the user.
The other two commits contain smaller fixes and enhancement.
Andrea Bolognani (3):
virsh: Improve error message on integer value parsing failure.
virsh: Fix dommemstat
Use vshCommandOptLongLong() instead of retrieving the value as a
string and converting it to a number manually.
---
tools/virsh-domain.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
index 10d01b6..36f3e6c 100644
---
On 05/15/2015 05:35 AM, Michal Privoznik wrote:
On 14.05.2015 21:38, Laine Stump wrote:
The kernel won't complain if you set the mac address and vlan tag for
an SRIOV VF via its PF, and it will even let you assign the PF to a
guest using PCI device assignment or macvtap passthrough. But if the
On Thu, May 14, 2015 at 03:36:28PM -0400, Laine Stump wrote:
Reorganize the loop that builds controller args to remove unnecessary
duplicated code and superfluous else clauses. No functional change
(this was split out from the following patch to make review easier).
This note can be dropped
On 15.05.2015 17:13, Laine Stump wrote:
On 05/15/2015 05:35 AM, Michal Privoznik wrote:
On 14.05.2015 21:38, Laine Stump wrote:
The kernel won't complain if you set the mac address and vlan tag for
an SRIOV VF via its PF, and it will even let you assign the PF to a
guest using PCI device
On Fri, May 15, 2015 at 04:43:28PM +0200, Michal Privoznik wrote:
From: Tony Krowiak akrow...@linux.vnet.ibm.com
Parse the domain configuration XML elements that enable/disable access to
the protected key management operations for a guest:
domain
...
keywrap
Makes it nicer as update bits are added for different cap types.
---
src/node_device/node_device_driver.c | 27 +++
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/src/node_device/node_device_driver.c
b/src/node_device/node_device_driver.c
index
On Thu, May 14, 2015 at 03:36:20PM -0400, Laine Stump wrote:
V1 was here:
http://www.redhat.com/archives/libvir-list/2015-May/msg00124.html
This started out with the intent to generate an error/failure on
request for an IDE controller on a machinetype that doesn't support
IDE (currently
On Fri, May 15, 2015 at 04:43:27PM +0200, Michal Privoznik wrote:
From: Tony Krowiak akrow...@linux.vnet.ibm.com
Two new domain configuration XML elements have been added to enable/disable
They haven't been added yet :)
This should be squashed in with the patch implementing XML parsing and
For some reason a union (_virNodeDevCapData) that had only been
declared inside the toplevel struct virNodeDevCapsDef was being used
as an argument to functions all over the place. Since it was only a
union, the type attribute wasn't necessarily sent with it. While
this works, it just seems wrong.
Both the hal and udev drivers call virPCI*() functions to the the
SRIOV VF/PF info about PCI devices, and the UDEV backend calls
virPCI*() to get IOMMU group info. Since there is now a single
function call in node_device_linux_sysfs.c to do all of this, replace
all that code in the two backends
Patch 5/6 resolves this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=981546
(filed against RHEL7, but existing in every version of libvirt that
supports reporting of SRIOV virtual function info via the NodeDevice
APIs - 0.7.5, believe it or not).
The rest of the series is there to make
Because reloading a PF driver with a different number of VFs doesn't
result in any sort of event sent from udev to the libvirt node_device
driver, libvirt's cache of that info can be out of date when a request
arrives for the info about a device. To fix this, we refresh that data
at the time of
The udev and hal drivers both already call the same functions as these
new functions added to node_device_linux_sysfs.c, but 1) we need to
call them from node_device_driver.c, and 2) it would be nice to
eliminate the duplicated code from the hal and udev backends.
---
On 27.04.2015 23:57, akrow...@linux.vnet.ibm.com wrote:
From: Tony Krowiak aekro...@us.ibm.com
Introduces two new -machine option parameters to the QEMU command to
enable/disable the CPACF protected key management operations for a guest:
aes-key-wrap='on|off'
dea-key-wrap='on|off'
On 27.04.2015 23:57, akrow...@linux.vnet.ibm.com wrote:
From: Tony Krowiak akrow...@linux.vnet.ibm.com
Parse the domain configuration XML elements that enable/disable access to
the protected key management operations for a guest:
domain
...
keywrap
cipher
From: Tony Krowiak akrow...@linux.vnet.ibm.com
Two new domain configuration XML elements have been added to enable/disable
the protected key management operations for a guest:
domain
...
keywrap
cipher name='aes|dea' state='on|off'/
/keywrap
...
/domain
From: Tony Krowiak aekro...@us.ibm.com
Introduces two new -machine option parameters to the QEMU command to
enable/disable the CPACF protected key management operations for a guest:
aes-key-wrap='on|off'
dea-key-wrap='on|off'
The QEMU code maps the corresponding domain configuration
I've taken Tony's patches from here:
https://www.redhat.com/archives/libvir-list/2015-April/msg01395.html
polished them a bit, and resend.
Tony Krowiak (4):
libvirt: docs: XML to enable/disable protected key mgmt ops
libvirt: conf: parse XML for protected key management ops
libvirt: qemu:
From: Tony Krowiak aekro...@us.ibm.com
Test the support for enabling/disabling CPACF protected key management
operations for a guest.
Signed-off-by: Tony Krowiak akrow...@linux.vnet.ibm.com
Signed-off-by: Viktor Mihajlovski mihaj...@linux.vnet.ibm.com
Reviewed-by: Boris Fiuczynski
From: Tony Krowiak akrow...@linux.vnet.ibm.com
Parse the domain configuration XML elements that enable/disable access to
the protected key management operations for a guest:
domain
...
keywrap
cipher name='aes|dea' state='on|off'/
/keywrap
...
/domain
This file contains only a single function, detect_scsi_host_caps(),
which is declared in node_device_driver.h and called from both the hal
and udev backends. Other things common to the hal and udev drivers
can be placed in that file though. As a prelude to adding further
functions, this patch
On 05/15/2015 10:39 AM, Michal Privoznik wrote:
On 27.04.2015 23:57, akrow...@linux.vnet.ibm.com wrote:
From: Tony Krowiak aekro...@us.ibm.com
Introduces two new -machine option parameters to the QEMU command to
enable/disable the CPACF protected key management operations for a guest:
On 05/15/2015 12:52 PM, Jim Fehlig wrote:
Currently, the libxl driver does not support any security drivers.
When the qemu driver has no security driver configued,
nodeGetSecurityModel succeeds but returns an empty virSecurityModel
object. Do the same in the libxl driver instead of reporting
If an SRIOV PF is offline, the kernel won't complain if you set the
mac address and vlan tag for a VF via this PF, and it will even let
you assign the VF to a guest using PCI device assignment or macvtap
passthrough. But in this case (the PF isn't online), the device won't
be usable in the guest.
On 05/15/2015 12:23 PM, Ján Tomko wrote:
On Fri, May 15, 2015 at 04:43:29PM +0200, Michal Privoznik wrote:
From: Tony Krowiak aekro...@us.ibm.com
Introduces two new -machine option parameters to the QEMU command to
enable/disable the CPACF protected key management operations for a guest:
On 05/15/2015 12:23 PM, Ján Tomko wrote:
On Fri, May 15, 2015 at 04:43:29PM +0200, Michal Privoznik wrote:
From: Tony Krowiak aekro...@us.ibm.com
Introduces two new -machine option parameters to the QEMU command to
enable/disable the CPACF protected key management operations for a guest:
Currently, the libxl driver does not support any security drivers.
When the qemu driver has no security driver configued,
nodeGetSecurityModel succeeds but returns an empty virSecurityModel
object. Do the same in the libxl driver instead of reporting
this function is not supported by the
On 05/15/2015 11:13 AM, Laine Stump wrote:
On 05/15/2015 05:35 AM, Michal Privoznik wrote:
On 14.05.2015 21:38, Laine Stump wrote:
The kernel won't complain if you set the mac address and vlan tag for
an SRIOV VF via its PF, and it will even let you assign the PF to a
guest using PCI device
On Fri, May 15, 2015 at 04:43:30PM +0200, Michal Privoznik wrote:
From: Tony Krowiak aekro...@us.ibm.com
Test the support for enabling/disabling CPACF protected key management
operations for a guest.
Signed-off-by: Tony Krowiak akrow...@linux.vnet.ibm.com
Signed-off-by: Viktor Mihajlovski
On 05/15/2015 10:39 AM, Michal Privoznik wrote:
On 27.04.2015 23:57, akrow...@linux.vnet.ibm.com wrote:
From: Tony Krowiak akrow...@linux.vnet.ibm.com
Parse the domain configuration XML elements that enable/disable access to
the protected key management operations for a guest:
domain
On Fri, May 15, 2015 at 04:43:29PM +0200, Michal Privoznik wrote:
From: Tony Krowiak aekro...@us.ibm.com
Introduces two new -machine option parameters to the QEMU command to
enable/disable the CPACF protected key management operations for a guest:
aes-key-wrap='on|off'
41 matches
Mail list logo
