On Thu, Oct 29, 2020 at 07:28:23PM +0100, Michal Privoznik wrote:
> On 10/29/20 6:56 PM, Andrea Bolognani wrote:
> > On Thu, 2020-10-29 at 15:23 +0100, Michal Privoznik wrote:
> > > On 10/29/20 2:36 PM, Andrea Bolognani wrote:
> > > > In the former case we should modify the functions dealing with
I have just tagged v6.9.0-rc2 in the repository and pushed signed
tarballs and source RPMs to https://libvirt.org/sources/
Please give the release candidate some testing and in case you find a
serious issue which should have a fix in the upcoming release, feel
free to reply to this thread to make
On 10/29/20 6:25 PM, Daniel P. Berrangé wrote:
BTW: I've pushed this so that Jirka can cook -rc2 overnight.
Michal
On 10/29/20 6:25 PM, Daniel P. Berrangé wrote:
GLibC has a really complicated way of dealing with the 'stat' function
historically, which means our mocks in turn have to look at four
different possible functions to replace, stat, stat64, __xstat,
__xstat64.
In Fedora 33 and earlier:
-
On 10/29/20 6:56 PM, Andrea Bolognani wrote:
On Thu, 2020-10-29 at 15:23 +0100, Michal Privoznik wrote:
On 10/29/20 2:36 PM, Andrea Bolognani wrote:
In the former case we should modify the functions dealing with them
so that they become successful no-ops, in the latter we should
probably do
On Thu, 2020-10-29 at 15:23 +0100, Michal Privoznik wrote:
> On 10/29/20 2:36 PM, Andrea Bolognani wrote:
> > In the former case we should modify the functions dealing with them
> > so that they become successful no-ops, in the latter we should
> > probably do what we do on Windows and not build
GLibC has a really complicated way of dealing with the 'stat' function
historically, which means our mocks in turn have to look at four
different possible functions to replace, stat, stat64, __xstat,
__xstat64.
In Fedora 33 and earlier:
- libvirt.so links to __xstat64
- libc.so library exports
On Mon, Oct 26, 2020 at 08:36:50 -0500, Eric Blake wrote:
> On 10/26/20 8:19 AM, Peter Krempa wrote:
> > We use the capability to switch to using 'block-export-add' in the
> > upcoming qemu release instead of the at the same time deprecated
> > 'nbd-server-add'.
> >
> > Unfortunately qemu wants
On 29.10.2020 10:59, Peter Krempa wrote:
> On Thu, Oct 22, 2020 at 17:46:28 +0300, Nikolay Shirokovskiy wrote:
>>
>>
>> On 22.10.2020 15:12, Peter Krempa wrote:
>>> On Tue, Oct 20, 2020 at 16:44:07 +0300, Nikolay Shirokovskiy wrote:
Currently in qemuProcessHandleBlockJob we either offload
This patch maps /domain/cpu/maxphysaddr into -cpu parameters:
- becomes host-phys-bits=on
- becomes phys-bits=42
Passthrough mode can only be used if the chosen CPU model is
'host-passthrough'.
The feature is available since QEMU 2.7.0.
Signed-off-by: Dario Faggioli
---
This patch introduces the:
sub element of /domain/cpu.
Purpose is being able to have a guest see the physical address size
exactly as the host does (if mode='passthrough' is used) or any size
the user wants it to see (if mode='emulate' is used and bits='' is
specified).
This can be
Hello everyone,
These patches let one specify how wide the physical addresses are, in
bits.
Using current QEMU's default of 40 may limit the amount of RAM the guest
can see (which is the reason why, in our packages, we bump that to 42; and
as far as I've understood from reading some old mailing
Hi, folks
Like last year[1], we're aiming to submit a KVM Forum 2020 "recap"
article for LWN.
This won't be a comprehensive summary of a lot of talks — LWN normally
aims for 1500 words; they say "fewer can sometimes work, and more is
generally OK too". Given that, the write-up can cover about
On 10/29/20 2:36 PM, Andrea Bolognani wrote:
On Thu, 2020-10-29 at 12:18 +0100, Michal Privoznik wrote:
On 10/29/20 11:49 AM, Andrea Bolognani wrote:
Assuming macOS doesn't have any root-only namespaces, can we simply
compile out the feature entirely on that OS? What about other targets
like
On Thu, Oct 29, 2020 at 02:36:42PM +0100, Andrea Bolognani wrote:
> On Thu, 2020-10-29 at 12:18 +0100, Michal Privoznik wrote:
> > On 10/29/20 11:49 AM, Andrea Bolognani wrote:
> > > Assuming macOS doesn't have any root-only namespaces, can we simply
> > > compile out the feature entirely on that
On Thu, 2020-10-29 at 12:18 +0100, Michal Privoznik wrote:
> On 10/29/20 11:49 AM, Andrea Bolognani wrote:
> > Assuming macOS doesn't have any root-only namespaces, can we simply
> > compile out the feature entirely on that OS? What about other targets
> > like Windows?
>
> What do you mean by
On Thu, Oct 29, 2020 at 9:03 AM Daniel P. Berrangé wrote:
>
> On Thu, Oct 29, 2020 at 09:01:05AM -0400, Neal Gompa wrote:
> > On Thu, Oct 29, 2020 at 7:39 AM Daniel P. Berrangé
> > wrote:
> > >
> > > On Thu, Oct 29, 2020 at 12:27:16PM +0100, Michal Privoznik wrote:
> > > > On 10/28/20 9:47 PM,
On Thu, Oct 29, 2020 at 5:40 AM Daniel P. Berrangé wrote:
>
> On Wed, Oct 28, 2020 at 04:49:43PM -0400, Neal Gompa wrote:
> > On Wed, Oct 28, 2020 at 8:36 AM Daniel P. Berrangé
> > wrote:
> > >
> > > The %meson macro sets "--auto-features=enabled", thus any feature in the
> > > RPM which has a
On Thu, Oct 29, 2020 at 09:01:05AM -0400, Neal Gompa wrote:
> On Thu, Oct 29, 2020 at 7:39 AM Daniel P. Berrangé
> wrote:
> >
> > On Thu, Oct 29, 2020 at 12:27:16PM +0100, Michal Privoznik wrote:
> > > On 10/28/20 9:47 PM, Neal Gompa wrote:
> > > > On Wed, Oct 28, 2020 at 7:49 AM Michal
On Thu, Oct 29, 2020 at 7:39 AM Daniel P. Berrangé wrote:
>
> On Thu, Oct 29, 2020 at 12:27:16PM +0100, Michal Privoznik wrote:
> > On 10/28/20 9:47 PM, Neal Gompa wrote:
> > > On Wed, Oct 28, 2020 at 7:49 AM Michal Privoznik
> > > wrote:
> > > >
> > > > On 10/27/20 1:06 PM, Neal Gompa wrote:
>
On Thu, Oct 29, 2020 at 12:27:16PM +0100, Michal Privoznik wrote:
> On 10/28/20 9:47 PM, Neal Gompa wrote:
> > On Wed, Oct 28, 2020 at 7:49 AM Michal Privoznik
> > wrote:
> > >
> > > On 10/27/20 1:06 PM, Neal Gompa wrote:
> > > > On Tue, Oct 27, 2020 at 6:24 AM Michal Privoznik
> > > > wrote:
On 10/28/20 9:47 PM, Neal Gompa wrote:
On Wed, Oct 28, 2020 at 7:49 AM Michal Privoznik wrote:
On 10/27/20 1:06 PM, Neal Gompa wrote:
On Tue, Oct 27, 2020 at 6:24 AM Michal Privoznik wrote:
On 10/26/20 11:08 PM, Neal Gompa wrote:
Contemporary versions of Fedora automatically set
On 10/29/20 11:49 AM, Andrea Bolognani wrote:
On Wed, 2020-10-28 at 20:25 +0100, Michal Privoznik wrote:
On 10/28/20 8:16 PM, Andrea Bolognani wrote:
On Mon, 2020-10-26 at 00:25 +0300, Roman Bolshakov wrote:
+++ b/src/security/security_util.c
@@ -56,6 +56,8 @@
On Wed, 2020-10-28 at 20:25 +0100, Michal Privoznik wrote:
> On 10/28/20 8:16 PM, Andrea Bolognani wrote:
> > On Mon, 2020-10-26 at 00:25 +0300, Roman Bolshakov wrote:
> > > +++ b/src/security/security_util.c
> > > @@ -56,6 +56,8 @@ VIR_LOG_INIT("security.security_util");
> > > # define
As explained in the original commit (31d687a3218c), these values
are actually unaffected by the corresponding _without_* macros
and so we can leave out the additional processing / obfuscation.
This reverts commit ae23a87d85cfc2a964123d9bd44157a411428c0a.
Signed-off-by: Andrea Bolognani
---
On Wed, Oct 28, 2020 at 04:49:43PM -0400, Neal Gompa wrote:
> On Wed, Oct 28, 2020 at 8:36 AM Daniel P. Berrangé
> wrote:
> >
> > The %meson macro sets "--auto-features=enabled", thus any feature in the
> > RPM which has a "with_XXX" condition, needs to explicitly pass a
> > "-DXXX=state" arg to
On Thu, Oct 22, 2020 at 17:46:28 +0300, Nikolay Shirokovskiy wrote:
>
>
> On 22.10.2020 15:12, Peter Krempa wrote:
> > On Tue, Oct 20, 2020 at 16:44:07 +0300, Nikolay Shirokovskiy wrote:
> >> Currently in qemuProcessHandleBlockJob we either offload blockjob event
> >> processing to the worker
27 matches
Mail list logo