flight 144888 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144888/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 144637
build-amd64
flight 144880 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144880/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 14 guest-saverestore fail REGR. vs. 144861
On 16.12.19 20:48, SeongJae Park wrote:
On on, 16 Dec 2019 17:23:44 +0100, Jürgen Groß wrote:
On 16.12.19 17:15, SeongJae Park wrote:
On Mon, 16 Dec 2019 15:37:20 +0100 SeongJae Park wrote:
On Mon, 16 Dec 2019 13:45:25 +0100 SeongJae Park wrote:
From: SeongJae Park
[...]
---
On Mon, Dec 16, 2019 at 6:55 PM Stefano Stabellini
wrote:
>
> On Mon, 16 Dec 2019, Roman Shaposhnik wrote:
> > Hi!
> >
> > it appears that something has broken in 4.13 RC5 so that
> > I'm now getting the following on ARM (full logs are attached).
> >
> > (XEN)
flight 144878 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144878/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-4 114 leak-check/checkfail REGR. vs. 144850
Regressions which
flight 144884 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144884/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 144637
build-amd64
flight 144883 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144883/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 144637
build-amd64
On Mon, 16 Dec 2019, Roman Shaposhnik wrote:
> Hi!
>
> it appears that something has broken in 4.13 RC5 so that
> I'm now getting the following on ARM (full logs are attached).
>
> (XEN)
> (XEN) Panic on CPU 0:
> (XEN) Failed to allocate requested dom0
On Mon, 16 Dec 2019, Julien Grall wrote:
> On 16/12/2019 23:05, Stefano Stabellini wrote:
> > On Mon, 16 Dec 2019, Julien Grall wrote:
> > > On 16/12/2019 18:02, Andrei Cherechesu wrote:
> > > But even with this patch, RAM in DomU is not direct mapped (i.e Guest
> > > Physical
> > > Address ==
flight 144882 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144882/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 144637
build-amd64
On 16/12/2019 23:05, Stefano Stabellini wrote:
On Mon, 16 Dec 2019, Julien Grall wrote:
On 16/12/2019 18:02, Andrei Cherechesu wrote:
But even with this patch, RAM in DomU is not direct mapped (i.e Guest Physical
Address == Host Physical Address). This means that DMA-capable device would
not
On Mon, 16 Dec 2019, Julien Grall wrote:
> On 16/12/2019 18:02, Andrei Cherechesu wrote:
> > Hello,
>
> Hello,
>
> > My name is Andrei Cherechesu and I'm a Software Engineer at NXP
> >
> > Semiconductors in the Automotive department, Linux BSP Team.
> >
> > I would like to tell you have done a
Thanks for the report, I'll give it a look!
On Mon, 16 Dec 2019, Roman Shaposhnik wrote:
> Hi!
>
> it appears that something has broken in 4.13 RC5 so that
> I'm now getting the following on ARM (full logs are attached).
>
> (XEN)
> (XEN) Panic on CPU 0:
flight 144881 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144881/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 144637
build-amd64
flight 144877 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144877/
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
On 16/12/2019 18:02, Andrei Cherechesu wrote:
Hello,
Hello,
My name is Andrei Cherechesu and I'm a Software Engineer at NXP
Semiconductors in the Automotive department, Linux BSP Team.
I would like to tell you have done a great job so far with Xen.
Thank you for your interest in Xen on
flight 144879 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144879/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 144637
build-amd64
Hello,
On 04/12/2019 23:20, Pavel Tatashin wrote:
privcmd_call requires to enable access to userspace for the
duration of the hypercall.
Currently, this is done via assembly macros. Change it to C
inlines instead.
Signed-off-by: Pavel Tatashin
Acked-by: Stefano Stabellini
Reviewed-by:
Hi,
On 04/12/2019 23:20, Pavel Tatashin wrote:
The arm and arm64 versions of hypercall.h are missing the include
guards. This is needed because C inlines for privcmd_call are going to
be added to the files.
Also fix a comment.
Signed-off-by: Pavel Tatashin
---
Hi!
it appears that something has broken in 4.13 RC5 so that
I'm now getting the following on ARM (full logs are attached).
(XEN)
(XEN) Panic on CPU 0:
(XEN) Failed to allocate requested dom0 memory. 672MB unallocated
(XEN)
On on, 16 Dec 2019 17:23:44 +0100, Jürgen Groß wrote:
> On 16.12.19 17:15, SeongJae Park wrote:
> > On Mon, 16 Dec 2019 15:37:20 +0100 SeongJae Park wrote:
> >
> >> On Mon, 16 Dec 2019 13:45:25 +0100 SeongJae Park wrote:
> >>
> >>> From: SeongJae Park
> >>>
> > [...]
> >>> ---
flight 144861 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144861/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail blocked in 144805
flight 144876 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144876/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 144637
build-amd64
flight 144871 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144871/
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
flight 144875 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144875/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 144637
build-amd64
On 12/10/19 3:47 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Re-define Uuid as [16]byte and implement fromC, toC, and String functions.
>
> Signed-off-by: Nick Rosbrook
Reviewed-by: George Dunlap
___
Xen-devel mailing list
Hello,
My name is Andrei Cherechesu and I'm a Software Engineer at NXP
Semiconductors in the Automotive department, Linux BSP Team.
I would like to tell you have done a great job so far with Xen.
Thus, we have ported and integrated Xen ARM in the Linux BSP for our
boards.
Currently, we are
On 12/10/19 3:47 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Switch over union key to determine how to populate 'union' in Go struct.
>
> Since the unions of C types cannot be directly accessed in cgo, use a
> typeof trick to typedef a struct in the cgo preamble that is analagous
> to
On 12/10/19 3:47 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Begin implementation of fromC marshaling functions for generated struct
> types. This includes support for converting fields that are basic
> primitive types such as string and integer types, nested anonymous
> structs, nested
> I was expecting you to change this if you sent a v3. :-)
>
> I can still change it on check-in, but if for some reason there's a v4,
> please make the change before resending. Thanks. :-)
Sorry, my mistake. I will make the change if I send v4.
Thanks,
-NR
flight 144868 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144868/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 8afcfc0c18de7a9a40aa0eb671772f9de577ccbf
baseline version:
xtf
On Fri, Dec 13, 2019 at 07:04:31PM +, Andrew Cooper wrote:
> do_suspend_lowlevel() behaves as a function call, even when the trampoline
> jumps back into the middle of it. Discuss this property, while renaming the
> far-too-generic __ret_point to s3_resume.
>
> Optimise the calling logic for
flight 144874 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144874/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 144637
build-amd64
On 12/10/19 3:47 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Define Mac as [6]byte and implement fromC, toC, and String functions.
>
> Signed-off-by: Nick Rosbrook
> Reviewed-by: George Dunlap
> ---
> Changes in v2:
> - Fix the format string in String function to use %02x.
> - Use a
On 12/10/19 3:47 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Introduce gengotypes.py to generate Go code the from IDL. As a first step,
> implement 'enum' type generation.
>
> As a result of the newly-generated code, remove the existing, and now
> conflicting definitions in xenlight.go.
On 12/16/19 4:20 PM, Andrew Cooper wrote:
> promote_l4_table() is different from its lower level helpers, by having an
> extra return path out of the middle of the loop in the case of a failure.
>
> Break from the loop, which is consistent with the other helpers, and
> functionally equivalent.
>
On Mon, Dec 16, 2019 at 04:55:52PM +0100, Jan Beulich wrote:
> On 16.12.2019 15:01, Anthony PERARD wrote:
> > On Mon, Dec 16, 2019 at 11:16:52AM +0100, Jan Beulich wrote:
> >> What headers are you taking about? My question was about the placement
> >> of .gitignore entries only. I'm pretty sure I
On 16.12.19 17:15, SeongJae Park wrote:
On Mon, 16 Dec 2019 15:37:20 +0100 SeongJae Park wrote:
On Mon, 16 Dec 2019 13:45:25 +0100 SeongJae Park wrote:
From: SeongJae Park
[...]
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -824,6 +824,24 @@
flight 144867 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144867/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 144637
build-amd64
promote_l4_table() is different from its lower level helpers, by having an
extra return path out of the middle of the loop in the case of a failure.
Break from the loop, which is consistent with the other helpers, and
functionally equivalent.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
On Mon, 16 Dec 2019 15:37:20 +0100 SeongJae Park wrote:
> On Mon, 16 Dec 2019 13:45:25 +0100 SeongJae Park wrote:
>
> > From: SeongJae Park
> >
[...]
> > --- a/drivers/block/xen-blkback/xenbus.c
> > +++ b/drivers/block/xen-blkback/xenbus.c
> > @@ -824,6 +824,24 @@ static void
On 16.12.2019 15:19, Julien Grall wrote:
> On 05/12/2019 15:34, Jan Beulich wrote:
>> Translated domains shouldn't see host physical addresses. While the
>> address is also not supposed to be handed back even to non-translated
>> domains when GNTMAP_device_map is not set (as explicitly stated by a
On 16.12.2019 15:01, Anthony PERARD wrote:
> On Mon, Dec 16, 2019 at 11:16:52AM +0100, Jan Beulich wrote:
>> What headers are you taking about? My question was about the placement
>> of .gitignore entries only. I'm pretty sure I had previously expressed
>> that I'm not overly happy to see needless
On 16.12.2019 16:38, Roger Pau Monné wrote:
> On Mon, Dec 16, 2019 at 02:02:27PM +, Andrew Cooper wrote:
>> c/s 5de961d9c09 "x86: do not enable global pages when virtualized on AMD or
>> Hygon hardware" in fact does. Fix the calculation in pge_init().
>>
>> While fixing this, adjust the
On 12/16/19 4:41 PM, Paolo Bonzini wrote:
On 16/12/19 16:37, Philippe Mathieu-Daudé wrote:
On 12/15/19 10:58 AM, Michael S. Tsirkin wrote:
On Fri, Dec 13, 2019 at 05:47:28PM +0100, Philippe Mathieu-Daudé wrote:
On 12/13/19 5:17 PM, Philippe Mathieu-Daudé wrote:
Historically, QEMU started
On 16/12/19 16:37, Philippe Mathieu-Daudé wrote:
> On 12/15/19 10:58 AM, Michael S. Tsirkin wrote:
>> On Fri, Dec 13, 2019 at 05:47:28PM +0100, Philippe Mathieu-Daudé wrote:
>>> On 12/13/19 5:17 PM, Philippe Mathieu-Daudé wrote:
Historically, QEMU started with only one X86 machine: the PC.
On Mon, Dec 16, 2019 at 02:02:27PM +, Andrew Cooper wrote:
> c/s 5de961d9c09 "x86: do not enable global pages when virtualized on AMD or
> Hygon hardware" in fact does. Fix the calculation in pge_init().
>
> While fixing this, adjust the command line documenation, first to use the
> newer
On 12/15/19 10:58 AM, Michael S. Tsirkin wrote:
On Fri, Dec 13, 2019 at 05:47:28PM +0100, Philippe Mathieu-Daudé wrote:
On 12/13/19 5:17 PM, Philippe Mathieu-Daudé wrote:
Historically, QEMU started with only one X86 machine: the PC.
The 'hw/i386/pc.h' header was used to store all X86 and PC
flight 144863 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144863/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 144637
build-amd64
On Mon, 16 Dec 2019 13:45:25 +0100 SeongJae Park wrote:
> From: SeongJae Park
>
> 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
It is not safe to close an event channel from the QEMU main thread when
that channel's poller is running in IOThread context.
This patch adds a new xen_device_set_event_channel_context() function
to explicitly assign the channel AioContext, and modifies
xen_device_bind_event_channel() to
On 16/12/2019 09:47, Roger Pau Monné wrote:
> On Fri, Dec 13, 2019 at 10:48:01PM +, Igor Druzhinin wrote:
>> They either need to be transformed to atomics to work correctly
>> (currently they left unprotected for HVM domains) or dropped entirely
> ^ are used
>> as taking a
Hi,
On 05/12/2019 15:34, Jan Beulich wrote:
Translated domains shouldn't see host physical addresses. While the
address is also not supposed to be handed back even to non-translated
domains when GNTMAP_device_map is not set (as explicitly stated by a
comment in the public header), PV kernels
flight 144862 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144862/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 144637
build-amd64
c/s 5de961d9c09 "x86: do not enable global pages when virtualized on AMD or
Hygon hardware" in fact does. Fix the calculation in pge_init().
While fixing this, adjust the command line documenation, first to use the
newer style, and to expand the description to discuss cases where the option
On Mon, Dec 16, 2019 at 11:16:52AM +0100, Jan Beulich wrote:
> What headers are you taking about? My question was about the placement
> of .gitignore entries only. I'm pretty sure I had previously expressed
> that I'm not overly happy to see needless scattering around of them.
> I'm merely trying
On 13/12/2019 17:37, George Dunlap wrote:
> This series implements a number of cleanups to make the code simpler
> and easier to follow. No functional changes intended.
>
> George Dunlap (3):
> x86/mm: Use a more descriptive name for pagetable mfns
> x86/mm: Use mfn_t in type get / put call
On 13/12/19 17:17, Philippe Mathieu-Daudé wrote:
> 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é
> ---
>
On 13/12/19 17:17, Philippe Mathieu-Daudé wrote:
> 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é
> ---
>
On 13/12/19 17:17, Philippe Mathieu-Daudé wrote:
> 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é
> ---
>
On 13/12/19 17:17, Philippe Mathieu-Daudé wrote:
> 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
On 13/12/19 17:17, Philippe Mathieu-Daudé wrote:
> 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é
> ---
>
On 13/12/19 17:17, Philippe Mathieu-Daudé wrote:
> 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,
On 16/12/2019 12:37, Jan Beulich wrote:
> On 16.12.2019 13:26, Andrew Cooper wrote:
>> On 16/12/2019 11:47, Jan Beulich wrote:
What
you've done here is half-virtualise something we have no intention to
ever virtualise for guests.
Both of these should be blanket #GP
On Mon, Dec 16, 2019 at 12:53:40PM +, Igor Druzhinin wrote:
> On 16/12/2019 10:00, Roger Pau Monné wrote:
> > On Fri, Dec 13, 2019 at 10:48:02PM +, Igor Druzhinin wrote:
> > I'm not sure if the following would be slightly better performance
> > wise:
> >
> > do {
> > old =
On Mon, Dec 16, 2019 at 01:45:10PM +0100, Jan Beulich wrote:
> On 16.12.2019 13:30, Roger Pau Monné wrote:
> > On Mon, Dec 16, 2019 at 12:21:09PM +0100, Jan Beulich wrote:
> >> On 16.12.2019 11:00, Roger Pau Monné wrote:
> >>> On Fri, Dec 13, 2019 at 10:48:02PM +, Igor Druzhinin wrote:
>
On 16/12/2019 10:00, Roger Pau Monné wrote:
> On Fri, Dec 13, 2019 at 10:48:02PM +, Igor Druzhinin wrote:
>> Now that vtsc_last is the only entity protected by vtsc_lock we can
>> simply update it using a single atomic operation and drop the spinlock
>> entirely. This is extremely important
From: SeongJae Park
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
From: SeongJae Park
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.
Acked-by: Roger Pau Monné
Signed-off-by: SeongJae Park
---
drivers/block/xen-blkback/xenbus.c | 7
From: SeongJae Park
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
From: SeongJae Park
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
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.
On 16.12.2019 13:30, Roger Pau Monné wrote:
> On Mon, Dec 16, 2019 at 12:21:09PM +0100, Jan Beulich wrote:
>> On 16.12.2019 11:00, Roger Pau Monné wrote:
>>> On Fri, Dec 13, 2019 at 10:48:02PM +, Igor Druzhinin wrote:
Now that vtsc_last is the only entity protected by vtsc_lock we can
flight 144860 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144860/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 144637
build-amd64
On 16.12.2019 13:11, Jin Nan Wang wrote:
> Fix a issue when user disable ETP exec-sp, xen missed a prompt
> log in dmesg.
>
> At default, xen will tell "VMX: Disabling executable EPT suerpages
> due to CVE-2018-12207". When user add 'ept=exec-sp=off' on command-line.
> The prompt is disappeared.
On 16.12.2019 13:26, Andrew Cooper wrote:
> On 16/12/2019 11:47, Jan Beulich wrote:
>>> What
>>> you've done here is half-virtualise something we have no intention to
>>> ever virtualise for guests.
>>>
>>> Both of these should be blanket #GP faults. AMD should never be in the
>>> position of
On 16.12.2019 12:51, Jin Nan Wang wrote:
>
> On 16/12/2019 7:00 pm, Jan Beulich wrote:
>> On 16.12.2019 09:27, Jin Nan Wang wrote:
>>> Fix a issue when user disable ETP exec-sp, xen missed a prompt
>>> log in dmesg.
>> Why "missed" (and why "prompt")? I think the original intention
>> was to log
On Mon, Dec 16, 2019 at 12:21:09PM +0100, Jan Beulich wrote:
> On 16.12.2019 11:00, Roger Pau Monné wrote:
> > On Fri, Dec 13, 2019 at 10:48:02PM +, Igor Druzhinin wrote:
> >> Now that vtsc_last is the only entity protected by vtsc_lock we can
> >> simply update it using a single atomic
Fix a issue when user disable ETP exec-sp, xen missed a prompt
log in dmesg.
At default, xen will tell "VMX: Disabling executable EPT suerpages
due to CVE-2018-12207". When user add 'ept=exec-sp=off' on command-line.
The prompt is disappeared. This can give users the illusion that the
feature is
On 16/12/2019 11:47, Jan Beulich wrote:
>> What
>> you've done here is half-virtualise something we have no intention to
>> ever virtualise for guests.
>>
>> Both of these should be blanket #GP faults. AMD should never be in the
>> position of seeing amd_ppin clear but PPIN_CTL returning
On 16/12/2019 11:33, Jan Beulich wrote:
> On 13.12.2019 20:50, Andrew Cooper wrote:
>> On 08/11/2019 15:22, Jan Beulich wrote:
>>> 1: include the PPIN in MCE records when available
>>> 2: explicitly disallow guest access to PPIN
>>> 3: provide Dom0 access to PPIN via XENPF_resource_op
>>>
>>> I
On 16/12/2019 11:49, Jan Beulich wrote:
> On 16.12.2019 12:42, Jin Nan Wang wrote:
>> Fix a issue when user disable ETP exec-sp, xen missed a prompt
>> log in dmesg.
> Thanks for fixing the style issue, but submitting v3 without
> addressing the question on the "why" etc given on v2 isn't
> overly
On 16/12/2019 7:00 pm, Jan Beulich wrote:
> On 16.12.2019 09:27, Jin Nan Wang wrote:
>> Fix a issue when user disable ETP exec-sp, xen missed a prompt
>> log in dmesg.
> Why "missed" (and why "prompt")? I think the original intention
> was to log a message only when no command line option was
Fix a issue when user disable ETP exec-sp, xen missed a prompt
log in dmesg.
Signed-off-by: James Wang
---
xen/arch/x86/hvm/vmx/vmx.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index
On 16.12.2019 12:42, Jin Nan Wang wrote:
> Fix a issue when user disable ETP exec-sp, xen missed a prompt
> log in dmesg.
Thanks for fixing the style issue, but submitting v3 without
addressing the question on the "why" etc given on v2 isn't
overly helpful.
Jan
flight 144859 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144859/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 144637
build-amd64
On 13.12.2019 20:47, Andrew Cooper wrote:
> On 08/11/2019 15:24, Jan Beulich wrote:
>> To fulfill the "protected" in its name, don't let the real hardware
>> values "shine through". Report a control register value expressing this.
>
> Why not call it as it is? They leak through due to bugs in
Hi all,
Xen 4.13 rc5 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.13.0-rc5
For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.13.0-rc5/xen-4.13.0-rc5.tar.gz
And the signature is at:
On 13.12.2019 20:50, Andrew Cooper wrote:
> On 08/11/2019 15:22, Jan Beulich wrote:
>> 1: include the PPIN in MCE records when available
>> 2: explicitly disallow guest access to PPIN
>> 3: provide Dom0 access to PPIN via XENPF_resource_op
>>
>> I have yet to get around to post the Linux side
On 16.12.2019 12:13, George Dunlap wrote:
> On 12/16/19 11:10 AM, Jan Beulich wrote:
>> On 13.12.2019 18:37, George Dunlap wrote:
>>> Replace `unsigned long` with `mfn_t` as appropriate throughout
>>> alloc/free_lN_table, get/put_page_from_lNe, and
>>> get_lN_linear_pagetable. This obviates the
On 16.12.2019 11:00, Roger Pau Monné wrote:
> On Fri, Dec 13, 2019 at 10:48:02PM +, Igor Druzhinin wrote:
>> Now that vtsc_last is the only entity protected by vtsc_lock we can
>> simply update it using a single atomic operation and drop the spinlock
>> entirely. This is extremely important
On 13.12.2019 18:37, George Dunlap wrote:
> The functions alloc_page_type(), alloc_lN_table(), free_page_type()
> and free_lN_table() are confusingly named: nothing is being allocated
> or freed. Rather, the page being passed in is being either validated
> or devalidated for use as the specific
On 12/16/19 11:10 AM, Jan Beulich wrote:
> On 13.12.2019 18:37, George Dunlap wrote:
>> Replace `unsigned long` with `mfn_t` as appropriate throughout
>> alloc/free_lN_table, get/put_page_from_lNe, and
>> get_lN_linear_pagetable. This obviates the need for a load of
>> `mfn_x()` and `_mfn()`
On 12/16/19 11:07 AM, Jan Beulich wrote:
> On 13.12.2019 18:37, George Dunlap wrote:
>> In many places, a PTE being modified is accompanied by the pagetable
>> mfn which contains the PTE (primarily in order to be able to maintain
>> linear mapping counts). In many cases, this mfn is stored in the
On 13.12.2019 18:37, George Dunlap wrote:
> Replace `unsigned long` with `mfn_t` as appropriate throughout
> alloc/free_lN_table, get/put_page_from_lNe, and
> get_lN_linear_pagetable. This obviates the need for a load of
> `mfn_x()` and `_mfn()` casts.
>
> Signed-off-by: George Dunlap
Ah, here
On 13.12.2019 18:37, George Dunlap wrote:
> In many places, a PTE being modified is accompanied by the pagetable
> mfn which contains the PTE (primarily in order to be able to maintain
> linear mapping counts). In many cases, this mfn is stored in the
> non-descript variable (or argement) "pfn".
On 16.12.2019 09:27, Jin Nan Wang wrote:
> Fix a issue when user disable ETP exec-sp, xen missed a prompt
> log in dmesg.
Why "missed" (and why "prompt")? I think the original intention
was to log a message only when no command line option was given
and the system would be vulnerable without the
flight 144858 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144858/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 144637
build-amd64
flight 144853 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144853/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 144517
test-armhf-armhf-libvirt-raw 13
> -Original Message-
> From: Durrant, Paul
> Sent: 16 December 2019 09:50
> To: Durrant, Paul ; Julien Grall ;
> Ian Jackson
> Cc: Jürgen Groß ; Stefano Stabellini
> ; qemu-de...@nongnu.org; osstest service owner
> ; Anthony Perard
> ; xen-devel@lists.xenproject.org
> Subject: RE:
1 - 100 of 116 matches
Mail list logo
