flight 135431 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135431/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 21 leak-check/check fail REGR. vs. 135318
version targeted for testi
flight 135419 qemu-upstream-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135419/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow216 guest-saverestore.2 fail REGR. vs. 133734
Test
flight 135416 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135416/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 18 leak-check/check fail REGR. vs. 135251
Tests which did n
flight 135418 qemu-upstream-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135418/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 125575
test
Currently the gs_shadow value is only cached when the vCPU is being scheduled
out by Xen. Reporting this (usually) stale value through vm_event is incorrect,
since it doesn't represent the actual state of the vCPU at the time the event
was recorded. This prevents vm_event subscribers from correctly
flight 135417 qemu-upstream-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135417/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 124921
buil
Hi "Christian,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.1-rc7 next-20190430]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0d
flight 135426 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135426/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 133580
test-amd64-amd64-xl
Add two new paramters to device_tree_for_each_node: node and depth.
Node is the node to start the search from and depth is the min depth of
the search.
Passing 0, 0 triggers the old behavior.
Signed-off-by: Stefano Stabellini
---
Changes in v2:
- new
---
xen/arch/arm/acpi/boot.c | 2 +-
x
Now that map_mmio_regions takes a p2mt parameter, there is no need to
keep "mmio" in the name. The p2mt parameter does a better job at
expressing what the mapping is about. Let's save the environment 5
characters at a time.
Also fix the comment on top of map_mmio_regions.
Signed-off-by: Stefano S
Hi all,
This series introduces a memory policy parameter for the iomem option,
so that we can map an iomem region into a guest as cacheable memory.
Then, this series fixes the way Xen handles reserved memory regions on
ARM: they should be mapped as normal memory, instead today they are
treated as
Reserved memory regions are automatically remapped to dom0. Their device
tree nodes are also added to dom0 device tree. However, the dom0 memory
node is not currently extended to cover the reserved memory regions
ranges as required by the spec. This commit fixes it.
Signed-off-by: Stefano Stabell
As we parse the device tree in Xen, keep track of the reserved-memory
regions as they need special treatment (follow-up patches will make use
of the stored information.)
Reuse process_memory_node to add reserved-memory regions to the
bootinfo.reserved_mem array. Remove the warning if there is no r
Change the signature of process_memory_node to match
device_tree_node_func.
Signed-off-by: Stefano Stabellini
---
Changes in v2:
- new
---
xen/arch/arm/bootfdt.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
Introduce a new libxc function that makes use of the new memory_policy
parameter added to the XEN_DOMCTL_memory_mapping hypercall.
The parameter values are the same for the XEN_DOMCTL_memory_mapping
hypercall (0 is MEMORY_POLICY_DEFAULT). Pass MEMORY_POLICY_DEFAULT by
default -- no changes in beha
Add a new memory policy option for the iomem parameter.
Possible values are:
- arm_devmem, device nGRE, the default on ARM
- arm_memory, WB cachable memory
- x86_uc: uncachable memory, the default on x86
Store the parameter in a new field in libxl_iomem_range.
Pass the memory policy option to xc_
Reuse the existing padding field to pass memory policy information. On
Arm, the caller can specify whether the memory should be mapped as
device nGRE, which is the default and the only possibility today, or
cacheable memory write-back. On x86, the only option is uncachable. The
current behavior be
reserved-memory regions should be mapped as normal memory. At the
moment, they get remapped as device memory in dom0 because Xen doesn't
know any better. Add an explicit check for it.
reserved-memory regions overlap with memory nodes. The overlapping
memory is reserved-memory and should be handled
Add a p2mt parameter to map_mmio_regions, pass p2m_mmio_direct_dev on
ARM and p2m_mmio_direct on x86 -- no changes in behavior.
On ARM, given the similarity between map_mmio_regions after the change
and map_regions_p2mt, remove un/map_regions_p2mt.
Signed-off-by: Stefano Stabellini
CC: jbeul...@
On Tue, 30 Apr 2019, Stefano Stabellini wrote:
> On Tue, 30 Apr 2019, Hillf Danton wrote:
> > A new local variable is introduced for accessing p2m entry with lock
> > protection.
> >
>
> Same comment about html and space damage. But the change looks correct.
I fixed up the patches and committed
Sorry for the delay, I was on a long vacation.
On Fri, 2019-04-05 at 17:01 +0200, Jan Beulich wrote:On 22.03.19 at
20:28, wrote:
> > Limitations:
> > - Custom runtime parameters (OPT_CUSTOM) are not supported yet.
> > - For integer parameters (OPT_UINT), only unsigned parameters are
> > printed
>
On Tue, Apr 30, 2019 at 01:10:02PM +0200, Christian König wrote:
> Add a structure for the parameters of dma_buf_attach, this makes it much
> easier
> to add new parameters later on.
I don't understand this reasoning. What are the "new parameters" that
are being proposed, and why do we need to p
On 4/30/19 7:10 AM, Christian König wrote:
> diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
> index 2c4f324f8626..cacca830b482 100644
> --- a/drivers/xen/gntdev-dmabuf.c
> +++ b/drivers/xen/gntdev-dmabuf.c
> @@ -608,6 +608,7 @@ dmabuf_imp_to_refs(struct gntdev_dmabuf_priv *p
On 30/04/2019 17:24, Chao Gao wrote:
> On Tue, Apr 30, 2019 at 11:08:54AM +0200, Roger Pau Monné wrote:
>> On Tue, Apr 30, 2019 at 01:19:19PM +0800, Chao Gao wrote:
>>> When testing with an UP guest with a pass-thru device with vt-d pi
>>> enabled in host, we observed that guest couldn't receive in
On 04/30/19 18:35, Anthony PERARD wrote:
> On Fri, Apr 26, 2019 at 08:15:07PM +0200, Laszlo Ersek wrote:
>> On 04/25/19 22:23, Igor Druzhinin wrote:
>>> On Xen, hvmloader firmware leaves address decoding enabled for
>>> enumerated PCI device before jumping into OVMF. OVMF seems to
>>> expect it to
On Tue, Apr 30, 2019 at 11:30:33AM +0200, Roger Pau Monné wrote:
>On Tue, Apr 30, 2019 at 05:01:21PM +0800, Chao Gao wrote:
>> On Tue, Apr 30, 2019 at 01:56:31AM -0600, Jan Beulich wrote:
>> On 30.04.19 at 07:19, wrote:
>> >> When testing with an UP guest with a pass-thru device with vt-d pi
On Fri, Apr 26, 2019 at 08:15:07PM +0200, Laszlo Ersek wrote:
> On 04/25/19 22:23, Igor Druzhinin wrote:
> > On Xen, hvmloader firmware leaves address decoding enabled for
> > enumerated PCI device before jumping into OVMF. OVMF seems to
> > expect it to be disabled and tries to size PCI BARs in se
On Tue, 30 Apr 2019, Hillf Danton wrote:
> A new local variable is introduced for accessing p2m entry with lock
> protection.
>
Same comment about html and space damage. But the change looks correct.
>
> Cc: Stefano Stabellini
>
> Signed-off-by: Hillf Danton
>
> ---
>
>
>
> --- a/arch
On Tue, Apr 30, 2019 at 11:08:54AM +0200, Roger Pau Monné wrote:
>On Tue, Apr 30, 2019 at 01:19:19PM +0800, Chao Gao wrote:
>> When testing with an UP guest with a pass-thru device with vt-d pi
>> enabled in host, we observed that guest couldn't receive interrupts
>> from that pass-thru device. Dum
Hi Hillf,
Thanks for the patch. Please send emails in plain text, no html. Refer
to Documentation/process/submitting-patches.rst.
On Tue, 30 Apr 2019, Hillf Danton wrote:
> Release the newly allocated p2m entry if we detect a duplicate in the RB tree.
Space damage aside due to html, the patch l
On Tue, Apr 30, 2019 at 03:33:00PM +0100, Ian Jackson wrote:
> Jan Beulich writes ("Re: [Xen-devel] linux 4.19 xenstore memory allocation
> failure Re: [linux-4.19 test] 135420: regressions - FAIL"):
> > On 30.04.19 at 15:02, wrote:
> > > ISTM that there are *two* bugs here:
> > >
> > > 1. What
On 4/30/19 4:06 PM, Jan Beulich wrote:
On 30.04.19 at 16:43, wrote:
>> On 4/30/19 9:44 AM, Jan Beulich wrote:
>> On 30.04.19 at 10:28, wrote:
On Tue, Apr 30, 2019 at 1:15 AM Jan Beulich wrote:
> I've outlined a solution already: Make a mem-sharing private variant
> of page_
linux/commits/Christian-K-nig/dma-buf-add-struct-dma_buf_attach_info-v2/20190430-221017
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
>>> On 30.04.19 at 16:43, wrote:
> On 4/30/19 9:44 AM, Jan Beulich wrote:
> On 30.04.19 at 10:28, wrote:
>>> On Tue, Apr 30, 2019 at 1:15 AM Jan Beulich wrote:
I've outlined a solution already: Make a mem-sharing private variant
of page_{,un}lock(), derived from the PV ones (but wi
On Tue, Apr 30, 2019 at 8:43 AM George Dunlap wrote:
>
> On 4/30/19 9:44 AM, Jan Beulich wrote:
> On 30.04.19 at 10:28, wrote:
> >> On Tue, Apr 30, 2019 at 1:15 AM Jan Beulich wrote:
> >>>
> >> On 29.04.19 at 18:35, wrote:
> On Mon, Apr 29, 2019 at 9:18 AM Jan Beulich wrote:
> >>
On 4/30/19 9:44 AM, Jan Beulich wrote:
On 30.04.19 at 10:28, wrote:
>> On Tue, Apr 30, 2019 at 1:15 AM Jan Beulich wrote:
>>>
>> On 29.04.19 at 18:35, wrote:
On Mon, Apr 29, 2019 at 9:18 AM Jan Beulich wrote:
On 26.04.19 at 19:21, wrote:
>> --- a/xen/arch/x86/mm.c
>>
Jan Beulich writes ("Re: [Xen-devel] linux 4.19 xenstore memory allocation
failure Re: [linux-4.19 test] 135420: regressions - FAIL"):
> On 30.04.19 at 15:02, wrote:
> > ISTM that there are *two* bugs here:
> >
> > 1. Whatever caused the memory allocation failure
>
> An order-5 allocation is s
On 30/04/2019 15:02, Ian Jackson wrote:
> osstest service owner writes ("[linux-4.19 test] 135420: regressions - FAIL"):
>> flight 135420 linux-4.19 real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/135420/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> i
>>> On 30.04.19 at 15:02, wrote:
> ISTM that there are *two* bugs here:
>
> 1. Whatever caused the memory allocation failure
An order-5 allocation is set to fail at any time (afaict). I find it
surprising that struct blkfront_ring_info instances (even arrays
of them when using multiple rings) g
Hi Ian,
On 29/04/2019 15:46, Ian Jackson wrote:
Julien Grall writes ("Re: [OSSTEST PATCH 00/21] Abandon jobs which are unreasonably
delaying their flight"):
As we discussed on IRC, I understand this will have an impact on Arm32
testing. Do you have an estimate how likely the tests will be skip
On Tue, Apr 30, 2019 at 2:44 AM Jan Beulich wrote:
>
> >>> On 30.04.19 at 10:28, wrote:
> > On Tue, Apr 30, 2019 at 1:15 AM Jan Beulich wrote:
> >>
> >> >>> On 29.04.19 at 18:35, wrote:
> >> > On Mon, Apr 29, 2019 at 9:18 AM Jan Beulich wrote:
> >> >> >>> On 26.04.19 at 19:21, wrote:
> >> >>
Hi Ian,
Thank you for the report.
On 30/04/2019 13:44, Ian Jackson wrote:
osstest service owner writes ("[linux-4.19 test] 135420: regressions - FAIL"):
flight 135420 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135420/
Regressions :-(
Tests which did not succeed a
>>> On 30.04.19 at 14:44, wrote:
> osstest service owner writes ("[linux-4.19 test] 135420: regressions - FAIL"):
>> flight 135420 linux-4.19 real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/135420/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> incl
flight 135415 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135415/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-pvops 4 host-instal
>>> On 30.04.19 at 15:35, wrote:
> On 30/04/2019 14:33, Jan Beulich wrote:
> On 30.04.19 at 15:16, wrote:
>>> On 30/04/2019 12:48, Jan Beulich wrote:
>>> On 30.04.19 at 12:44, wrote:
> Then we could drop this #ifndef section.
Not sure about this - I'm actually unconvinced t
On 30/04/2019 14:33, Jan Beulich wrote:
On 30.04.19 at 15:16, wrote:
On 30/04/2019 12:48, Jan Beulich wrote:
On 30.04.19 at 12:44, wrote:
An alternative would be memory barriers between the writes on ARM,
right? Or a strong ordered set_bit() variant (we had that discussion
recently related
>>> On 30.04.19 at 15:16, wrote:
> On 30/04/2019 12:48, Jan Beulich wrote:
> On 30.04.19 at 12:44, wrote:
>>> An alternative would be memory barriers between the writes on ARM,
>>> right? Or a strong ordered set_bit() variant (we had that discussion
>>> recently related to a barrier in ARM-sp
> On 29. Apr 2019, at 18:11, Ross Lagerwall wrote:
>
> On 4/16/19 1:07 PM, Pawel Wieczorkiewicz wrote:
>> Starting with the "2af6f1aa6233 Fix patch creation with GCC 6.1+" commit
>> all .rodata sections are included by default (regardless of whether they
>> are needed or not).
>> During stacked
Hi,
On 30/04/2019 12:48, Jan Beulich wrote:
On 30.04.19 at 12:44, wrote:
An alternative would be memory barriers between the writes on ARM,
right? Or a strong ordered set_bit() variant (we had that discussion
recently related to a barrier in ARM-specific __cpu_disable()).
I am not entirely a
osstest service owner writes ("[linux-4.19 test] 135420: regressions - FAIL"):
> flight 135420 linux-4.19 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/135420/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test
On 29. Apr 2019, at 17:47, Ross Lagerwall
mailto:ross.lagerw...@citrix.com>> wrote:
On 4/16/19 1:07 PM, Pawel Wieczorkiewicz wrote:
Handle .livepatch.hooks* and .altinstr_replacement sections as the
special sections with assigned group_size resolution function.
By default each .livepatch.hooks*
osstest service owner writes ("[linux-4.19 test] 135420: regressions - FAIL"):
> flight 135420 linux-4.19 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/135420/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build
> On 29. Apr 2019, at 17:25, Ross Lagerwall wrote:
>
> On 4/16/19 1:07 PM, Pawel Wieczorkiewicz wrote:
>> This function determines, based on the given section name, if the
>> sections belongs to the special sections category.
>> It treats a name from the special_sections array as a prefix. Any
>
>>> On 30.04.19 at 12:44, wrote:
> An alternative would be memory barriers between the writes on ARM,
> right? Or a strong ordered set_bit() variant (we had that discussion
> recently related to a barrier in ARM-specific __cpu_disable()).
Yes.
> Then we could drop this #ifndef section.
Not sure
flight 135420 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135420/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail REGR. vs. 129313
test-amd64-amd64-lib
Add a structure for the parameters of dma_buf_attach, this makes it much easier
to add new parameters later on.
v2: rebase cleanup and fix all new implementations as well
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 13 +++--
drivers/gpu/drm/armad
On 29.04.19 17:30, Julien Grall wrote:
Hi Oleksandr,
Hi, Julien
@@ -22,10 +22,13 @@
#ifdef EARLY_PRINTK_VERSION_NONE
#define STATUS_REG SCIF_SCFSR
#define TX_FIFO_REG SCIF_SCFTDR
+#elif EARLY_PRINTK_VERSION_A
+#define STATUS_REG SCIFA_SCASSR
+#define TX_FIFO_REG SCIFA_SCAFTD
On 29.04.19 17:29, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
---
docs/misc/arm/early-printk.txt | 6 ++
xen/arch/arm/Rules.mk | 7 +++
xen/arch/arm/arm32/debug-scif.inc | 13 +
3 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/docs
On 30/04/2019 12:38, Jan Beulich wrote:
On 30.04.19 at 12:31, wrote:
>
>>
>> On 30/04/2019 11:27, Jan Beulich wrote:
>> On 30.04.19 at 11:13, wrote:
In xen/common/schedule.c there is a weird "#ifndef CONFIG_X86" in
do_poll().
It was introduced way before anyone would
>>> On 30.04.19 at 12:31, wrote:
>
> On 30/04/2019 11:27, Jan Beulich wrote:
> On 30.04.19 at 11:13, wrote:
>>> In xen/common/schedule.c there is a weird "#ifndef CONFIG_X86" in
>>> do_poll().
>>>
>>> It was introduced way before anyone would think about ARM by commit
>>> ef4c6b079cc55e (I
On 30/04/2019 11:27, Jan Beulich wrote:
On 30.04.19 at 11:13, wrote:
In xen/common/schedule.c there is a weird "#ifndef CONFIG_X86" in
do_poll().
It was introduced way before anyone would think about ARM by commit
ef4c6b079cc55e (I couldn't find any xen-devel mail related to that
commit), so
>>> On 30.04.19 at 11:13, wrote:
> In xen/common/schedule.c there is a weird "#ifndef CONFIG_X86" in
> do_poll().
>
> It was introduced way before anyone would think about ARM by commit
> ef4c6b079cc55e (I couldn't find any xen-devel mail related to that
> commit), so I guess it is related to IA6
On Tue, 2019-04-30 at 11:13 +0200, Juergen Gross wrote:
> In xen/common/schedule.c there is a weird "#ifndef CONFIG_X86" in
> do_poll().
>
> It was introduced way before anyone would think about ARM by commit
> ef4c6b079cc55e (I couldn't find any xen-devel mail related to that
> commit), so I gues
On 29/04/2019 15:53, Jan Beulich wrote:
On 23.04.19 at 16:30, wrote:
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -478,6 +478,43 @@ void p2m_unlock_and_tlb_flush(struct p2m_domain *p2m)
>> mm_write_unlock(&p2m->lock);
>> }
>>
>> +int altp2m_get_effective_ent
Marek Marczykowski-Górecki writes ("[PATCH v2] python: Adjust xc_physinfo
wrapper for updated virt_caps bits"):
> Commit f089fddd94 "xen: report PV capability in sysctl and use it in
> toolstack" changed meaning of virt_caps bit 1 - previously it was
> "directio", but was changed to "pv" and "dire
On Thu, Apr 18, 2019 at 10:54:05AM -0700, Stefano Stabellini wrote:
> On Thu, 18 Apr 2019, Wei Liu wrote:
> > Hi all
> >
> > We now have Gitlab CI as a complementary system to Osstest and have planned
> > to
> > add bots. It's high time we think about how we integrate them and how it may
> > impr
>>> On 30.04.19 at 11:01, wrote:
> On Tue, Apr 30, 2019 at 01:56:31AM -0600, Jan Beulich wrote:
>>In any event it doesn't look correct to skip migration altogether in
>>that case. I'd rather expect it to require getting done differently.
>>After all there still is a (CPU, vector) tuple associated
On Tue, Apr 30, 2019 at 05:01:21PM +0800, Chao Gao wrote:
> On Tue, Apr 30, 2019 at 01:56:31AM -0600, Jan Beulich wrote:
> On 30.04.19 at 07:19, wrote:
> >> When testing with an UP guest with a pass-thru device with vt-d pi
> >> enabled in host, we observed that guest couldn't receive interru
On Tue, Apr 30, 2019 at 12:42:52AM +0200, Marek Marczykowski-Górecki wrote:
> Commit f089fddd94 "xen: report PV capability in sysctl and use it in
> toolstack" changed meaning of virt_caps bit 1 - previously it was
> "directio", but was changed to "pv" and "directio" was moved to bit 2.
> Adjust py
In xen/common/schedule.c there is a weird "#ifndef CONFIG_X86" in
do_poll().
It was introduced way before anyone would think about ARM by commit
ef4c6b079cc55e (I couldn't find any xen-devel mail related to that
commit), so I guess it is related to IA64?
Question is: can we just drop it, or does
On Tue, Apr 30, 2019 at 01:19:19PM +0800, Chao Gao wrote:
> When testing with an UP guest with a pass-thru device with vt-d pi
> enabled in host, we observed that guest couldn't receive interrupts
> from that pass-thru device. Dumping IRTE, we found the corresponding
> IRTE is set to posted format
On Tue, Apr 30, 2019 at 01:56:31AM -0600, Jan Beulich wrote:
On 30.04.19 at 07:19, wrote:
>> When testing with an UP guest with a pass-thru device with vt-d pi
>> enabled in host, we observed that guest couldn't receive interrupts
>> from that pass-thru device. Dumping IRTE, we found the corr
>>> On 30.04.19 at 10:28, wrote:
> On Tue, Apr 30, 2019 at 1:15 AM Jan Beulich wrote:
>>
>> >>> On 29.04.19 at 18:35, wrote:
>> > On Mon, Apr 29, 2019 at 9:18 AM Jan Beulich wrote:
>> >> >>> On 26.04.19 at 19:21, wrote:
>> >> > --- a/xen/arch/x86/mm.c
>> >> > +++ b/xen/arch/x86/mm.c
>> >> > @@
On Tue, Apr 30, 2019 at 1:15 AM Jan Beulich wrote:
>
> >>> On 29.04.19 at 18:35, wrote:
> > On Mon, Apr 29, 2019 at 9:18 AM Jan Beulich wrote:
> >> >>> On 26.04.19 at 19:21, wrote:
> >> > --- a/xen/arch/x86/mm.c
> >> > +++ b/xen/arch/x86/mm.c
> >> > @@ -2030,12 +2030,11 @@ static inline bool
>
>>> On 30.04.19 at 07:19, wrote:
> When testing with an UP guest with a pass-thru device with vt-d pi
> enabled in host, we observed that guest couldn't receive interrupts
> from that pass-thru device. Dumping IRTE, we found the corresponding
> IRTE is set to posted format with "vector" field as 0
>>> On 29.04.19 at 18:16, wrote:
> The posted version of this patch depends on c/s 3c555295 "x86/vpmu: Improve
> documentation and parsing for vpmu=" (Xen 4.12 and later) to prevent
> `vpmu=rtm-abort` impliying `vpmu=1`, which is outside of security support.
>
> Signed-off-by: Andrew Cooper
Rev
>>> On 29.04.19 at 18:16, wrote:
> These were missed as a consequence of being rebased over other cmdline
> cleanup.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.
>>> On 29.04.19 at 18:35, wrote:
> On Mon, Apr 29, 2019 at 9:18 AM Jan Beulich wrote:
>> >>> On 26.04.19 at 19:21, wrote:
>> > --- a/xen/arch/x86/mm.c
>> > +++ b/xen/arch/x86/mm.c
>> > @@ -2030,12 +2030,11 @@ static inline bool
>> > current_locked_page_ne_check(struct page_info *page) {
>> > #
>>> On 29.04.19 at 18:42, wrote:
> On 4/29/19 4:18 PM, Jan Beulich wrote:
> On 26.04.19 at 19:21, wrote:
>>> Patch cf4b30dca0a "Add debug code to detect illegal page_lock and
> put_page_type
>>> ordering" added extra sanity checking to page_lock/page_unlock for debug
> builds
>>> with the a
79 matches
Mail list logo
