On 1/6/20 10:38 AM, Jürgen Groß wrote:
> On 06.01.20 08:56, Santucco wrote:
>> Hello,
>>
>> I’m trying to use vdispl interface from PV OS, it doesn’t work.
>> Configuration details:
>> Xen 4.12.1
>> Dom0: Linux 4.20.17-gentoo #13 SMP Sat Dec 28 11:12:24 MSK 2019
>> x86_64 Intel(R)
On 08.01.20 06:50, Tao Xu wrote:
Hi,
When I use xen-hptool cpu-offline/cpu-online to let CPU in a socket
online/offline using the script as follows:
for((j=48;j<=95;j++));
do
xen-hptool cpu-offline $j
done
for((j=48;j<=95;j++));
do
xen-hptool cpu-online $j
done
Xen crash when cpu
flight 145777 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145777/
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
Hi,
When I use xen-hptool cpu-offline/cpu-online to let CPU in a socket
online/offline using the script as follows:
for((j=48;j<=95;j++));
do
xen-hptool cpu-offline $j
done
for((j=48;j<=95;j++));
do
xen-hptool cpu-online $j
done
Xen crash when cpu re-online. I use the upstream
branch xen-unstable
xenbranch xen-unstable
job build-i386
testid xen-build
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen
flight 145770 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145770/
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 145767 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145767/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 70911f1f4aee0366b6122f2b90d367ec0f066beb
baseline version:
ovmf
flight 145749 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145749/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw 18 leak-check/check fail REGR. vs. 145725
Tests which did
flight 145765 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145765/
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 145759 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145759/
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
From: Eduardo Valentin
System instability are seen during resume from hibernation when system
is under heavy CPU load. This is due to the lack of update of sched
clock data, and the scheduler would then think that heavy CPU hog
tasks need more time in CPU, causing the system to freeze
during the
From: Aleksei Besogonov
The SNAPSHOT_SET_SWAP_AREA is supposed to be used to set the hibernation
offset on a running kernel to enable hibernating to a swap file.
However, it doesn't actually update the swsusp_resume_block variable. As
a result, the hibernation fails at the last step (after all
shutdown_pirq is invoked during hibernation path and hence
PIRQs should be restarted during resume.
Before this commit'020db9d3c1dc0a' xen/events: Fix interrupt lost
during irq_disable and irq_enable startup_pirq was automatically
called during irq_enable however, after this commit pirq's did not
From: Munehisa Kamata
There are no pm handlers for the legacy devices, so during tear down
stale event channel <> IRQ mapping may still remain in the image and resume
may fail. To avoid adding much code by implementing handlers for legacy
devices, add a simple helper function to "shutdown"
From: Munehisa Kamata
Currently, steal time accounting code in scheduler expects steal clock
callback to provide monotonically increasing value. If the accounting
code receives a smaller value than previous one, it uses a negative
value to calculate steal time and results in incorrectly updated
From: Munehisa Kamata
Add freeze, thaw and restore callbacks for PM suspend and hibernation
support. All frontend drivers that needs to use PM_HIBERNATION/PM_SUSPEND
events, need to implement these xenbus_driver callbacks.
The freeze handler stops a block-layer queue and disconnect the
frontend
From: Munehisa Kamata
Add freeze, thaw and restore callbacks for PM suspend and hibernation
support. The freeze handler simply disconnects the frotnend from the
backend and frees resources associated with queues after disabling the
net_device from the system. The restore handler just changes the
From: Munehisa Kamata
Add Xen PVHVM specific system core callbacks for PM suspend and
hibernation support. The callbacks suspend and resume Xen
primitives,like shared_info, pvclock and grant table. Note that
Xen suspend can handle them in a different manner, but system
core callbacks are called
Introduce a small function which re-uses shared page's PA allocated
during guest initialization time in reserve_shared_info() and not
allocate new page during resume flow.
It also does the mapping of shared_info_page by calling
xen_hvm_init_shared_info() to use the function.
Signed-off-by:
From: Munehisa Kamata
Since commit b3e96c0c7562 ("xen: use freeze/restore/thaw PM events for
suspend/resume/chkpt"), xenbus uses PMSG_FREEZE, PMSG_THAW and
PMSG_RESTORE events for Xen suspend. However, they're actually assigned
to xenbus_dev_suspend(), xenbus_dev_cancel() and xenbus_dev_resume()
From: Munehisa Kamata
Guest hibernation is different from xen suspend/resume/live migration.
Xen save/restore does not use pm_ops as is needed by guest hibernation.
Hibernation in guest follows ACPI path and is guest inititated , the
hibernation image is saved within guest as compared to later
Hello,
I am sending out a V2 version of series of patches that implements guest
PM hibernation.
These guests are running on xen hypervisor. The patches had been tested
against mainstream kernel. EC2 instance hibernation feature is provided
to the AWS EC2 customers. PM hibernation uses swap space
flight 145756 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145756/
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 145752 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145752/
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
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
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
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
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
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: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,
>>>
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
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
---
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
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
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
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
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
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 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 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
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
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
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:
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
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
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;
> >
> >
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
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 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
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,
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 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 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
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:
> 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
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
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
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 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
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
> > > 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
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
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)
>
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 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
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
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 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
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,
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
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
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
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
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 ;-)
>
>> ---
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
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
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:
>
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
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
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: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
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
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
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
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
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
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
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
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
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
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
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
---
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
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
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:
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
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
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
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
---
1 - 100 of 124 matches
Mail list logo
