flight 145691 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145691/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 15 guest-stop fail REGR. vs. 145650
Tests which did not succeed
On 06.01.20 18:37, Andrew Cooper wrote:
The compiler can't fold because of the write to *perr in the first hunk.
No functional change, but slightly better compiled code.
Signed-off-by: Andrew Cooper
Reviewed-by: Juergen Gross
Juergen
___
Xen-de
> -Original Message-
> From: Andrew Cooper
> Sent: 07 January 2020 00:26
> To: Lars Kurth ; xen-devel de...@lists.xenproject.org>
> Cc: Rian Quinn ; Daniel P. Smith
> ; Doug Goldstein ; Brian
> Woods ; Rich Persaud ;
> anastassios.na...@onapp.com; mirela.simono...@aggios.com;
> edgar.igle
On 06.01.2020 20:01, Andrew Cooper wrote:
> On 09/12/2019 12:11, Jan Beulich wrote:
>> On 06.12.2019 22:02, Andrew Cooper wrote:
>>> On 12/11/2019 14:03, Jan Beulich wrote:
Bottom line - I'm half convinced and willing to give my ack, but
I'm not convinced you truly thought through the lon
Hi Stefano,
On 2020/1/7 6:01, Stefano Stabellini wrote:
On Sat, 28 Dec 2019, Wei Xu wrote:
Hi Julien,
On 2019/12/28 16:09, Julien Grall wrote:
Hi,
On 28/12/2019 03:08, Wei Xu wrote:
This patch fixes the typo about the active status range of an IRQ
via GICD. Otherwise it will be failed to ha
flight 145699 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145699/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf cc617b6e1430242f8d042c71c2d923dbc6436a36
baseline version:
ovmf 0ef6fbbd114e89b8d838e
On 06.01.2020 20:38, Andrew Cooper wrote:
> On 06/01/2020 16:36, Jan Beulich wrote:
>> Note that SDM revision 070 doesn't specify exception behavior for
>> ModRM.mod != 0b11; assuming #UD here.
>>
>> Signed-off-by: Jan Beulich
>> ---
>> RFC: Yet to be tested (once SDE supports it).
>
> Do you hav
On 06.01.2020 20:45, Andrew Cooper wrote:
> On 06/01/2020 16:39, Jan Beulich wrote:
>> The dependency on a new EFER bit implies that we need to set that bit
>> ourselves in order to be able to successfully invoke the insn.
>>
>> Also once again introduce the SVM related constants at this occasion.
On 06.01.2020 18:16, Andrew Cooper wrote:
> On 06/01/2020 10:13, Jan Beulich wrote:
>> On 03.01.2020 21:07, Andrew Cooper wrote:
>>> --- a/xen/include/xen/sched.h
>>> +++ b/xen/include/xen/sched.h
>>> @@ -963,10 +963,22 @@ void watchdog_domain_destroy(struct domain *d);
>>> *(that is, this wo
On 03/01/2020 20:07, Andrew Cooper wrote:
> The net diffstat is:
> add/remove: 0/13 grow/shrink: 25/129 up/down: 6297/-20469 (-14172)
>
> With the following objects/functions removed entirely:
> iommu_hwdom_none 1 - -1
> hwdom_max_order
On 07/01/2020 08:39, Wei Xu wrote:
Hi Stefano,
On 2020/1/7 6:01, Stefano Stabellini wrote:
On Sat, 28 Dec 2019, Wei Xu wrote:
Hi Julien,
On 2019/12/28 16:09, Julien Grall wrote:
Hi,
On 28/12/2019 03:08, Wei Xu wrote:
This patch fixes the typo about the active status range of an IRQ
via G
flight 145722 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145722/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
flight 145710 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145710/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 145511
build-arm64-libvirt
Hi Julien,
On 2020/1/7 17:10, Julien Grall wrote:
On 07/01/2020 08:39, Wei Xu wrote:
Hi Stefano,
On 2020/1/7 6:01, Stefano Stabellini wrote:
On Sat, 28 Dec 2019, Wei Xu wrote:
Hi Julien,
On 2019/12/28 16:09, Julien Grall wrote:
Hi,
On 28/12/2019 03:08, Wei Xu wrote:
This patch fixes th
On 17/12/2019 15:14, Durrant, Paul wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of
>> Sergey Dyasli
>> Sent: 17 December 2019 14:08
>> To: xen-de...@lists.xen.org; kasan-...@googlegroups.com; linux-
>> ker...@vger.kernel.org
>> Cc: Juergen Gross ; Sergey Dyasli
>> ; Stefano St
On 07/01/2020 09:28, Wei Xu wrote:
Hi Julien,
On 2020/1/7 17:10, Julien Grall wrote:
On 07/01/2020 08:39, Wei Xu wrote:
Hi Stefano,
On 2020/1/7 6:01, Stefano Stabellini wrote:
On Sat, 28 Dec 2019, Wei Xu wrote:
Hi Julien,
On 2019/12/28 16:09, Julien Grall wrote:
Hi,
On 28/12/2019 03:
Hi Julien,
On 2020/1/7 18:51, Julien Grall wrote:
On 07/01/2020 09:28, Wei Xu wrote:
Hi Julien,
On 2020/1/7 17:10, Julien Grall wrote:
On 07/01/2020 08:39, Wei Xu wrote:
Hi Stefano,
On 2020/1/7 6:01, Stefano Stabellini wrote:
On Sat, 28 Dec 2019, Wei Xu wrote:
Hi Julien,
On 2019/12/2
Durrant, Paul writes ("LRU list of domids"):
> I've been looking at keeping an LRU list of domids to avoid eager recycling
> and I have a few questions...
>
> Keeping history in a file that is updated by libxl seems ok (and I have
> coded it up), but there is the question of host reboot... s
On 06/01/2020 14:40, Jan Beulich wrote:
> On 06.01.2020 15:35, Sergey Dyasli wrote:
>> On 06/01/2020 11:28, George Dunlap wrote:
>>> On 12/19/19 11:15 PM, Andrew Cooper wrote:
On 19/12/2019 11:35, Jan Beulich wrote:
XENVER_changeset
XENVER_commandline
XEN
On 07/01/2020 10:56, Wei Xu wrote:
Maybe I am missing something, but Linux seems to be running fine and I
can't spot any error related to read the active status register. By
any chance, did you build Xen with your patch?
Yes, I built Xen with my patch.
The reason I asked the log is to se
branch xen-unstable
xenbranch xen-unstable
job build-arm64
testid xen-build
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem ch
We had this irc conversation about this. c&p here for our (mostly my)
reference.
11:03 Diziet: I wasn't really considering keeping 2^15 history... I
was thinking much shorter... after all there's nothing to
actually prevent re-creation of exactly the same do
Hi,
On 07/01/2020 09:48, Wei Xu wrote:
On 2020/1/7 17:10, Julien Grall wrote:
On 07/01/2020 08:39, Wei Xu wrote:
Hi Stefano,
On 2020/1/7 6:01, Stefano Stabellini wrote:
On Sat, 28 Dec 2019, Wei Xu wrote:
Hi Julien,
On 2019/12/28 16:09, Julien Grall wrote:
Hi,
On 28/12/2019 03:08, Wei X
flight 145730 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145730/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
Hence it's pointless for it to return an error indicator, and it's even
less useful for it to be __must_check. This is a result of commit
e8afe1124cc1 ("iommu: elide flushing for higher order map/unmap
operations") moving the TLB flushing out of the function.
Signed-off-by: Jan Beulich
--- a/xen
It's not always clear what the best way is to handle unexpected
conditions: whether with ASSERT(), domain_crash(), BUG_ON(), or some
other method. All methods have a risk of introducing security
vulnerabilities and unnecessary instabilities to production systems.
Provide guidelines for different
The "nesting" section in the MAINTAINERS file was not initially
intended to describe the check-in policy for patches, but only how
nesting worked; but since there was no check-in policy, it has been
acting as a de-facto policy.
One problem with this is that the policy is not complete: It doesn't
c
On 1/7/20 12:02 PM, George Dunlap wrote:
> It's not always clear what the best way is to handle unexpected
> conditions: whether with ASSERT(), domain_crash(), BUG_ON(), or some
> other method. All methods have a risk of introducing security
> vulnerabilities and unnecessary instabilities to produ
On 1/7/20 12:03 PM, George Dunlap wrote:
> v2:
> - Modify "sufficient time" to "sufficient time and/or warning".
> - Add a comment explicitly stating that there are exceptions.
> - Move some of the alternate proposals into the changelog itself
Sorry, this should obviously have 'v2' in the subject.
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 required to work even before frame table is set up
From: Wei Liu
They were put into page.h but mm.h is more appropriate.
The real reason is that I will be adding some new functions which
takes mfn_t. It turns out it is a bit difficult to do in page.h.
No functional change.
Signed-off-by: Wei Liu
Acked-by: Jan Beulich
---
Changed since v3:
-
From: Wei Liu
The pl2e and pl1e variables are heavily (ab)used in that function. It
is fine at the moment because all page tables are always mapped so
there is no need to track the life time of each variable.
We will soon have the requirement to map and unmap page tables. We
need to track the l
From: Wei Liu
We will need to have a variable named pl*e when we rewrite
virt_to_xen_l*e. Change pl*e to l*t to reflect better its purpose.
This will make reviewing later patch easier.
No functional change.
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
Reviewed-by: Jan Beulich
---
xen/a
From: Wei Liu
We will soon rewrite the function to handle dynamically mapping and
unmapping of page tables.
No functional change.
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
---
Changed since v4:
- drop the end_of_loop goto label since this function may be refactored
in the future an
This batch adds an alternative alloc-map-unmap-free Xen PTE API to the
normal alloc-free on the xenheap, in preparation of switching to domheap
for Xen page tables. Since map and unmap are basically no-ops now, and
other changes are cosmetic to ease future patches, this batch does not
introduce any
From: Wei Liu
We will soon need to handle dynamically mapping / unmapping page
tables in the said function.
No functional change.
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
---
Changed since v4:
- drop the end_of_loop goto label since this function may be refactored
in the future an
From: Wei Liu
The pl2e and pl1e variables are heavily (ab)used in that function. It
is fine at the moment because all page tables are always mapped so
there is no need to track the life time of each variable.
We will soon have the requirement to map and unmap page tables. We
need to track the li
On Fri, Jan 03, 2020 at 05:22:48PM +, Andrew Cooper wrote:
> The hvm and pae parameters are a remnant of legacy migration. They have 0
> passed in from libxl_stream_read.c's process_record(), and are discarded in
> xc_domain_restore().
>
> While dropping these, update the doxygen comment to b
On Tue, Jan 07, 2020 at 12:06:43PM +, Hongyan Xia wrote:
> From: Wei Liu
>
> They were put into page.h but mm.h is more appropriate.
>
> The real reason is that I will be adding some new functions which
> takes mfn_t. It turns out it is a bit difficult to do in page.h.
>
> No functional cha
AFAICT, it has never had an external user since its introduction
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/boot/trampoline.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x8
On Mon, Jan 06, 2020 at 05:03:52PM +, Andrew Cooper wrote:
> XCFLAGS_CHECKPOINT_COMPRESS has been unused since c/s b15bc4345 (2015),
> XCFLAGS_HVM since c/s 9e8672f1c (2013), and XCFLAGS_STDVGA since c/s
> 087d43326 (2007). Drop the constants, and code which sets them.
>
> The separate hvm pa
No need to use 4-byte integers to store two bits of information.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Jun Nakajima
CC: Kevin Tian
---
xen/arch/x86/hvm/vmx/vmx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/h
On 07/01/2020, 08:23, "Durrant, Paul" wrote:
> -Original Message-
> From: Andrew Cooper
> Sent: 07 January 2020 00:26
> To: Lars Kurth ; xen-devel de...@lists.xenproject.org>
> Cc: Rian Quinn ; Daniel P. Smith
> ; Doug Goldstein ; Brian
> Woods ; Rich Pers
On 07.01.2020 13:02, George Dunlap wrote:
> It's not always clear what the best way is to handle unexpected
> conditions: whether with ASSERT(), domain_crash(), BUG_ON(), or some
> other method. All methods have a risk of introducing security
> vulnerabilities and unnecessary instabilities to prod
Hi Julien,
On 2020/1/7 19:42, Julien Grall wrote:
Hi,
On 07/01/2020 09:48, Wei Xu wrote:
On 2020/1/7 17:10, Julien Grall wrote:
On 07/01/2020 08:39, Wei Xu wrote:
Hi Stefano,
On 2020/1/7 6:01, Stefano Stabellini wrote:
On Sat, 28 Dec 2019, Wei Xu wrote:
Hi Julien,
On 2019/12/28 16:09,
On 07.01.2020 13:03, George Dunlap wrote:
> DISCUSSION
>
> This seems to be a change from people's understanding of the current
> policy. Most people's understanding of the current policy seems to be:
>
> 1. In order to get a change to a given file committed, it must have
> an Ack or Review fro
On 07.01.2020 13:13, Wei Liu wrote:
> On Tue, Jan 07, 2020 at 12:06:43PM +, Hongyan Xia wrote:
>> From: Wei Liu
>>
>> They were put into page.h but mm.h is more appropriate.
>>
>> The real reason is that I will be adding some new functions which
>> takes mfn_t. It turns out it is a bit difficu
On 07.01.2020 12:02, Sergey Dyasli wrote:
> On 06/01/2020 14:40, Jan Beulich wrote:
>> On 06.01.2020 15:35, Sergey Dyasli wrote:
>>> On 06/01/2020 11:28, George Dunlap wrote:
On 12/19/19 11:15 PM, Andrew Cooper wrote:
> On 19/12/2019 11:35, Jan Beulich wrote:
> XENVER_changeset
On 07.01.2020 13:15, Andrew Cooper wrote:
> AFAICT, it has never had an external user since its introduction
I guess it was only ever anticipated to gain one.
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@
On 07.01.2020 13:25, Andrew Cooper wrote:
> No need to use 4-byte integers to store two bits of information.
>
> Signed-off-by: Andrew Cooper
In principle
Reviewed-by: Jan Beulich
But ...
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -3978,7 +3978,7 @@ void vmx_vme
On 27.12.2019 10:01, Jan Beulich wrote:
> (re-sending, as I still don't see the mail having appeared on the list)
>
> On 23.12.2019 15:04, Alexandru Stefan ISAILA wrote:
>> Changes since V5:
>> - Add black lines
>
> Luckily no color comes through in plain text mails ;-)
>
>> --- a/xen/arc
Hi George,
On 07/01/2020 12:02, George Dunlap wrote:
It's not always clear what the best way is to handle unexpected
conditions: whether with ASSERT(), domain_crash(), BUG_ON(), or some
other method. All methods have a risk of introducing security
vulnerabilities and unnecessary instabilities t
On Tue, Jan 07, 2020 at 02:09:05PM +0100, Jan Beulich wrote:
> On 07.01.2020 13:13, Wei Liu wrote:
> > On Tue, Jan 07, 2020 at 12:06:43PM +, Hongyan Xia wrote:
> >> From: Wei Liu
> >>
> >> They were put into page.h but mm.h is more appropriate.
> >>
> >> The real reason is that I will be addin
On Tue, 2020-01-07 at 14:09 +0100, Jan Beulich wrote:
> ...
>
> Looks like I simply forgot every time I went through my list of
> pending (for the various stages of processing) patches. I guess
> patches 3 and 4 are also independent of patch 2 and hence could
> go in as well.
If so, looks like pa
Travis reports: https://travis-ci.org/andyhhp/xen/jobs/633751811
mem_sharing.c:361:13: error: 'rmap_has_entries' defined but not used
[-Werror=unused-function]
static bool rmap_has_entries(const struct page_info *page)
^
cc1: all warnings being treated as errors
This happen
On 07.01.2020 14:25, Alexandru Stefan ISAILA wrote:
> On 27.12.2019 10:01, Jan Beulich wrote:
>> On 23.12.2019 15:04, Alexandru Stefan ISAILA wrote:
>>> --- a/xen/arch/x86/mm/mem_access.c
>>> +++ b/xen/arch/x86/mm/mem_access.c
>>> @@ -366,11 +366,12 @@ long p2m_set_mem_access(struct domain *d, gfn_
On Tue, Jan 07, 2020 at 01:48:41PM +, Xia, Hongyan wrote:
> On Tue, 2020-01-07 at 14:09 +0100, Jan Beulich wrote:
> > ...
> >
> > Looks like I simply forgot every time I went through my list of
> > pending (for the various stages of processing) patches. I guess
> > patches 3 and 4 are also ind
SYMPTOMS
A Xen host is found to lock up with messages on console along the
following lines:-
NMI watchdog: BUG: soft lockup - CPU#2 stuck for 23s!
Later on in the system log, reference is often made to a specific
program that happens to be running at the time, however the program
referred to is
On 07.01.2020 15:55, Jan Beulich wrote:
> On 07.01.2020 14:25, Alexandru Stefan ISAILA wrote:
>> On 27.12.2019 10:01, Jan Beulich wrote:
>>> On 23.12.2019 15:04, Alexandru Stefan ISAILA wrote:
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -366,11 +366,12
On 20/12/2019 06:26, Jürgen Groß wrote:
> On 19.12.19 13:45, Sergey Dyasli wrote:
>> Hi Juergen,
>>
>> We recently did another quick test of core scheduling mode, and the following
>> failures were found:
>>
>> 1. live-patch apply failures:
>>
>> (XEN) [ 1058.751974] livepatch: lp_1_1: Timed o
flight 145736 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145736/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
On Tue, Jan 7, 2020 at 6:49 AM Andrew Cooper wrote:
>
> Travis reports: https://travis-ci.org/andyhhp/xen/jobs/633751811
>
> mem_sharing.c:361:13: error: 'rmap_has_entries' defined but not used
> [-Werror=unused-function]
>static bool rmap_has_entries(const struct page_info *page)
>
Due to the unconditional updating of dom->highmem_end in
libxl__domain_device_construct_rdm() I've observed on a 2Gb HVM guest
with a passed through device (without overly large BARs, and with no RDM
ranges at all)
(d2) RAM in high memory; setting high_mem resource base to 1
...
(d2) E820
> > > Please send me agenda items for this Thursday's community call (we
> > agreed to move it by 1 week) preferably by Wednesday!
> > >
> > > A draft agenda is
> > at https://cryptpad.fr/pad/#/2/pad/edit/ERZtMYD5j6k0sv-NG6Htl-AJ/
> > > Please add agenda items to the documen
On 07.01.2020 15:31, Alexandru Stefan ISAILA wrote:
>
>
> On 07.01.2020 15:55, Jan Beulich wrote:
>> On 07.01.2020 14:25, Alexandru Stefan ISAILA wrote:
>>> On 27.12.2019 10:01, Jan Beulich wrote:
On 23.12.2019 15:04, Alexandru Stefan ISAILA wrote:
> --- a/xen/arch/x86/mm/mem_access.c
>>
On 07/01/2020 12:55, Wei Xu wrote:
Hi Julien,
As only one entity should manage the UART (i.e Xen or Dom0), we today
assume this will be managed by Xen. Xen should expose a partial
virtual UART (only a few registers are emulating) to dom0 in replacement.
This is usually done by the UART driv
On 06.01.2020 16:54, Andrew Cooper wrote:
> There is no point performing the masking calculations if we are going to
> throw the result away.
A reasonably optimizing compiler ought to do so. It's slightly less
source code the original way. Nevertheless I don't really mind the
change, so ...
> No
On 06.01.2020 16:54, Andrew Cooper wrote:
> c/s ec92fcd1d08, which caused the trampoline GDT Access bits to be set,
> removed the final writes which occurred between enabling paging and switching
> to the high mappings. There don't plausibly need to be any memory writes in
> few instructions is ta
On Sun, Jan 05, 2020 at 09:57:56PM +, Andrew Cooper wrote:
[...]
> >
> >> The locked bit is probably a good idea, but one aspect missing here is
> >> the check to see whether the hypercall page is already enabled, which I
> >> expect is for a kexec crash scenario.
> >>
> >> However, the most im
On 06.01.2020 16:54, Andrew Cooper wrote:
> First, it is undefined to have superpages and MTRRs disagree on cacheability
> boundaries, and nothing this early in boot has checked that it is safe to use
> superpages here.
Stating this here gives, at least to me, the impression that you change
things
On 07/01/2020 15:21, Jan Beulich wrote:
> On 06.01.2020 16:54, Andrew Cooper wrote:
>> c/s ec92fcd1d08, which caused the trampoline GDT Access bits to be set,
>> removed the final writes which occurred between enabling paging and switching
>> to the high mappings. There don't plausibly need to be
On 06.01.2020 16:54, Andrew Cooper wrote:
> The need for Xen to be identity mapped into the bootmap is not obvious, and
> differs between the MB and EFI boot paths. Furthermore, the EFI side is
> further complicated by spraying non-identity aliases into the mix.
What (intentional) aliases are you
On Sun, Jan 05, 2020 at 10:06:08PM +, Andrew Cooper wrote:
> On 05/01/2020 21:22, Wei Liu wrote:
> > On Sun, Jan 05, 2020 at 07:08:28PM +, Andrew Cooper wrote:
> >>> +static inline uint64_t hv_do_hypercall(uint64_t control, paddr_t input,
> >>> paddr_t output)
> >>> +{
> >>> +uint64_t
On 07.01.2020 16:51, Andrew Cooper wrote:
> On 07/01/2020 15:21, Jan Beulich wrote:
>> On 06.01.2020 16:54, Andrew Cooper wrote:
>>> c/s ec92fcd1d08, which caused the trampoline GDT Access bits to be set,
>>> removed the final writes which occurred between enabling paging and
>>> switching
>>> to
On Mon, Jan 06, 2020 at 10:38:23AM +0100, Jan Beulich wrote:
[...]
> > +
> > +static inline uint64_t hv_do_rep_hypercall(uint16_t code, uint16_t
> > rep_count,
> > + uint16_t varhead_size,
> > + paddr_t input, padd
On 1/7/20 1:05 PM, Jan Beulich wrote:
> On 07.01.2020 13:03, George Dunlap wrote:
>> DISCUSSION
>>
>> This seems to be a change from people's understanding of the current
>> policy. Most people's understanding of the current policy seems to be:
>>
>> 1. In order to get a change to a given file co
On 07.01.2020 17:16, Jan Beulich wrote:
> On 06.01.2020 16:54, Andrew Cooper wrote:
>> --- a/xen/arch/x86/efi/efi-boot.h
>> +++ b/xen/arch/x86/efi/efi-boot.h
>> @@ -584,21 +584,24 @@ static void __init efi_arch_memory_setup(void)
>> if ( !efi_enabled(EFI_LOADER) )
>> return;
>>
>> -
On Mon, Jan 06, 2020 at 11:27:18AM +0100, Jan Beulich wrote:
> On 05.01.2020 17:47, Wei Liu wrote:
> > Hyper-V's input / output argument must be 8 bytes aligned an not cross
> > page boundary. The easiest way to satisfy those requirements is to use
> > percpu page.
>
> I'm not sure "easiest" is re
On Mon, Jan 06, 2020 at 11:31:50AM +0100, Jan Beulich wrote:
> On 05.01.2020 17:48, Wei Liu wrote:
> > --- a/xen/include/asm-x86/guest/hyperv.h
> > +++ b/xen/include/asm-x86/guest/hyperv.h
> > @@ -66,6 +66,7 @@ struct ms_hyperv_info {
> > extern struct ms_hyperv_info ms_hyperv;
> >
> > DECLARE_
On 06.01.2020 16:54, Andrew Cooper wrote:
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -689,12 +689,15 @@ trampoline_setup:
> sub $(L2_PAGETABLE_ENTRIES*8),%eax
> loop1b
>
> -/*
> - * During boot, hook 4kB mappings of first 2MB o
On Tue, Jan 07, 2020 at 03:58:07PM +0100, Jan Beulich wrote:
> Due to the unconditional updating of dom->highmem_end in
> libxl__domain_device_construct_rdm() I've observed on a 2Gb HVM guest
> with a passed through device (without overly large BARs, and with no RDM
> ranges at all)
>
> (d2) RAM i
On 07.01.2020 17:17, George Dunlap wrote:
> On 1/7/20 1:05 PM, Jan Beulich wrote:
>> On 07.01.2020 13:03, George Dunlap wrote:
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -104,7 +104,53 @@ Descriptions of section entries:
>>>xen-maintainers-
>>>
>>>
>>> -The meaning of nesting:
>
From: Wei Liu Sent: Tuesday, January 7, 2020 8:34 AM
>
> On Mon, Jan 06, 2020 at 11:27:18AM +0100, Jan Beulich wrote:
> > On 05.01.2020 17:47, Wei Liu wrote:
> > > Hyper-V's input / output argument must be 8 bytes aligned an not cross
> > > page boundary. The easiest way to satisfy those requirem
On 06.01.2020 16:54, Andrew Cooper wrote:
> Now that NULL will fault at boot, there is no need for a special constant to
> signify "current not set up yet".
Mind making this "... no strong need ..."? The benefit of an easily
recognizable value goes away, but I guess we'll be fine without.
IOW I'm
flight 145740 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145740/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 07.01.2020 17:33, Wei Liu wrote:
> On Mon, Jan 06, 2020 at 11:27:18AM +0100, Jan Beulich wrote:
>> On 05.01.2020 17:47, Wei Liu wrote:
>>> Hyper-V's input / output argument must be 8 bytes aligned an not cross
>>> page boundary. The easiest way to satisfy those requirements is to use
>>> percpu
flight 145725 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145725/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-rtds 15 guest-stop fail in 145691 pass in 145725
test-armhf-armhf-xl-vhd 15
On 07/01/2020 15:43, Jan Beulich wrote:
> On 06.01.2020 16:54, Andrew Cooper wrote:
>> First, it is undefined to have superpages and MTRRs disagree on cacheability
>> boundaries, and nothing this early in boot has checked that it is safe to use
>> superpages here.
> Stating this here gives, at leas
On Tue, Jan 07, 2020 at 06:08:19PM +0100, Jan Beulich wrote:
> On 07.01.2020 17:33, Wei Liu wrote:
> > On Mon, Jan 06, 2020 at 11:27:18AM +0100, Jan Beulich wrote:
> >> On 05.01.2020 17:47, Wei Liu wrote:
> >>> Hyper-V's input / output argument must be 8 bytes aligned an not cross
> >>> page bounda
flight 145743 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145743/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
I'm told that GENMASK_ULL shouldn't be used outside of Arm code in its
current form.
Requested-by: Jan Beulich
Signed-off-by: Wei Liu
---
xen/include/asm-x86/guest/hyperv-tlfs.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/include/asm-x86/guest/hyperv-tlfs.h
b/
Fix two issues discovered by Jan.
Wei Liu (2):
x86/hyperv: drop usage of GENMASK_ULL from hyperv-tlfs.h
x86/hyperv: drop all __packed from hyperv-tlfs.h
xen/include/asm-x86/guest/hyperv-tlfs.h | 60 -
1 file changed, 30 insertions(+), 30 deletions(-)
--
2.20.1
___
All structures are already naturally aligned. Linux added those
attributes out of paranoia.
In Xen we've had instance we had to drop pointless __packed to placate
gcc 9 (see ca9310b24e), it is better drop those attributes.
Requested-by: Jan Beulich
Signed-off-by: Wei Liu
---
xen/include/asm-x8
On 07/01/2020 16:16, Jan Beulich wrote:
> On 06.01.2020 16:54, Andrew Cooper wrote:
>> The need for Xen to be identity mapped into the bootmap is not obvious, and
>> differs between the MB and EFI boot paths. Furthermore, the EFI side is
>> further complicated by spraying non-identity aliases into
On 07/01/2020 16:30, Jan Beulich wrote:
>>> for ( i = 0; i < 8; ++i )
>>> {
>>> unsigned int slot = (xen_phys_start >> L2_PAGETABLE_SHIFT) + i;
>>> paddr_t addr = slot << L2_PAGETABLE_SHIFT;
>>>
>>> l2_identmap[slot] = l2e_from_paddr(addr,
>>> PAGE_HYPERVISOR
On 07/01/2020 16:35, Jan Beulich wrote:
> On 06.01.2020 16:54, Andrew Cooper wrote:
>> --- a/xen/arch/x86/boot/head.S
>> +++ b/xen/arch/x86/boot/head.S
>> @@ -689,12 +689,15 @@ trampoline_setup:
>> sub $(L2_PAGETABLE_ENTRIES*8),%eax
>> loop1b
>>
>> -/*
>> -
On 07/01/2020 16:52, Jan Beulich wrote:
> On 06.01.2020 16:54, Andrew Cooper wrote:
>> Now that NULL will fault at boot, there is no need for a special constant to
>> signify "current not set up yet".
> Mind making this "... no strong need ..."? The benefit of an easily
> recognizable value goes aw
On 07/01/2020 16:19, Jan Beulich wrote:
> On 07.01.2020 16:51, Andrew Cooper wrote:
>> On 07/01/2020 15:21, Jan Beulich wrote:
>>> On 06.01.2020 16:54, Andrew Cooper wrote:
c/s ec92fcd1d08, which caused the trampoline GDT Access bits to be set,
removed the final writes which occurred betw
Hello,
you're probably right about the malformed commandline for USB-passthru:
With upstream qemu I get
qemu-system-x86_64: -usbdevice tablet: '-usbdevice' is deprecated,
please use '-device usb-...' instead
qemu-system-x86_64: -usbdevice host:0d46:3003: '-usbdevice' is
deprecated, please us
flight 145750 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145750/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
1 - 100 of 124 matches
Mail list logo
