On 6/13/19 9:54 AM, Cornelia Huck wrote:
On Fri, 7 Jun 2019 14:30:48 -0400
Tony Krowiak wrote:
On 6/7/19 10:56 AM, Cornelia Huck wrote:
On Thu, 6 Jun 2019 12:45:29 -0400
Matthew Rosato wrote:
On 6/6/19 10:44 AM, Cornelia Huck wrote:
This patch adds a very rough implementation
On 6/13/19 10:18 AM, Cornelia Huck wrote:
On Tue, 11 Jun 2019 10:19:29 -0400
Tony Krowiak wrote:
On 6/7/19 4:03 PM, Alex Williamson wrote:
On Fri, 7 Jun 2019 14:26:13 -0400
Tony Krowiak wrote:
On 6/6/19 12:15 PM, Alex Williamson wrote:
On Thu, 6 Jun 2019 09:32:24 -0600
Alex Williamson
On 6/7/19 4:03 PM, Alex Williamson wrote:
On Fri, 7 Jun 2019 14:26:13 -0400
Tony Krowiak wrote:
On 6/6/19 12:15 PM, Alex Williamson wrote:
On Thu, 6 Jun 2019 09:32:24 -0600
Alex Williamson wrote:
On Thu, 6 Jun 2019 16:44:17 +0200
Cornelia Huck wrote:
Add a rough implementation
On 6/7/19 10:56 AM, Cornelia Huck wrote:
On Thu, 6 Jun 2019 12:45:29 -0400
Matthew Rosato wrote:
On 6/6/19 10:44 AM, Cornelia Huck wrote:
This patch adds a very rough implementation of additional config data
for mdev devices. The idea is to make it possible to specify some
type-specific
On 6/6/19 12:15 PM, Alex Williamson wrote:
On Thu, 6 Jun 2019 09:32:24 -0600
Alex Williamson wrote:
On Thu, 6 Jun 2019 16:44:17 +0200
Cornelia Huck wrote:
Add a rough implementation for vfio-ap.
Signed-off-by: Cornelia Huck
---
mdevctl.libexec | 25 ++
uot;version is a required attribute if live migration is supported
for an mdev device"?
My two cents: This is the best of the suggestions
Tony Krowiak
you are right, "mandatory" may bring some confusion.
Maybe
"vendor driver must provide version attribute for an mdev dev
On 10/30/2015 06:49 AM, Michal Privoznik wrote:
On 29.10.2015 18:48, Laine Stump wrote:
On 10/29/2015 12:49 PM, Tony Krowiak wrote:
For a guest domain defined with a large number of macvtap devices, it
takes an exceedingly long time to boot the guest. In a test of a guest
domain configured
On 10/29/2015 01:48 PM, Laine Stump wrote:
On 10/29/2015 12:49 PM, Tony Krowiak wrote:
For a guest domain defined with a large number of macvtap devices, it takes an
exceedingly long time to boot the guest. In a test of a guest domain configured
with 82 macvtap devices, it took over two
For a guest domain defined with a large number of macvtap devices, it takes an
exceedingly long time to boot the guest. In a test of a guest domain configured
with 82 macvtap devices, it took over two minutes for the guest to boot. An
strace of the ioctl calls during guest start up showed the
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: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
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 04/27/2015 05:57 PM, akrow...@linux.vnet.ibm.com wrote:
From: Tony Krowiak akrow...@linux.vnet.ibm.com
The IBM System z Central Processor Assist for Cryptographic Functions (CPACF)
hardware provides a set of CPU instructions for use in clear-key encryption,
pseudo random number generation
On 01/21/2015 01:44 PM, Laine Stump wrote:
(I didn't try make syntax-check, but am assuming you have and that it
passes)
On 01/19/2015 11:18 AM, akrow...@linux.vnet.ibm.com wrote:
From: Tony Krowiak akrow...@linux.vnet.ibm.com
This patch supplies the funtionality of synchronizing the host
On 01/21/2015 01:34 PM, Laine Stump wrote:
On 01/19/2015 11:18 AM, akrow...@linux.vnet.ibm.com wrote:
From: Tony Krowiak akrow...@linux.vnet.ibm.com
This patch provides the utility functions needed to synchronize
the rxfilter changes made to a guest domain with the corresponding
macvtap
screwed something up :-))
Oh, and so that it is officially said: ACK, with my small patch squashed in.
I applied your patches and tested them. All is working as before
applying it.
ACK this patch to my patch.
On 10/10/2014 01:55 PM, akrow...@linux.vnet.ibm.com wrote:
From: Tony Krowiak akrow
On 10/08/2014 12:59 PM, Eric Blake wrote:
On 10/08/2014 09:36 AM, Laine Stump wrote:
On 10/06/2014 05:37 PM, akrow...@linux.vnet.ibm.com wrote:
From: Tony Krowiak akrow...@linux.vnet.ibm.com
This patch provides the utility functions to needed to synchronize the
changes made to a guest domain
On 10/08/2014 11:36 AM, Laine Stump wrote:
On 10/06/2014 05:37 PM, akrow...@linux.vnet.ibm.com wrote:
From: Tony Krowiak akrow...@linux.vnet.ibm.com
This patch provides the utility functions to needed to synchronize the
changes made to a guest domain network device's multicast filter
On 10/08/2014 03:15 PM, Laine Stump wrote:
On 10/06/2014 05:37 PM, akrow...@linux.vnet.ibm.com wrote:
From: Tony Krowiak akrow...@linux.vnet.ibm.com
This patch adds functionality to processNicRxFilterChangedEvent().
The old and new multicast lists are compared and the filters in
the macvtap
On 10/02/2014 10:19 AM, Laine Stump wrote:
On 10/01/2014 03:36 PM, Tony Krowiak wrote:
On 09/30/2014 03:47 PM, Laine Stump wrote:
On 09/30/2014 02:28 PM, Tony Krowiak wrote:
On 09/24/2014 05:50 AM, Laine Stump wrote:
These patches set up an event handler for qemu's NIC_RX_FILTER_CHANGED
On 09/30/2014 03:47 PM, Laine Stump wrote:
On 09/30/2014 02:28 PM, Tony Krowiak wrote:
On 09/24/2014 05:50 AM, Laine Stump wrote:
These patches set up an event handler for qemu's NIC_RX_FILTER_CHANGED
event, which is sent whenever a guest makes a change to a network
device's unicast/multicast
On 09/24/2014 05:50 AM, Laine Stump wrote:
NIC_RX_FILTER_CHANGED is sent by qemu any time a NIC driver in the
guest modified the NIC's RX Filter (for example, if the MAC address of
the NIC is changed by the guest).
This patch doesn't do anything useful with that event; it just sets up
all the
On 09/24/2014 05:50 AM, Laine Stump wrote:
These patches set up an event handler for qemu's NIC_RX_FILTER_CHANGED
event, which is sent whenever a guest makes a change to a network
device's unicast/multicast filter, vlan table, or MAC address.
The handler checks if it is appropriate to respond
24 matches
Mail list logo
