flight 144689 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144689/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 144517
build-i386-libvirt
On 11.12.19 08:28, Jan Beulich wrote:
Jürgen, Boris,
I've noticed
<6>clocksource: Switched to clocksource tsc
as the final clocksource related boot message in a PV Dom0's
log with 5.4.2. Is it intentional that it's not the "xen" one
that gets used by default?
I think this is fine. I just tes
On 11.12.2019 09:16, Jürgen Groß wrote:
> On 11.12.19 08:28, Jan Beulich wrote:
>> Jürgen, Boris,
>>
>> I've noticed
>>
>> <6>clocksource: Switched to clocksource tsc
>>
>> as the final clocksource related boot message in a PV Dom0's
>> log with 5.4.2. Is it intentional that it's not the "xen" one
Add core scheduling feature to SUPPORT.md.
Signed-off-by: Juergen Gross
---
SUPPORT.md | 8
1 file changed, 8 insertions(+)
diff --git a/SUPPORT.md b/SUPPORT.md
index 1cad7d6164..169b6f8fcf 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -255,6 +255,14 @@ of using different schedulers and
On 11/12/2019 07:41, Jan Beulich wrote:
> On 10.12.2019 18:55, Andrew Cooper wrote:
>> On 10/12/2019 08:55, Jan Beulich wrote:
>>> On 09.12.2019 18:49, Andrew Cooper wrote:
On 09/12/2019 16:52, Jan Beulich wrote:
> On 05.12.2019 23:30, Andrew Cooper wrote:
>> Some hypercalls tasklets w
The legacy / compatibility mode ES, CS, SS, and DS overrides are null
prefixes in 64-bit mode, i.e. they in particular don't cancel an
earlier FS or GS one.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -2830,14 +2830,17 @
AMD and friends explicitly specify that 64-bit operands aren't possible
for these insns. Nevertheless REX.W isn't fully ignored: It still
cancels a possible operand size override (0x66). Intel otoh explicitly
provides for 64-bit operands on the respective insn page of the SDM.
Signed-off-by: Jan B
On 11.12.2019 09:45, Juergen Gross wrote:
> Add core scheduling feature to SUPPORT.md.
>
> Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-
On 10.12.2019 23:40, Eslam Elnikety wrote:
> On 10.12.19 10:21, Jan Beulich wrote:
>> On 09.12.2019 22:49, Eslam Elnikety wrote:
>>> On 09.12.19 16:19, Andrew Cooper wrote:
On 09/12/2019 08:41, Eslam Elnikety wrote:
> --- /dev/null
> +++ b/xen/arch/x86/microcode/Makefile
> @@ -0,0
flight 144693 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144693/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 144637
build-i386-xsm
On 11.12.2019 00:18, Eslam Elnikety wrote:
> On 10.12.19 10:37, Jan Beulich wrote:
>> On 09.12.2019 09:41, Eslam Elnikety wrote:
>>> --- a/docs/misc/xen-command-line.pandoc
>>> +++ b/docs/misc/xen-command-line.pandoc
>>> @@ -2113,7 +2113,7 @@ logic applies:
>>> active by default.
>>>
>>>
On Tue, Dec 10, 2019 at 11:33:45AM +, Paul Durrant wrote:
> If a driver probe() fails then leave the xenstore state alone. There is no
> reason to modify it as the failure may be due to transient resource
> allocation issues and hence a subsequent probe() may succeed.
>
> If the driver support
> -Original Message-
> From: Roger Pau Monné
> Sent: 11 December 2019 10:06
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; linux-ker...@vger.kernel.org; Juergen
> Gross ; Stefano Stabellini ;
> Boris Ostrovsky
> Subject: Re: [Xen-devel] [PATCH v2 2/4] xenbus: limit when state
flight 144699 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144699/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 272c18435e93cbf749c096a9552ab5ef0d79a4ca
baseline version:
xen ae25
On 11.12.19 11:14, Durrant, Paul wrote:
-Original Message-
From: Roger Pau Monné
Sent: 11 December 2019 10:06
To: Durrant, Paul
Cc: xen-devel@lists.xenproject.org; linux-ker...@vger.kernel.org; Juergen
Gross ; Stefano Stabellini ;
Boris Ostrovsky
Subject: Re: [Xen-devel] [PATCH v2 2/4]
On Tue, 2019-12-10 at 16:20 +0100, Jan Beulich wrote:
>
> ol2e = l2e_from_intpte(
>l2e_get_intpte(ol2e) + (PAGE_SIZE <<
> PAGETABLE_ORDER));
>
> Of course, as mentioned before, I'm not overly happy to see type
> safety lost in case like this one, where it's not needed
On Tue, Dec 10, 2019 at 11:33:47AM +, Paul Durrant wrote:
> By simply re-attaching to shared rings during connect_ring() rather than
> assuming they are freshly allocated (i.e assuming the counters are zero)
> it is possible for vbd instances to be unbound and re-bound from and to
> (respective
On Wed, Dec 11, 2019 at 04:50:58AM +0100, SeongJae Park wrote:
> On Tue, 10 Dec 2019 11:16:35 +0100 "Roger Pau Monné"
> wrote:
> > > diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h
> > > index 869c816d5f8c..cdb075e4182f 100644
> > > --- a/include/xen/xenbus.h
> > > +++ b/include/xen/xenb
> -Original Message-
> From: Roger Pau Monné
> Sent: 11 December 2019 10:46
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; linux-ker...@vger.kernel.org; Konrad
> Rzeszutek Wilk ; Jens Axboe ;
> Boris Ostrovsky ; Juergen Gross
> ; Stefano Stabellini
> Subject: Re: [PATCH v2 4/4
flight 144703 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144703/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 144637
build-i386-xsm
map_pages_to_xen and modify_xen_mappings are performing almost exactly
the same operations when shattering an l2 PTE, the only difference
being whether we want to flush.
Signed-off-by: Hongyan Xia
---
Changes in v3:
- style and indentation changes.
- return -ENOMEM instead of -1.
Changes in v2:
map_pages_to_xen and modify_xen_mappings are performing almost exactly
the same operations when shattering an l3 PTE, the only difference
being whether we want to flush.
Signed-off-by: Hongyan Xia
---
Changes in v3:
- style and indentation changes.
- return -ENOMEM instead of -1.
Changes in v2:
map_pages_to_xen and modify_xen_mappings use almost exactly the same
page shattering logic, and the code is mingled with other PTE
manipulations so it is less obvious that the intention is page
shattering. Factor out the functions to make them reusable and to make
the intention more obvious.
Of co
And this time with the correct list. Really despairing with Outlook which keeps
adding random old contacts to my address book and puts them in front of
frequently used entries (sigh)
From: Lars Kurth
Date: Wednesday, 11 December 2019 at 10:31
To: "xen-de...@lists.xensource.com" ,
"mirageos-de.
On Tue, 2019-12-10 at 16:20 +0100, Jan Beulich wrote:
> On 09.12.2019 12:48, Hongyan Xia wrote:
> > --- a/xen/arch/x86/mm.c
> > +++ b/xen/arch/x86/mm.c
> > @@ -5151,6 +5151,51 @@ l1_pgentry_t *virt_to_xen_l1e(unsigned long
> > v)
> > flush_area_local((const void *)v, f) :
Hi Hongyan,
On 11/12/2019 10:28, Xia, Hongyan wrote:
On Tue, 2019-12-10 at 16:20 +0100, Jan Beulich wrote:
ol2e = l2e_from_intpte(
l2e_get_intpte(ol2e) + (PAGE_SIZE <<
PAGETABLE_ORDER));
Of course, as mentioned before, I'm not overly happy to see type
safety lost
On Tue, Dec 10, 2019 at 04:43:30PM +0100, Jan Beulich wrote:
> On 10.12.2019 16:37, Durrant, Paul wrote:
> >> -Original Message-
> >> From: Xen-devel On Behalf Of Jan
> >> Beulich
> >> Sent: 10 December 2019 15:34
> >> To: Wei Liu
> >> Cc: Wei Liu ; Paul Durrant ; Andrew
> >> Cooper ; Mic
Hello,
I see that you have already sent v6, for future iterations can you
please wait until the conversation on the previous version has been
settled?
I'm still replying to your replies to v5, and hence you should hold off
sending v6 until we get some kind of conclusion/agreement.
On Wed, Dec 11
> -Original Message-
> From: Wei Liu
> Sent: 11 December 2019 11:15
> To: Jan Beulich
> Cc: Durrant, Paul ; Wei Liu ; Wei Liu
> ; Paul Durrant ; Andrew Cooper
> ; Michael Kelley ; Xen
> Development List ; Roger Pau Monné
>
> Subject: Re: [PATCH for-next 1/7] x86: import hyperv-tlfs.h fro
On Wed, 2019-12-11 at 11:10 +, Julien Grall wrote:
> Hi Hongyan,
> ...
>
> While this involves more instructions, how often do we expect the
> code
> to be called?
>
> Cheers,
>
I don't expect this to be called very often in the current Xen.
Although with direct map removal, a lot of the m
On Wed, Dec 11, 2019 at 11:22:49AM +, Durrant, Paul wrote:
> > -Original Message-
> > From: Wei Liu
> > Sent: 11 December 2019 11:15
> > To: Jan Beulich
> > Cc: Durrant, Paul ; Wei Liu ; Wei Liu
> > ; Paul Durrant ; Andrew Cooper
> > ; Michael Kelley ; Xen
> > Development List ; Roger
On Tue, Dec 10, 2019 at 02:53:05PM +, Paul Durrant wrote:
> Objects allocated by xen_blkif_alloc come from the 'blkif_cache' kmem
> cache. This cache is destoyed when xen-blkif is unloaded so it is
> necessary to wait for the deferred free routine used for such objects to
> complete. This neces
On Tue, Dec 10, 2019 at 05:17:28PM +0100, Jan Beulich wrote:
> On 25.10.2019 11:16, Wei Liu wrote:
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -1577,7 +1577,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> > max_cpus = nr_cpu_ids;
> > }
> >
>
flight 144686 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144686/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12
guest-start/debianhvm.repeat fail REGR. v
On Tue, Dec 10, 2019 at 04:35:41PM +0100, Jan Beulich wrote:
> On 25.10.2019 11:16, Wei Liu wrote:
> > Do the following:
> > 1. include xen/types.h and xen/bitops.h
> > 2. fix up invocations of BIT macro
>
> Is it truly BIT(..., UL) in _all_ cases, and not BIT(..., U) in some?
In Linux BIT is
Hi Hongyan,
On 11/12/2019 11:28, Xia, Hongyan wrote:
On Wed, 2019-12-11 at 11:10 +, Julien Grall wrote:
Hi Hongyan,
...
While this involves more instructions, how often do we expect the
code
to be called?
Cheers,
I don't expect this to be called very often in the current Xen.
Although
On Wed, Dec 11, 2019 at 04:26:57AM +, SeongJae Park wrote:
> Granting pages consumes backend system memory. In systems configured
> with insufficient spare memory for those pages, it can cause a memory
> pressure situation. However, finding the optimal amount of the spare
flight 144706 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144706/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 144637
build-i386-xsm
On Wed, 11 Dec 2019 11:51:12 +0100 "Roger Pau Monné"
wrote:
> > On Tue, 10 Dec 2019 11:16:35 +0100 "Roger Pau Monné"
> > wrote:
> > > > diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h
> > > > index 869c816d5f8c..cdb075e4182f 100644
> > > > --- a/include/xen/xenbus.h
> > > > +++ b/incl
On Wed, 11 Dec 2019 12:14:44 +0100 "Roger Pau Monné"
wrote:
>
> I see that you have already sent v6, for future iterations can you
> please wait until the conversation on the previous version has been
> settled?
>
> I'm still replying to your replies to v5, and hence you should hold off
> send
On Wed, Dec 11, 2019 at 04:27:33AM +, SeongJae Park wrote:
> A few of static variables in blkback have 'xen_blkif_' prefix, though it
> is unnecessary for static variables. This commit removes such prefixes.
>
> Signed-off-by: SeongJae Park
Thanks.
Reviewed-by: Roger Pau Monné
__
Hi,
On 09/12/2019 17:37, Andrew Cooper wrote:
On 08/12/2019 12:57, Julien Grall wrote:
Hi Andrew,
On 05/12/2019 22:30, Andrew Cooper wrote:
These hypercalls each use continue_hypercall_on_cpu(), whose API is
about to
switch to use -ERESTART. Update the soon-to-be affected paths to cope,
fold
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2019-19581,CVE-2019-19582 / XSA-307
version 3
find_next_bit() issues
UPDATES IN VERSION 3
Public release.
Updated metadata to add 4.13, updat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2019-19580 / XSA-310
version 3
Further issues with restartable PV type change operations
UPDATES IN VERSION 3
Public release.
Updated metadata to add
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2019-19578 / XSA-309
version 3
Linear pagetable use / entry miscounts
UPDATES IN VERSION 3
Public release.
Updated metadata to add 4.13, upd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2019-19577 / XSA-311
version 4
Bugs in dynamic height handling for AMD IOMMU pagetables
UPDATES IN VERSION 4
Public release.
Re-base 4.12 patch ont
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2019-19583 / XSA-308
version 3
VMX: VMentry failure with debug exceptions and blocked states
UPDATES IN VERSION 3
Public release.
Updated metadata to a
On Wed, 11 Dec 2019 12:46:51 +0100 "Roger Pau Monné"
wrote:
> > Granting pages consumes backend system memory. In systems configured
> > with insufficient spare memory for those pages, it can cause a memory
> > pressure situation. However, finding the optimal amount of the spare
>
On 11.12.19 12:46, Roger Pau Monné wrote:
On Wed, Dec 11, 2019 at 04:26:57AM +, SeongJae Park wrote:
+
return 0;
}
subsys_initcall(xenbus_probe_backend_init);
diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h
index 869c816d5f8c..196260017666 100644
--- a/include/xen/xenbus
Containing still in flight DMA was introduced to work around certain
devices / systems hanging hard upon hitting an IOMMU fault. Passing
through (such) devices (on such systems) is inherently insecure (as
guests could easily arrange for IOMMU faults to occur). Defaulting to
a mode where admins may
On 11/12/2019 13:09, Xen.org security team wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Xen Security Advisory CVE-2019-19577 / XSA-311
>version 4
>
> Bugs in dynamic height handling for AMD IOMMU pagetables
>
>
> CREDIT
> -Original Message-
> From: Roger Pau Monné
> Sent: 11 December 2019 11:29
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; linux-bl...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Konrad Rzeszutek Wilk ;
> Jens Axboe
> Subject: Re: [PATCH] xen-blkback: prevent premature m
> -Original Message-
> From: Jürgen Groß
> Sent: 11 December 2019 10:21
> To: Durrant, Paul ; Roger Pau Monné
>
> Cc: xen-devel@lists.xenproject.org; linux-ker...@vger.kernel.org; Stefano
> Stabellini ; Boris Ostrovsky
>
> Subject: Re: [Xen-devel] [PATCH v2 2/4] xenbus: limit when state
On 11.12.19 14:55, Roger Pau Monné wrote:
On Wed, Dec 11, 2019 at 01:27:42PM +, Durrant, Paul wrote:
-Original Message-
From: Roger Pau Monné
Sent: 11 December 2019 11:29
To: Durrant, Paul
Cc: xen-devel@lists.xenproject.org; linux-bl...@vger.kernel.org; linux-
ker...@vger.kernel.or
On Wed, Dec 11, 2019 at 01:27:42PM +, Durrant, Paul wrote:
> > -Original Message-
> > From: Roger Pau Monné
> > Sent: 11 December 2019 11:29
> > To: Durrant, Paul
> > Cc: xen-devel@lists.xenproject.org; linux-bl...@vger.kernel.org; linux-
> > ker...@vger.kernel.org; Konrad Rzeszutek W
> -Original Message-
> From: Roger Pau Monné
> Sent: 11 December 2019 13:55
> To: Durrant, Paul ; Juergen Gross
> Cc: xen-devel@lists.xenproject.org; linux-bl...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Konrad Rzeszutek Wilk ;
> Jens Axboe
> Subject: Re: [PATCH] xen-blkback: pre
flight 144711 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144711/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 144713 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144713/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 144637
build-i386-xsm
> -Original Message-
> > > diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-
> > blkback/xenbus.c
> > > index e8c5c54e1d26..13d09630b237 100644
> > > --- a/drivers/block/xen-blkback/xenbus.c
> > > +++ b/drivers/block/xen-blkback/xenbus.c
> > > @@ -181,6 +181,8 @@ static i
On 11.12.2019 11:58, Hongyan Xia wrote:
> map_pages_to_xen and modify_xen_mappings are performing almost exactly
> the same operations when shattering an l3 PTE, the only difference
> being whether we want to flush.
>
> Signed-off-by: Hongyan Xia
>
> ---
> Changes in v3:
> - style and indentatio
Patch #1 is clean-up for an apparent mis-feature.
Paul Durrant (4):
xenbus: move xenbus_dev_shutdown() into frontend code...
xenbus: limit when state is forced to closed
xen/interface: re-define FRONT/BACK_RING_ATTACH()
xen-blkback: support dynamic unbind/bind
drivers/block/xen-blkback/x
If a driver probe() fails then leave the xenstore state alone. There is no
reason to modify it as the failure may be due to transient resource
allocation issues and hence a subsequent probe() may succeed.
If the driver supports re-binding then only force state to closed during
remove() only in the
Currently these macros are defined to re-initialize a front/back ring
(respectively) to values read from the shared ring in such a way that any
requests/responses that are added to the shared ring whilst the front/back
is detached will be skipped over. This, in general, is not a desirable
semantic
...and make it static
xenbus_dev_shutdown() is seemingly intended to cause clean shutdown of PV
frontends when a guest is rebooted. Indeed the function waits for a
conpletion which is only set by a call to xenbus_frontend_closed().
This patch removes the shutdown() method from backends and moves
By simply re-attaching to shared rings during connect_ring() rather than
assuming they are freshly allocated (i.e assuming the counters are zero)
it is possible for vbd instances to be unbound and re-bound from and to
(respectively) a running guest.
This has been tested by running:
while true;
On 11.12.2019 11:58, Hongyan Xia wrote:
> @@ -5578,27 +5597,8 @@ int modify_xen_mappings(unsigned long s, unsigned long
> e, unsigned int nf)
> }
>
> /* PAGE1GB: shatter the superpage and fall through. */
> -pl2e = alloc_xen_pagetable();
> -if (
On 11.12.2019 11:58, Hongyan Xia wrote:
> map_pages_to_xen and modify_xen_mappings are performing almost exactly
> the same operations when shattering an l2 PTE, the only difference
> being whether we want to flush.
>
> Signed-off-by: Hongyan Xia
As before comments on patch 1 apply here as well.
On 03.12.2019 06:41, Marek Marczykowski-Górecki wrote:
> QEMU running in a stubdom needs to be able to set INTX_DISABLE, and the
> MSI(-X) enable flags in the PCI config space. This adds an attribute
> 'allow_interrupt_control' which when set for a PCI device allows writes
> to this flag(s). The t
On Wed, Dec 11, 2019 at 01:53:00PM +0100, Jan Beulich wrote:
> Containing still in flight DMA was introduced to work around certain
> devices / systems hanging hard upon hitting an IOMMU fault. Passing
> through (such) devices (on such systems) is inherently insecure (as
> guests could easily arran
On Wed, 2019-12-11 at 16:32 +0100, Jan Beulich wrote:
> On 11.12.2019 11:58, Hongyan Xia wrote:
> > @@ -5578,27 +5597,8 @@ int modify_xen_mappings(unsigned long s,
> > unsigned long e, unsigned int nf)
> > }
> >
> > /* PAGE1GB: shatter the superpage and fall through. */
Hi,
On 04/12/2019 17:10, Hongyan Xia wrote:
From: Wei Liu
We are going to switch to using domheap page for page tables.
A new set of APIs is introduced to allocate, map, unmap and free pages
for page tables.
The allocation and deallocation work on mfn_t but not page_info,
because they are req
On Wed, 2019-12-11 at 16:29 +0100, Jan Beulich wrote:
> > +}
> > +
> > +if ( locking )
> > +spin_lock(&map_pgdir_lock);
> > +if ( (l3e_get_flags(*pl3e) & _PAGE_PRESENT) &&
> > + (l3e_get_flags(*pl3e) & _PAGE_PSE) )
> > +{
> > +l3e_write_atomic(pl3e,
> > +
Hi,
On 10/12/2019 10:42, George Dunlap wrote:
On 12/9/19 1:13 PM, Julien Grall wrote:
Hi all,
I was looking at the Grant Table code over the week-end and noticed
thart XSA-255 [1] introduced some unintended consequences on Arm.
Since the XSA, gnttab_map_frame() will remove the previous mappin
Calling ./configure with python3 being there but no python,
tools/configure will fail. Fix that by defaulting to python and
falling back to python3 or python2.
While at it fix the use of non portable "type -p" by replacing it by
AC_PATH_PROG().
Signed-off-by: Juergen Gross
---
tools/configure.a
On 11.12.2019 17:27, Xia, Hongyan wrote:
> On Wed, 2019-12-11 at 16:32 +0100, Jan Beulich wrote:
>> On 11.12.2019 11:58, Hongyan Xia wrote:
>>> @@ -5578,27 +5597,8 @@ int modify_xen_mappings(unsigned long s,
>>> unsigned long e, unsigned int nf)
>>> }
>>>
>>> /* PAGE1GB:
On 11.12.2019 17:34, Xia, Hongyan wrote:
> On Wed, 2019-12-11 at 16:29 +0100, Jan Beulich wrote:
>>> +}
>>> +
>>> +if ( locking )
>>> +spin_lock(&map_pgdir_lock);
>>> +if ( (l3e_get_flags(*pl3e) & _PAGE_PRESENT) &&
>>> + (l3e_get_flags(*pl3e) & _PAGE_PSE) )
>>> +{
>>
flight 144719 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144719/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Each `blkif` has a free pages pool for the grant mapping. The size of
the pool starts from zero and be increased on demand while processing
the I/O requests. If current I/O requests handling is finished or 100
milliseconds has passed since last I/O requests handling, it checks and
shrinks the poo
A few of static variables in blkback have 'xen_blkif_' prefix, though it
is unnecessary for static variables. This commit removes such prefixes.
Reviewed-by: Roger Pau Monné
Signed-off-by: SeongJae Park
---
drivers/block/xen-blkback/blkback.c | 37 +
1 file changed,
Granting pages consumes backend system memory. In systems configured
with insufficient spare memory for those pages, it can cause a memory
pressure situation. However, finding the optimal amount of the spare
memory is challenging for large systems having dynamic resource
utilization patterns. Al
Granting pages consumes backend system memory. In systems configured
with insufficient spare memory for those pages, it can cause a memory
pressure situation. However, finding the optimal amount of the spare
memory is challenging for large systems having dynamic resource
utilization patterns. Al
flight 144708 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144708/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-shadow 18 guest-localmigrate/x10 fail REGR. vs. 144673
Tests which di
flight 144718 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144718/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 144637
build-i386-xsm
On 10/12/2019 10:07, Jan Beulich wrote:
> On 10.12.2019 10:59, Andrew Cooper wrote:
>> On 09/12/2019 18:06, Roger Pau Monne wrote:
>>> Currently cr4 is not cached before suspension, and mmu_cr4_features is
>>> used in order to restore the expected cr4 value. This is correct so
>>> far because the t
On 12/5/2019 3:28 PM, Julien Grall wrote:
> Hi,
>
> On 05/12/2019 19:17, Jeff Kubascik wrote:
>> On 12/3/2019 1:04 PM, Julien Grall wrote:
>>> Hi,
>>>
>>> On 26/11/2019 21:13, Jeff Kubascik wrote:
The physical timer traps apply an offset so that time starts at 0 for
the guest. However, t
On 11/12/2019 19:36, Andrew Cooper wrote:
> Absolutely nothing remaining in suspend.c should be spilled. It can all
> be (re)caluclated from the same information source as the AP boot path,
> and the result will be strictly smaller in RAM, and more robust.
And at a cursory glance, the logic in su
Hi Jens, James and Martin,
This series concludes the work I did for linux-5.5 on the compat_ioctl()
cleanup, killing off fs/compat_ioctl.c and block/compat_ioctl.c by moving
everything into drivers.
Overall this would be a reduction both in complexity and line count, but
as I'm also adding docume
Various block drivers implement the CDROMMULTISESSION,
CDROM_GET_CAPABILITY, and CDROMEJECT ioctl commands, relying on the
block layer to handle compat_ioctl mode for them.
Move this into the drivers directly as a preparation for simplifying
the block layer later.
Since some of these commands nee
On 11/12/2019 09:27, Jan Beulich wrote:
> The legacy / compatibility mode ES, CS, SS, and DS overrides are null
> prefixes in 64-bit mode, i.e. they in particular don't cancel an
> earlier FS or GS one.
>
> Signed-off-by: Jan Beulich
null is a very overloaded term. What you mean here is simply "
On 11/12/2019 09:28, Jan Beulich wrote:
> AMD and friends explicitly specify that 64-bit operands aren't possible
> for these insns. Nevertheless REX.W isn't fully ignored: It still
> cancels a possible operand size override (0x66). Intel otoh explicitly
> provides for 64-bit operands on the respec
This patch set improves the emulation of the physical timer by removing the
physical timer offset and sign extend the TimerValue to better match the
behavior described in the ARMv8 Reference Manual (ARM DDI 0487E.a), section
D11.2.4.
Changes in v2:
- Update commit message to specify reference manu
Per the ARMv8 Reference Manual (ARM DDI 0487E.a), section D11.2.4
specifies that the values in the TimerValue view of the timers are
signed in standard two's complement form. When writing to the TimerValue
register, it should be signed extended as described by the equation
CompareValue = (Count
The physical timer traps apply an offset so that time starts at 0 for
the guest. However, this offset is not currently applied to the physical
counter. Per the ARMv8 Reference Manual (ARM DDI 0487E.a), section
D11.2.4 Timers, the "Offset" between the counter and timer should be
zero for a physical
Hello,
The issue I'm seeing is that pages of previously-xenballooned memory are getting
trapped in the balloon on free, specifically when they are free'd in batches
(i.e. not all at once). The first batch is restored to the domain properly, but
subsequent frees are not.
Truthfully I'm not sure if
branch xen-unstable
xenbranch xen-unstable
job build-amd64-xsm
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xe
flight 144712 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144712/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 144668
Tests which did not succeed
flight 144716 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144716/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail never pass
test-amd64-i386-xl
On 11.12.19 16:29, Paul Durrant wrote:
If a driver probe() fails then leave the xenstore state alone. There is no
reason to modify it as the failure may be due to transient resource
allocation issues and hence a subsequent probe() may succeed.
If the driver supports re-binding then only force st
On 11.12.19 16:29, Paul Durrant wrote:
Currently these macros are defined to re-initialize a front/back ring
(respectively) to values read from the shared ring in such a way that any
requests/responses that are added to the shared ring whilst the front/back
is detached will be skipped over. This,
On 11.12.19 16:29, Paul Durrant wrote:
By simply re-attaching to shared rings during connect_ring() rather than
assuming they are freshly allocated (i.e assuming the counters are zero)
it is possible for vbd instances to be unbound and re-bound from and to
(respectively) a running guest.
This ha
1 - 100 of 103 matches
Mail list logo
