On 10/29/18 7:26 PM, Jim Fehlig wrote:
The pvops Linux kernel implements machine_ops.crash_shutdown as
static void xen_hvm_crash_shutdown(struct pt_regs *regs)
{
native_machine_crash_shutdown(regs);
xen_reboot(SHUTDOWN_soft_reset);
}
but currently the libxl driver does not
The pvops Linux kernel implements machine_ops.crash_shutdown as
static void xen_hvm_crash_shutdown(struct pt_regs *regs)
{
native_machine_crash_shutdown(regs);
xen_reboot(SHUTDOWN_soft_reset);
}
but currently the libxl driver does not handle the soft reset
shutdown event. As a
On 10/17/18 10:15 AM, Daniel P. Berrangé wrote:
> This reverts commit 8b035c84d8a7362a87a95e6114b8e7f959685ed9.
>
> The MTTCG impl in QEMU does allow pinning vCPUs.
>
> When the guest is running we already check if pinning is
> possible in the qemuDomainPinVcpuLive method, so this
> check was
On 10/17/18 10:15 AM, Daniel P. Berrangé wrote:
> MTTCG is the new multi-threaded impl of TCG which follows
> KVM in having one host OS thread per vCPU. Historically
> we have discarded all PIDs reported for TCG guests, but
> we must now selectively honour this data.
>
> We don't have anything
On 10/15/18 4:26 AM, Nikolay Shirokovskiy wrote:
> Before using filters binding filters instantiation was done by hypervisors
> drivers initialization code (qemu was the only such hypervisor). Now qemu
> reconnection done supposes it should be done by nwfilter driver probably.
> Let's add this
Introduce caching whether /dev/kvm is usable as the QEMU user:QEMU
group. This reduces the overhead of the QEMU capabilities cache
lookup. Before this patch there were many fork() calls used for
checking whether /dev/kvm is accessible. Now we store the result
whether /dev/kvm is accessible or not
On Thursday, 18 October 2018 14:26:47 CET Michal Privoznik wrote:
> To avoid multiple includes, header files start with:
>
> #ifndef __SOMETHING__
> # define __SOMETHING__
>
> Well, SOMETHING should be the file name, and there should be a
> space after hash and before 'define'.
Note that
On Mon, Oct 29, 2018 at 05:53:58PM +0100, Marc Hartmayer wrote:
> Introduce caching whether /dev/kvm is usable as the QEMU user:QEMU
> group. This reduces the overhead of the QEMU capabilities cache
> lookup. Before this patch there were many fork() calls used for
> checking whether /dev/kvm is
ping?
Thoughts at all - it's more doc than code and I'd really like to be sure
the words are proper and/or make sense.
Tks -
John
On 10/15/18 10:26 AM, John Ferlan wrote:
> Details in the patches
>
> John Ferlan (2):
> access: Modify the VIR_ERR_ACCESS_DENIED to include driverName
> docs:
Introduce caching whether /dev/kvm is usable as the QEMU user:QEMU
group. This reduces the overhead of the QEMU capabilities cache
lookup. Before this patch there were many fork() calls used for
checking whether /dev/kvm is accessible. Now we store the result
whether /dev/kvm is accessible or not
On 10/18/18 10:54 AM, Boris Fiuczynski wrote:
> v2:
> + added singleton check for vfio-ap mediated device
>
> This patch series introduces initial libvirt support for guest
> dedicated crypto adapters on S390.
> It allows to specify a vfio-ap mediated device in a domain.
> Extensive
On 10/29/18 11:54 AM, Boris Fiuczynski wrote:
> Hi Erik,
> do you think it is possible that this series gets into v4.9.0?
>
> Cheers,
> Boris
>
Not sure if Erik is "online" today... The Red Hat portion of the team
has just returned from KVM Forum and today we have some well larger news
to
Hi Erik,
do you think it is possible that this series gets into v4.9.0?
Cheers,
Boris
On 10/24/18 12:18 AM, Erik Skultety wrote:
On Mon, Oct 22, 2018 at 10:10:39AM +0200, Boris Fiuczynski wrote:
On 10/19/18 1:56 PM, Thomas Huth wrote:
On 2018-10-18 16:54, Boris Fiuczynski wrote:
Adjusting
I'm afraid I'm a bit behind. I suggest to enter freeze tomorrow morning
then pushing rc2 on Thursday and if everything goes well push the GA
during the w.e., a bit late but not too late.
I hope this works for everybody,
thanks,
Daniel
--
Daniel Veillard | Red Hat Developers Tools
On Thu, Oct 25, 2018 at 10:11:34AM +, Huangyong wrote:
> Hello,
>
> In qemu_command, vnc graphic device can’t be more than 1, as the
> following code show in qemuBuildCommandLineValidate():
> If（sdl > 1 || vnc > 1 || spice > 1） {
>virReportError(….);
>
Hello,
In qemu_command, vnc graphic device can’t be more than 1, as the
following code show in qemuBuildCommandLineValidate():
If（sdl > 1 || vnc > 1 || spice > 1） {
virReportError(….);
return -1;
}
This check originally introduced by
External snapshot of readonly disk of active domain is impossible but error
message [1] is cryptic (it's source is qemu). Let's make error message more
user friendly.
The problem is libvirtd precreates snapshot image with no write permission which
is not expected by qemu.
[1] current error
On Thu, Oct 25, 2018 at 01:12:15PM +0200, Philippe Mathieu-Daudé wrote:
> Hi Gerd,
>
> On 25/10/18 10:52, Gerd Hoffmann wrote:
> > Simliar to deprecated machine types.
>
> "Similar"
>
> > Print a warning when creating a deprecated device.
> > Add deprecation notice to -device help.
> >
> >
On Thu, Oct 25, 2018 at 09:37:58PM +0100, Daniel P. Berrangé wrote:
> On Thu, Oct 25, 2018 at 10:52:56AM +0200, Gerd Hoffmann wrote:
> > While being at it deprecate cirrus too.
> >
> > Reason (short version): use stdvga instead.
> > Verbose version:
> >
On Fri, Oct 26, 2018 at 05:23:37PM +0530, P J P wrote:
> +-- On Fri, 26 Oct 2018, Paolo Bonzini wrote --+
> | Oh, thanks! I said I was dumb. :) So the fix is just this:
> |
> | diff --git a/hw/audio/fmopl.h b/hw/audio/fmopl.h
> | index e7e578a48e..7199afaa3c 100644
> | --- a/hw/audio/fmopl.h
>
polite ping
On 2018/10/17 上午10:21, Luyao Zhong wrote:
Hi libvirt experts,
This is the RFC for updating NVDIMM support in libvirt.
QEMU has supported four more properties which libvirt has not introduced
yet, including 'align', 'pmem', 'nvdimm-persistences' and 'unarmed'.
The 'align' property
This patch adds caching to rules instantiating in nwfilter. This instantiating
can take much time as described in [1] so as we are lacking option to
instantiate rules faster right now we can at least don't instantiate when we
don't need to. And this is typical that between libvirtd restarts rules
We are going to save this dump on applying rules so that on
next applying we can compare dump of current rules with dump of
previous rules. Which in turn will help us to decide wether to
reinstantiate rules or not.
Signed-off-by: Nikolay Shirokovskiy
---
src/libvirt_private.syms | 1 +
Applied on top of [1] that restores reinstantiating filters on daemon reload.
Note the fragile issue mentioned in ebiptablesDumpIstalledRules in respect to
list
of firewall tables we are using.
I wonder can we instead of caching instantiate rules faster in the end? There
is iptables-restore if
On Thu, Oct 18, 2018 at 5:28 PM Martin Kletzander
wrote:
> On Thu, Oct 18, 2018 at 02:12:36PM +0800, Han Han wrote:
> >On Wed, Oct 17, 2018 at 4:46 PM Martin Kletzander
> >wrote:
> >
> >> On Tue, Oct 16, 2018 at 07:19:41PM -0400, John Ferlan wrote:
> >> >
> >> >
> >> >On 10/14/18 10:26 AM, Han
25 matches
Mail list logo
