On 29 May 2018 at 10:36, Michal Privoznik wrote:
> On 05/28/2018 09:34 AM, Sukrit Bhatnagar wrote:
>>
>> This is what new macros will look like:
>>
>> # define _VIR_TYPE_PTR(type) type##Ptr
>>
>> # define _VIR_ATTR_AUTOFREE_PTR(type) __attribute__((cleanup(type##Free)))
>> # define _VIR_ATTR_AUTO
On 05/28/2018 09:34 AM, Sukrit Bhatnagar wrote:
>
> This is what new macros will look like:
>
> # define _VIR_TYPE_PTR(type) type##Ptr
>
> # define _VIR_ATTR_AUTOFREE_PTR(type) __attribute__((cleanup(type##Free)))
> # define _VIR_ATTR_AUTOCLOSE_PTR(type) __attribute__((cleanup(type##Close)))
>
Quoting Jiri Denemark (2018-05-28 09:19:51)
> On Wed, May 16, 2018 at 10:39:19 +0200, Jiri Denemark wrote:
> > The current virConnectCompareCPU and virConnectBaselineCPU APIs are not
> > very useful because they ignore what a hypervisor can do on the current
> > host. This series adds two new APIs
Signed-off-by: Roman Bogorodskiy
---
docs/drvbhyve.html.in | 16
docs/news.xml | 9 +
2 files changed, 25 insertions(+)
diff --git a/docs/drvbhyve.html.in b/docs/drvbhyve.html.in
index 5b5513d3df..78a291c6bb 100644
--- a/docs/drvbhyve.html.in
+++ b/docs/drvbhyve
This series adds support for specifying CPU topology for bhyve guests.
This also would need domxml-from-native support that I plan to add
separately.
I've updated docs to mention 4.4.0, but more probably it'll go to 4.5.0
as the freeze is close and I'm not sure I'll be able to turn around
before i
Recently, bhyve started supporting specifying guest CPU topology.
It looks this way:
bhyve -c cpus=C,sockets=S,cores=C,threads=T ...
The old behaviour with bhyve -c C, where C is a number of vCPUs, is
still supported.
So if we have CPU topology in the domain XML, use the new syntax,
otherwise
On 28 May 2018 at 13:54, Pavel Hrdina wrote:
> On Mon, May 28, 2018 at 01:04:28PM +0530, Sukrit Bhatnagar wrote:
>> On 25 May 2018 at 16:20, Pavel Hrdina wrote:
>> > On Fri, May 25, 2018 at 12:06:50PM +0200, Andrea Bolognani wrote:
>> >> On Fri, 2018-05-25 at 10:04 +0200, Pavel Hrdina wrote:
>> >
On Mon, May 28, 2018 at 04:48:08PM +0200, Erik Skultety wrote:
> On Mon, May 28, 2018 at 10:15:22AM +0200, Erik Skultety wrote:
> > On Mon, May 28, 2018 at 10:01:06AM +0200, Daniel Veillard wrote:
> > > Seems the end of the month is coming soon !
> > > I suggest to enter freeze tomorrow morningm
On Mon, May 28, 2018 at 10:15:22AM +0200, Erik Skultety wrote:
> On Mon, May 28, 2018 at 10:01:06AM +0200, Daniel Veillard wrote:
> > Seems the end of the month is coming soon !
> > I suggest to enter freeze tomorrow morningm with plan for an RC2 on Thursday
> > and a final release on the week-en
On Mon, May 28, 2018 at 16:31:47 +0200, Michal Privoznik wrote:
> Trying to set any cache for makes no sense.
> Such disk translates into -device scsi-block on the command line
> and the device lacks any cache setting because it's merely a
> middle man between qemu and real SCSI device.
>
> Signe
On Mon, May 28, 2018 at 04:36:54PM +0200, Erik Skultety wrote:
> On Wed, May 23, 2018 at 04:18:31PM -0500, Brijesh Singh wrote:
> > The API can be used outside the libvirt to get the launch security
> > information. When SEV is enabled, the API can be used to get the
> > measurement of the launch p
On Wed, May 23, 2018 at 04:18:33PM -0500, Brijesh Singh wrote:
> This patch implements the internal driver API for launch event into
> qemu driver. When SEV is enabled, execute 'query-sev-launch-measurement'
> to get the measurement of memory encrypted through launch sequence.
>
> Signed-off-by: Br
On Wed, May 23, 2018 at 04:18:32PM -0500, Brijesh Singh wrote:
> Add remote support for launch security info.
Add support for GetLaunchSecurityInfo to remote driver.
My naming comments from patch 6 apply here too.
>
> Signed-off-by: Brijesh Singh
Functionally though,
Reviewed-by: Erik Skultety
On Wed, May 23, 2018 at 04:18:31PM -0500, Brijesh Singh wrote:
> The API can be used outside the libvirt to get the launch security
> information. When SEV is enabled, the API can be used to get the
> measurement of the launch process.
>
> Signed-off-by: Brijesh Singh
> ---
> include/libvirt/libv
Trying to set any cache for makes no sense.
Such disk translates into -device scsi-block on the command line
and the device lacks any cache setting because it's merely a
middle man between qemu and real SCSI device.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_command.c | 5 +
1 file c
On Wed, May 16, 2018 at 10:39:19 +0200, Jiri Denemark wrote:
> The current virConnectCompareCPU and virConnectBaselineCPU APIs are not
> very useful because they ignore what a hypervisor can do on the current
> host. This series adds two new APIs which are designed to work with
> capabilities of a
On Wed, May 23, 2018 at 04:18:34PM -0500, Brijesh Singh wrote:
> Add new 'launch-security' command, the command can be used to get or set
> the launch security information when booting encrypted VMs.
>
> Signed-off-by: Brijesh Singh
> ---
> tools/virsh-domain.c | 81
> +++
On Mon, May 28, 2018 at 11:36:45AM +0200, Peter Krempa wrote:
When parsing status XML the post-parse callbacks can't access any
private data present in the status XML as the private bits were parsed
after invoking post-parse callbacks.
Move the invocation so that everything is parsed first.
Sig
On Mon, May 28, 2018 at 11:36:46AM +0200, Peter Krempa wrote:
The status XML parser function virDomainObjParseXML could not pass in
parseOpaque into the post parse callbacks. Add a callback which will
allow hypervisor drivers to fill it from the 'virDomainObj' data.
Signed-off-by: Peter Krempa
On Mon, May 28, 2018 at 11:36:47AM +0200, Peter Krempa wrote:
When status XML was parsed the post-parse callbacks could not access
qemu caps and potentially upgrade the definition according to the
present caps. Implement the callback to pass it in.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_
On Mon, May 28, 2018 at 11:36:44AM +0200, Peter Krempa wrote:
There is only one block accessing it. Removing it is necessary so that
post parse callbacks can later be invoked after the hypervisor private
data callback so that e.g. qemuCaps are properly filled for the
postparse callbacks.
As the
Move the check for boot elements into a separate function
and remove its dependency on the parser-supplied bootHash table.
Reconstructing the hash table from the domain definition
effectively duplicates the check for duplicate boot order
values, also present in virDomainDeviceBootParseXML.
Signed
An alternative to Peter's:
[PATCH 1/4] conf: domain: Remove code accessing 'bootHash' from the post-parse
infrestructure
<8b4627fedd199117af1ab46f5562e3838679357e.1527500017.git.pkre...@redhat.com>
Ján Tomko (3):
vmx: add VIR_DOMAIN_DEF_FEATURE_NO_BOOT_ORDER
conf: introduce virDomainDefCheckB
Further patches will introduce validation and a default setting
of def->os.bootDevs in postParse.
Introduce a feature flag to opt out of this and set it in the vmx
driver.
Signed-off-by: Ján Tomko
---
src/conf/domain_conf.h | 1 +
src/vmx/vmx.c | 3 ++-
2 files changed, 3 insertions(+)
From: Peter Krempa
As the function signature of virDomainDefPostParseInternal does not
differ from virDomainDefPostParse now, the wrapper can be dropped.
Signed-off-by: Peter Krempa
Signed-off-by: Ján Tomko
---
src/conf/domain_conf.c | 33 +
1 file changed, 9 i
Its only use is now to check for duplicate boot order values,
which is now also done in virDomainDefPostParseCommon.
Remove it completely.
Signed-off-by: Ján Tomko
---
src/conf/domain_conf.c | 89 ++
1 file changed, 31 insertions(+), 58 deletions(
On Fri, May 25, 2018 at 13:50:19 -0400, Collin Walling wrote:
> Sorry for the delay. I've been experiencing issues with the mail server :(
>
> On 05/16/2018 04:39 AM, Jiri Denemark wrote:
> > Signed-off-by: Jiri Denemark
> > ---
> > src/qemu/qemu_driver.c | 60 +++
On Fri, May 25, 2018 at 15:22:43 -0400, Collin Walling wrote:
> >>> +switch (result) {
> >>> +case VIR_CPU_COMPARE_INCOMPATIBLE:
> >>> +vshPrint(ctl,
> >>> + _("CPU described in %s is incompatible with the CPU
> >>> provided "
> >>> + "by hyperviso
On Wed, May 23, 2018 at 04:18:30PM -0500, Brijesh Singh wrote:
> QEMU >= 2.12 provides 'sev-guest' object which is used to launch encrypted
>
Unnecessary new line here...
> VMs on AMD platform using SEV feature. The various inputs required to
> launch SEV guest is provided through the tag. A typ
On Wed, May 23, 2018 at 04:18:29PM -0500, Brijesh Singh wrote:
> QEMU uses /dev/sev device while creating the SEV guest, lets add /dev/sev
> in the list of devices allowed to be accessed by the QEMU.
>
> Signed-off-by: Brijesh Singh <>
> ---
I think this might be swapped with the previous patch an
On Wed, May 23, 2018 at 04:18:28PM -0500, Brijesh Singh wrote:
> The launch-security element can be used to define the security
> model to use when launching a domain. Currently we support 'sev'.
>
> When 'sev' is used, the VM will be launched with AMD SEV feature enabled.
> SEV feature supports ru
On Wed, May 23, 2018 at 04:18:27PM -0500, Brijesh Singh wrote:
> Extend hypervisor capabilities to include sev feature. When available,
> hypervisor supports launching an encrypted VM on AMD platform. The
> sev feature tag provides additional details like Platform Diffie-Hellman
> (PDH) key and cer
On Wed, May 23, 2018 at 04:18:25PM -0500, Brijesh Singh wrote:
> This patch series provides support for launching an encrypted guest using
> AMD's new Secure Encrypted Virtualization (SEV) feature.
>
> SEV is an extension to the AMD-V architecture which supports running
> multiple VMs under the co
On Mon, May 28, 2018 at 9:16 AM, Ján Tomko wrote:
> On Sun, May 27, 2018 at 02:08:58PM +0200, Fabiano Fidêncio wrote:
>>
>> On Sun, May 27, 2018 at 1:17 PM, Ján Tomko wrote:
>>>
>>> On Sat, May 26, 2018 at 11:00:27PM +0200, Fabiano Fidêncio wrote:
From: Fabiano Fidêncio
The status XML parser function virDomainObjParseXML could not pass in
parseOpaque into the post parse callbacks. Add a callback which will
allow hypervisor drivers to fill it from the 'virDomainObj' data.
Signed-off-by: Peter Krempa
---
src/conf/domain_conf.c | 6 +-
src/conf/domain_conf.h |
When parsing status XML the post-parse callbacks can't access any
private data present in the status XML as the private bits were parsed
after invoking post-parse callbacks.
Move the invocation so that everything is parsed first.
Signed-off-by: Peter Krempa
---
src/conf/domain_conf.c | 37 +
There is only one block accessing it. Removing it is necessary so that
post parse callbacks can later be invoked after the hypervisor private
data callback so that e.g. qemuCaps are properly filled for the
postparse callbacks.
As the function signature of virDomainDefPostParseInternal does not
dif
This will allow the qemu post-parse callbacks to access 'qemuCaps' which
is stored in the status XML when we restore the status of VMs.
It will become useful in cases when we need to decide whether storage
authentication/encryption secret aliases will need to be regenerated.
Peter Krempa (4):
c
When status XML was parsed the post-parse callbacks could not access
qemu caps and potentially upgrade the definition according to the
present caps. Implement the callback to pass it in.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_domain.c | 10 ++
1 file changed, 10 insertions(+)
dif
On 5/25/2018 6:58 PM, Pino Toscano wrote:
On Thursday, 24 May 2018 14:24:27 CEST Xiao Feng Ren wrote:
From: Yi Min Zhao
Let's introduce zPCI capability.
Signed-off-by: Yi Min Zhao
Reviewed-by: Boris Fiuczynski
Reviewed-by: Stefan Zimmermann
Reviewed-by: Bjoern Walk
---
src/qemu/qemu_c
On 5/25/2018 6:22 PM, Bjoern Walk wrote:
Cornelia Huck [2018-05-24, 06:25PM +0200]:
On Thu, 24 May 2018 14:24:32 +0200
Xiao Feng Ren wrote:
From: Yi Min Zhao
This commit adds hotplug support for PCI devices on S390 guests.
There's no need to implement hot unplug for zPCI as QEMU implemen
On Mon, May 28, 2018 at 01:04:28PM +0530, Sukrit Bhatnagar wrote:
> On 25 May 2018 at 16:20, Pavel Hrdina wrote:
> > On Fri, May 25, 2018 at 12:06:50PM +0200, Andrea Bolognani wrote:
> >> On Fri, 2018-05-25 at 10:04 +0200, Pavel Hrdina wrote:
> >> > On Fri, May 25, 2018 at 09:13:51AM +0200, Andrea
On Mon, May 28, 2018 at 10:01:06AM +0200, Daniel Veillard wrote:
> Seems the end of the month is coming soon !
> I suggest to enter freeze tomorrow morningm with plan for an RC2 on Thursday
> and a final release on the week-end,
>
> Hope this works for everybody,
>
> thanks !
Hi,
would Wednes
On Mon, May 28, 2018 at 01:04:28PM +0530, Sukrit Bhatnagar wrote:
> On 25 May 2018 at 16:20, Pavel Hrdina wrote:
> > On Fri, May 25, 2018 at 12:06:50PM +0200, Andrea Bolognani wrote:
> >> On Fri, 2018-05-25 at 10:04 +0200, Pavel Hrdina wrote:
> >> > On Fri, May 25, 2018 at 09:13:51AM +0200, Andrea
Seems the end of the month is coming soon !
I suggest to enter freeze tomorrow morningm with plan for an RC2 on Thursday
and a final release on the week-end,
Hope this works for everybody,
thanks !
Daniel
--
Daniel Veillard | Red Hat Developers Tools http://developer.redhat.com/
veil
On 25 May 2018 at 16:20, Pavel Hrdina wrote:
> On Fri, May 25, 2018 at 12:06:50PM +0200, Andrea Bolognani wrote:
>> On Fri, 2018-05-25 at 10:04 +0200, Pavel Hrdina wrote:
>> > On Fri, May 25, 2018 at 09:13:51AM +0200, Andrea Bolognani wrote:
>> > > However, I realize it might not be possible to re
On Sun, May 27, 2018 at 16:25:35 -0300, Julio Faracco wrote:
> This commit adds some basic structures to support events for volumes as
> libvirt does with pools, networks, domains, secrets, etc. This commit
> add only lifecycle event to be included at create and delete actions.
>
> Signed-off-by:
On Wed, May 23, 2018 at 04:18:26PM -0500, Brijesh Singh wrote:
> QEMU version >= 2.12 provides support for launching an encrypted VMs on
> AMD x86 platform using Secure Encrypted Virtualization (SEV) feature.
> This patch adds support to query the SEV capability from the qemu.
>
> Signed-off-by: Br
On Wed, May 23, 2018 at 04:18:26PM -0500, Brijesh Singh wrote:
> QEMU version >= 2.12 provides support for launching an encrypted VMs on
> AMD x86 platform using Secure Encrypted Virtualization (SEV) feature.
> This patch adds support to query the SEV capability from the qemu.
>
> Signed-off-by: Br
Eduardo Habkost writes:
> On Fri, May 25, 2018 at 08:30:59AM +0200, Markus Armbruster wrote:
>> Eduardo Habkost writes:
>> > On Wed, May 23, 2018 at 05:53:34PM +0200, Markus Armbruster wrote:
> [...]
>> >> >> Worse, a machine type property that is static for all machine types now
>> >> >> could
On Sun, May 27, 2018 at 02:08:58PM +0200, Fabiano Fidêncio wrote:
On Sun, May 27, 2018 at 1:17 PM, Ján Tomko wrote:
On Sat, May 26, 2018 at 11:00:27PM +0200, Fabiano Fidêncio wrote:
From: Fabiano Fidêncio
There are still some places using virConfGetValue() and then checking
the specific typ
On Fri, May 25, 2018 at 10:26:12 -0500, Eric Blake wrote:
> On 05/17/2018 05:43 PM, Eric Blake wrote:
> > Here's my updated counterproposal for a backup API.
> >
> > In comparison to v2 posted by Nikolay:
> > https://www.redhat.com/archives/libvir-list/2018-April/msg00115.html
> > - changed termin
52 matches
Mail list logo