flight 144770 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144770/
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 12.12.19 23:35, osstest service owner wrote:
flight 144736 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144736/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit1 7 xen-boot
On 10.12.19 15:53, 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 necessity was missed in commit 148
On 12.12.19 07:04, Jürgen Groß wrote:
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
> -Original Message-
> From: Jürgen Groß
> Sent: 13 December 2019 09:00
> To: Durrant, Paul ; xen-devel@lists.xenproject.org;
> linux-bl...@vger.kernel.org; linux-ker...@vger.kernel.org
> Cc: Boris Ostrovsky ; Stefano Stabellini
>
> Subject: Re: [PATCH v3 3/4] xen/interface: re-define
> F
> -Original Message-
> From: Jürgen Groß
> Sent: 13 December 2019 05:41
> To: David Miller ; Durrant, Paul
>
> Cc: xen-devel@lists.xenproject.org; wei@kernel.org; linux-
> ker...@vger.kernel.org; net...@vger.kernel.org
> Subject: Re: [Xen-devel] [PATCH net-next] xen-netback: get rid o
On Thu, Dec 12, 2019 at 05:06:58PM +0100, SeongJae Park wrote:
> On Thu, 12 Dec 2019 16:27:57 +0100 "Roger Pau Monné"
> wrote:
>
> > > diff --git a/drivers/block/xen-blkback/blkback.c
> > > b/drivers/block/xen-blkback/blkback.c
> > > index fd1e19f1a49f..98823d150905 100644
> > > --- a/drivers/b
On 13.12.19 10:27, Roger Pau Monné wrote:
On Thu, Dec 12, 2019 at 05:06:58PM +0100, SeongJae Park wrote:
On Thu, 12 Dec 2019 16:27:57 +0100 "Roger Pau Monné"
wrote:
diff --git a/drivers/block/xen-blkback/blkback.c
b/drivers/block/xen-blkback/blkback.c
index fd1e19f1a49f..98823d150905 100644
On 12.12.2019 23:17, Eslam Elnikety wrote:
> On the "newest of everything": That's not what I intend to propose. The
> microcode provided via a scan (or for that matter) will always
> override the builtin microcode. The common case would be that the
> microcode provided via a scan (or ) is newe
On 13.12.19 10:24, Durrant, Paul wrote:
-Original Message-
From: Jürgen Groß
Sent: 13 December 2019 05:41
To: David Miller ; Durrant, Paul
Cc: xen-devel@lists.xenproject.org; wei@kernel.org; linux-
ker...@vger.kernel.org; net...@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH net-ne
On 03.12.2019 10:14, Jan Beulich wrote:
> On 02.12.2019 15:40, Alexandru Stefan ISAILA wrote:
>> On 29.11.2019 13:31, Jan Beulich wrote:
>>> On 21.11.2019 16:02, Alexandru Stefan ISAILA wrote:
@@ -4711,6 +4712,18 @@ static int do_altp2m_op(
}
break;
>
On 03.12.2019 10:14, Jan Beulich wrote:
> On 02.12.2019 15:40, Alexandru Stefan ISAILA wrote:
>> On 29.11.2019 13:31, Jan Beulich wrote:
>>> On 21.11.2019 16:02, Alexandru Stefan ISAILA wrote:
@@ -4711,6 +4712,18 @@ static int do_altp2m_op(
}
break;
>
> -Original Message-
> From: Jürgen Groß
> Sent: 13 December 2019 10:02
> To: Durrant, Paul ; David Miller
>
> Cc: xen-devel@lists.xenproject.org; wei@kernel.org; linux-
> ker...@vger.kernel.org; net...@vger.kernel.org
> Subject: Re: [Xen-devel] [PATCH net-next] xen-netback: get rid o
The version of this header present in the Linux source tree has contained
such macros for some time. These macros, as the names imply, allow front
or back rings to be set up for existent (rather than freshly created and
zeroed) shared rings.
This patch is to update this, the canonical version of t
On 13.12.19 11:18, Paul Durrant wrote:
The version of this header present in the Linux source tree has contained
such macros for some time. These macros, as the names imply, allow front
or back rings to be set up for existent (rather than freshly created and
zeroed) shared rings.
This patch is t
On 12.12.2019 18:32, George Dunlap wrote:
> Both put_page_from_l2e and put_page_from_l3e handle having superpage
> entries by looping over each page and "put"-ing each one individually.
> As with putting page table entries, this code is functionally
> identical, but for some reason different. More
On 12.12.2019 21:07, Andrew Cooper wrote:
> On 12/12/2019 17:32, George Dunlap wrote:
>> The functions alloc_page_type(), alloc_lN_table(), free_page_type()
>> and free_lN_table() are confusingly named:
>
> There is alloc_segdesc_page() which should be adjusted for consistency.
>
>> nothing is be
Just two minor remarks:
On 12.12.2019 19:27, Anthony PERARD wrote:
> --- /dev/null
> +++ b/docs/misc/kconfig-macro-language.rst
> @@ -0,0 +1,247 @@
> +==
> +Kconfig macro language
> +==
> +
> +Concept
> +---
> +
> +The basic idea was inspired by Make. Wh
On 12.12.2019 19:27, Anthony PERARD wrote:
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -32,6 +32,9 @@ config ARCH_DEFCONFIG
> string
> default "arch/x86/configs/x86_64_defconfig"
>
> +config INDIRECT_THUNK
> + def_bool $(cc-option,-mindirect-branch-register)
I'
Hi Juergen,
On 13/12/2019 08:31, Jürgen Groß wrote:
On 12.12.19 23:35, osstest service owner wrote:
flight 144736 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144736/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
On 13.12.19 12:14, Julien Grall wrote:
Hi Juergen,
On 13/12/2019 08:31, Jürgen Groß wrote:
On 12.12.19 23:35, osstest service owner wrote:
flight 144736 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144736/
Regressions :-(
Tests which did not succeed and are b
On 12.12.2019 20:04, Andrew Cooper wrote:
> On 12/12/2019 18:27, Anthony PERARD wrote:
>> diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
>> index ff6c0f5cdd18..8c846261d241 100644
>> --- a/xen/include/xen/compiler.h
>> +++ b/xen/include/xen/compiler.h
>> @@ -78,7 +78,7 @@
>>
On 13/12/2019 11:24, Jürgen Groß wrote:
On 13.12.19 12:14, Julien Grall wrote:
Hi Juergen,
On 13/12/2019 08:31, Jürgen Groß wrote:
On 12.12.19 23:35, osstest service owner wrote:
flight 144736 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144736/
Regressions
flight 144758 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144758/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs.
144545
Tests wh
Julien Grall writes ("Re: [Xen-devel] [xen-4.13-testing test] 144736:
regressions - FAIL"):
> AMD Seattle boards (laxton*) are known to fail booting time to time
> because of PCI training issue. We have workaround for it (involving
> longer power cycle) but this is not 100% reliable.
This wasn'
On 12.12.2019 18:18, Ian Jackson wrote:
> osstest service owner writes ("[xen-4.9-testing test] 144723: regressions -
> trouble: fail/pass/starved"):
>> flight 144723 xen-4.9-testing real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/144723/
>>
>> Regressions :-(
>>
>> Tests which did
On Fri, Dec 13, 2019 at 10:33 AM Jürgen Groß wrote:
>
> On 13.12.19 10:27, Roger Pau Monné wrote:
> > On Thu, Dec 12, 2019 at 05:06:58PM +0100, SeongJae Park wrote:
> >> On Thu, 12 Dec 2019 16:27:57 +0100 "Roger Pau Monné"
> >> wrote:
> >>
> diff --git a/drivers/block/xen-blkback/blkback.c
Jan Beulich writes ("Re: [xen-4.9-testing test] 144723: regressions - trouble:
fail/pass/starved"):
> On 12.12.2019 18:18, Ian Jackson wrote:
> > osstest service owner writes ("[xen-4.9-testing test] 144723: regressions -
> > trouble: fail/pass/starved"):
> >> flight 144723 xen-4.9-testing real [
flight 144782 xen-4.9-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/144782/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-amd64-pvgrub queued
test-amd64-i386-
> On Dec 13, 2019, at 10:48 AM, Jan Beulich wrote:
>
> On 12.12.2019 21:07, Andrew Cooper wrote:
>> On 12/12/2019 17:32, George Dunlap wrote:
>>> The functions alloc_page_type(), alloc_lN_table(), free_page_type()
>>> and free_lN_table() are confusingly named:
>>
>> There is alloc_segdesc_page
On Fri, Dec 13, 2019 at 12:13:53PM +0100, Jan Beulich wrote:
> On 12.12.2019 19:27, Anthony PERARD wrote:
> > --- a/xen/arch/x86/Kconfig
> > +++ b/xen/arch/x86/Kconfig
> > @@ -32,6 +32,9 @@ config ARCH_DEFCONFIG
> > string
> > default "arch/x86/configs/x86_64_defconfig"
> >
> > +config IN
On 13.12.2019 13:00, George Dunlap wrote:
>
>
>> On Dec 13, 2019, at 10:48 AM, Jan Beulich wrote:
>>
>> On 12.12.2019 21:07, Andrew Cooper wrote:
>>> On 12/12/2019 17:32, George Dunlap wrote:
The functions alloc_page_type(), alloc_lN_table(), free_page_type()
and free_lN_table() are co
On 13.12.2019 13:18, Anthony PERARD wrote:
> On Fri, Dec 13, 2019 at 12:13:53PM +0100, Jan Beulich wrote:
>> On 12.12.2019 19:27, Anthony PERARD wrote:
>>> --- a/xen/arch/x86/Kconfig
>>> +++ b/xen/arch/x86/Kconfig
>>> @@ -32,6 +32,9 @@ config ARCH_DEFCONFIG
>>> string
>>> default "arch/x86/
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
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 13/12/2019 12:54, 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
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
Each `blkif` has a free pages pool for the grant mapping. The size of
the pool starts from zero and is 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,
This patch adds a specification for a 'carrier' node in xenstore to allow
a backend to notify a frontend of it's virtual carrier/link state. E.g.
a backend that is unable to forward packets from the guest because it is
not attached to a bridge may wish to advertise 'no carrier'.
NOTE: This is pure
On 13.12.2019 14:01, Andrew Cooper wrote:
> On 13/12/2019 12:54, 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 explicit
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 13 December 2019 12:53
> To: xen-devel@lists.xenproject.org
> Cc: Juergen Gross ; Kevin Tian ;
> Stefano Stabellini ; Julien Grall
> ; Wei Liu ; Konrad Wilk
> ; George Dunlap ;
> Andrew Cooper ; Paul Durrant ;
> Ian
On 13.12.19 13:53, 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 arrange for IOMMU faults to occur)
In function xenvif_disconnect_queue(), the value of queue->rx_irq is
zeroed *before* queue->task is stopped. Unfortunately that task may call
notify_remote_via_irq(queue->rx_irq) and calling that function with a
zero value results in a NULL pointer dereference in evtchn_from_irq().
This patch simp
On 13.12.2019 14:11, Jürgen Groß wrote:
> On 13.12.19 13:53, 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
>> gu
On 13.12.2019 14:12, Durrant, Paul wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 13 December 2019 12:53
>> To: xen-devel@lists.xenproject.org
>> Cc: Juergen Gross ; Kevin Tian ;
>> Stefano Stabellini ; Julien Grall
>> ; Wei Liu ; Konrad Wilk
>> ; Geor
> -Original Message-
> From: Jan Beulich
> Sent: 13 December 2019 13:26
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Juergen Gross ; Kevin
> Tian ; Stefano Stabellini ;
> Julien Grall ; Wei Liu ; Konrad Wilk
> ; George Dunlap ;
> Andrew Cooper ; Paul Durrant ;
> Ian Jackson ;
On 13.12.19 14:21, Jan Beulich wrote:
On 13.12.2019 14:11, Jürgen Groß wrote:
On 13.12.19 13:53, 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) i
On 13.12.2019 14:29, Durrant, Paul wrote:
>> From: Jan Beulich
>> Sent: 13 December 2019 13:26
>>
>> On 13.12.2019 14:12, Durrant, Paul wrote:
From: Xen-devel On Behalf Of Jan
Beulich
Sent: 13 December 2019 12:53
+#define IOMMU_quarantine_none 0
+#define IOMMU_quara
On 13.12.2019 14:31, Jürgen Groß wrote:
> On 13.12.19 14:21, Jan Beulich wrote:
>> On 13.12.2019 14:11, Jürgen Groß wrote:
>>> On 13.12.19 13:53, Jan Beulich wrote:
Containing still in flight DMA was introduced to work around certain
devices / systems hanging hard upon hitting an IOMMU fa
On 09/12/2019 21:49, Eslam Elnikety wrote:
>>> +
>>> +extern const char __builtin_intel_ucode_start[],
>>> __builtin_intel_ucode_end[];
>>> +extern const char __builtin_amd_ucode_start[],
>>> __builtin_amd_ucode_end[];
>>> +#endif
>>> +
>>> /* By default, ucode loading is done in NMI handler */
>
On 13.12.19 14:38, Jan Beulich wrote:
On 13.12.2019 14:31, Jürgen Groß wrote:
On 13.12.19 14:21, Jan Beulich wrote:
On 13.12.2019 14:11, Jürgen Groß wrote:
On 13.12.19 13:53, Jan Beulich wrote:
Containing still in flight DMA was introduced to work around certain
devices / systems hanging hard
> -Original Message-
> From: Xen-devel On Behalf Of
> Jürgen Groß
> Sent: 13 December 2019 13:47
> To: Jan Beulich
> Cc: Kevin Tian ; Stefano Stabellini
> ; Julien Grall ; Wei Liu
> ; Konrad Wilk ; George Dunlap
> ; Andrew Cooper ;
> Paul Durrant ; Ian Jackson ; xen-
> de...@lists.xenproj
On 12/12/2019 22:13, Eslam Elnikety wrote:
>>> Second, there is often need to couple a Xen build with a minimum
>>> microcode patch level. Having the microcode built within the Xen image
>>> itself is a streamlined, natural way of achieving that.
>>
>> Okay, I can accept this as a reason, to some d
> On Dec 12, 2019, at 7:57 PM, Andrew Cooper wrote:
>
> On 12/12/2019 17:32, George Dunlap wrote:
>> Both put_page_from_l2e and put_page_from_l3e handle having superpage
>> entries by looping over each page and "put"-ing each one individually.
>> As with putting page table entries, this code is
On 13.12.2019 14:46, Jürgen Groß wrote:
> On 13.12.19 14:38, Jan Beulich wrote:
>> On 13.12.2019 14:31, Jürgen Groß wrote:
>>> Maybe I have misunderstood the current state, but I thought that it
>>> would just silently hide quirky devices without imposing a security
>>> risk. We would not learn whi
On Fri, Dec 13, 2019 at 01:53:29PM +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 13.12.19 14:03, Paul Durrant wrote:
This patch adds a specification for a 'carrier' node in xenstore to allow
a backend to notify a frontend of it's virtual carrier/link state. E.g.
a backend that is unable to forward packets from the guest because it is
not attached to a bridge may wish to ad
On 12/12/2019 12:46, Hongyan Xia wrote:
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 7d4dd80a85..8def4fb8d8 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -5151,6 +5151,52 @@ l1_pgentry_t *virt_to_xen_l1e(unsigned long v)
> flush_area_local
On 13.12.2019 14:53, Durrant, Paul wrote:
> Since *not* having the 'sink' page allows a guest pull off a host DoS
> in the presence of such h/w, security is surely increased by having it?
hostdevice result w/o sink result w/ sink
goodgoodgood
On 13.12.19 15:11, Jan Beulich wrote:
On 13.12.2019 14:46, Jürgen Groß wrote:
On 13.12.19 14:38, Jan Beulich wrote:
On 13.12.2019 14:31, Jürgen Groß wrote:
Maybe I have misunderstood the current state, but I thought that it
would just silently hide quirky devices without imposing a security
ri
On 13.12.19 15:23, Jan Beulich wrote:
On 13.12.2019 14:53, Durrant, Paul wrote:
Since *not* having the 'sink' page allows a guest pull off a host DoS
in the presence of such h/w, security is surely increased by having it?
hostdevice result w/o sink result w/ sink
g
On Fri, Dec 13, 2019 at 01:02:10PM +, SeongJae Park wrote:
> Each `blkif` has a free pages pool for the grant mapping. The size of
> the pool starts from zero and is increased on demand while processing
> the I/O requests. If current I/O requests handling is finished or 100
> milliseconds has
On 13.12.2019 15:19, Andrew Cooper wrote:
> On 12/12/2019 12:46, Hongyan Xia wrote:
>> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
>> index 7d4dd80a85..8def4fb8d8 100644
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -5151,6 +5151,52 @@ l1_pgentry_t *virt_to_xen_l1e(unsigned lon
On 12/12/2019 13:16, Jan Beulich wrote:
> On 12.12.2019 13:46, Hongyan Xia wrote:
>> 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.
On Thu, Dec 12, 2019 at 07:00:35PM +, Andrew Cooper wrote:
> On 12/12/2019 18:27, Anthony PERARD wrote:
> > Kconfig can check if $(CC) is clang or not, if it is
> > CONFIG_CC_IS_CLANG will be set.
> >
> > With that patch, the hypervisor can be built using clang by running
> > `make CC=clang CXX
On 13.12.2019 15:29, Jürgen Groß wrote:
> On 13.12.19 15:23, Jan Beulich wrote:
>> On 13.12.2019 14:53, Durrant, Paul wrote:
>>> Since *not* having the 'sink' page allows a guest pull off a host DoS
>>> in the presence of such h/w, security is surely increased by having it?
>>
>> host devic
On 13.12.2019 15:24, Jürgen Groß wrote:
> On 13.12.19 15:11, Jan Beulich wrote:
>> On 13.12.2019 14:46, Jürgen Groß wrote:
>>> On 13.12.19 14:38, Jan Beulich wrote:
On 13.12.2019 14:31, Jürgen Groß wrote:
> Maybe I have misunderstood the current state, but I thought that it
> would jus
On Thu, Dec 12, 2019 at 06:30:43PM +, Andrew Cooper wrote:
> On 12/12/2019 18:27, Anthony PERARD wrote:
> > diff --git a/docs/misc/distro_mapping.txt b/docs/misc/distro_mapping.txt
> > index 2e46592728e3..599b6fd1e912 100644
> > --- a/docs/misc/distro_mapping.txt
> > +++ b/docs/misc/distro_mapp
On 13/12/2019 14:36, Jan Beulich wrote:
> On 13.12.2019 15:19, Andrew Cooper wrote:
>> On 12/12/2019 12:46, Hongyan Xia wrote:
>>> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
>>> index 7d4dd80a85..8def4fb8d8 100644
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -5151,6 +5151,
On Fri, 13 Dec 2019 15:34:35 +0100 "Roger Pau Monné"
wrote:
> > Each `blkif` has a free pages pool for the grant mapping. The size of
> > the pool starts from zero and is increased on demand while processing
> > the I/O requests. If current I/O requests handling is finished or 100
> > millisec
On 13/12/2019 13:58, George Dunlap wrote:
>
>> On Dec 12, 2019, at 7:57 PM, Andrew Cooper wrote:
>>
>> On 12/12/2019 17:32, George Dunlap wrote:
>>> Both put_page_from_l2e and put_page_from_l3e handle having superpage
>>> entries by looping over each page and "put"-ing each one individually.
>>> A
On Thu, Dec 12, 2019 at 06:32:27PM +, Andrew Cooper wrote:
> On 12/12/2019 18:27, Anthony PERARD wrote:
> > This comment isn't about CONFIG_TESTS, but about SEABIOS_DIR that has
> > been removed.
> >
> > Originally, the comment was added by 5f82d0858de1 ("tools: support
> > SeaBIOS. Use by defa
On Thu, Dec 12, 2019 at 06:45:02PM +, Andrew Cooper wrote:
> On 12/12/2019 18:27, Anthony PERARD wrote:
> > Dependency change:
> > - Now depends on flex/bison, maybe we could _shipped those files like
> > before. Linux doesn't do that anymore.
>
> Content like that should not be checked in t
> -Original Message-
> From: Jürgen Groß
> Sent: 13 December 2019 14:17
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Cc: Konrad Rzeszutek Wilk
> Subject: Re: [PATCH] public/io/netif.h: document a mechanism to advertise
> carrier state
>
> On 13.12.19 14:03, Paul Durrant 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
memory is challenging for large systems having dynamic resource
utilization patterns. Al
On 13.12.19 15:45, Jan Beulich wrote:
On 13.12.2019 15:24, Jürgen Groß wrote:
On 13.12.19 15:11, Jan Beulich wrote:
On 13.12.2019 14:46, Jürgen Groß wrote:
On 13.12.19 14:38, Jan Beulich wrote:
On 13.12.2019 14:31, Jürgen Groß wrote:
Maybe I have misunderstood the current state, but I though
Each `blkif` has a free pages pool for the grant mapping. The size of
the pool starts from zero and is 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
The number of empty lines between functions in the xenbus.c is
inconsistent. This trivial style cleanup commit fixes the file to
consistently place only one empty line.
Signed-off-by: SeongJae Park
---
drivers/block/xen-blkback/xenbus.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(
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
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,
+Anthony
On 13/12/2019 11:40, Ian Jackson wrote:
Julien Grall writes ("Re: [Xen-devel] [xen-4.13-testing test] 144736: regressions -
FAIL"):
AMD Seattle boards (laxton*) are known to fail booting time to time
because of PCI training issue. We have workaround for it (involving
longer power cycl
On Fri, Dec 13, 2019 at 12:05:11PM +0100, Jan Beulich wrote:
> Just two minor remarks:
>
> On 12.12.2019 19:27, Anthony PERARD wrote:
> > --- /dev/null
> > +++ b/docs/misc/kconfig-macro-language.rst
[...]
> > +Then, Kconfig moves onto the evaluation stage to resolve inter-symbol
> > +dependency as
This patch adds a specification for a 'carrier' node in xenstore to allow
a backend to notify a frontend of it's virtual carrier/link state. E.g.
a backend that is unable to forward packets from the guest because it is
not attached to a bridge may wish to advertise 'no carrier'.
While in the area
> -Original Message-
> From: Xen-devel On Behalf Of
> Julien Grall
> Sent: 13 December 2019 15:37
> To: Ian Jackson
> Cc: Jürgen Groß ; xen-devel@lists.xenproject.org; Stefano
> Stabellini ; osstest service owner ad...@xenproject.org>; Anthony Perard
> Subject: Re: [Xen-devel] [xen-4.13
Hi,
On Fri, 2019-12-13 at 14:19 +, Andrew Cooper wrote:
> On 12/12/2019 12:46, Hongyan Xia wrote:
> > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> > index 7d4dd80a85..8def4fb8d8 100644
> > --- a/xen/arch/x86/mm.c
> > +++ b/xen/arch/x86/mm.c
> > @@ -5151,6 +5151,52 @@ l1_pgentry_t *virt
On 13.12.19 16:51, Paul Durrant wrote:
This patch adds a specification for a 'carrier' node in xenstore to allow
a backend to notify a frontend of it's virtual carrier/link state. E.g.
a backend that is unable to forward packets from the guest because it is
not attached to a bridge may wish to ad
On Fri, 2019-12-13 at 14:58 +, Andrew Cooper wrote:
> On 13/12/2019 14:36, Jan Beulich wrote:
> > On 13.12.2019 15:19, Andrew Cooper wrote:
> > > On 12/12/2019 12:46, Hongyan Xia wrote:
> > > > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> > > > index 7d4dd80a85..8def4fb8d8 100644
> > >
On Thu, Dec 12, 2019 at 06:56:00PM +, Andrew Cooper wrote:
> On 12/12/2019 18:27, Anthony PERARD wrote:
> > diff --git a/xen/Makefile b/xen/Makefile
> > index efbe9605e52b..0cf4ded9d9d4 100644
> > --- a/xen/Makefile
> > +++ b/xen/Makefile
> > @@ -267,6 +267,7 @@ $(foreach base,arch/x86/mm/guest
Convert the deprecated DPRINTF() macro to trace events.
Signed-off-by: Philippe Mathieu-Daudé
---
v2: rename pc_pic -> x86_pic
---
hw/i386/pc.c | 19 +--
hw/i386/trace-events | 6 ++
2 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i
Hi Paolo,
Since you posted your "x86: allow building without PC machine
types" series [1], I looked at my past work on this topic
(restrict "hw/i386/pc.h" to the X86 architecture).
I'm glad to see in [2] you remove most (all) of the last uses.
Since I haven't looked at this for some time, my WiP b
Move the KVM-related call to "sysemu/kvm.h".
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/pc.h | 1 -
include/sysemu/kvm.h | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 1f86eba3f9..9866dfbd60 100644
--- a/includ
In commit f809c6051 we replaced the use of cpu_set_smm_t callbacks
by using a Notifier to modify the MemoryRegion. This prototype is
now not used anymore, we can safely remove it.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/pc.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/
The "pcie_host.h" header is used by devices providing a PCI-e bus,
usually North Bridges. The ICH9 is a South Bridge.
Since we don't need this header, do not include it.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/ich9.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/hw
In commit 1454509726 we removed the pc_pci_device_init()
deprecated function and its calls, but we forgot to remove
its prototype. Do that now.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/pc.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/hw/i386/pc.h b/include/hw/i386
While the ICH9 chipset is a 'South Bridge', it is not a PCI bridge.
Nothing in "hw/i386/ich9.h" requires definitions from "pci_bridge.h"
so move its inclusion where it is required.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/ich9.h| 1 -
hw/i386/acpi-build.c | 1 +
hw/pci-
Commit 02a9594b4f0 already converted 'dev' to DeviceState.
Since the cast is superfluous, remove it.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/ide/piix.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/ide/piix.c b/hw/ide/piix.c
index db313dd3b1..ffeff4e095 100644
---
Since commit 0c8465440 the ioapic_print_redtbl() function is not
used outside of ioapic_common.c, make it static, and remove its
prototype declaration in "ioapic_internal.h".
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/ioapic_internal.h | 1 -
hw/intc/ioapic_common.c | 2
All the X86 machines use an interrupt controller.
Rename the function to something more generic.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/pc.h | 2 +-
hw/i386/microvm.c| 2 +-
hw/i386/pc.c | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/inclu
1 - 100 of 140 matches
Mail list logo