On 25.09.20 06:59, Jürgen Groß wrote:
On 24.09.20 22:23, Andrew Cooper wrote:
On 23/09/2020 06:24, Juergen Gross wrote:
xenguest.h includes xenctrl_dom.h, which is including the Xen internal
xen/libelf/libelf.h. This results in build failures for components
using libxenguest when being built
On 24.09.20 22:23, Andrew Cooper wrote:
On 23/09/2020 06:24, Juergen Gross wrote:
xenguest.h includes xenctrl_dom.h, which is including the Xen internal
xen/libelf/libelf.h. This results in build failures for components
using libxenguest when being built outside the Xen build environment.
Fix
flight 154663 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154663/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-2 68 xtf/test-hvm64-xsa-221 fail REGR. vs. 154601
On Thu, Sep 24, 2020 at 01:13:29PM +0200, Vlastimil Babka wrote:
>On 9/16/20 8:34 PM, David Hildenbrand wrote:
>> Page isolation doesn't actually touch the pages, it simply isolates
>> pageblocks and moves all free pages to the MIGRATE_ISOLATE freelist.
>>
>> We already place pages to the tail of
flight 154702 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154702/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
On 23/09/2020 06:24, Juergen Gross wrote:
> xenguest.h includes xenctrl_dom.h, which is including the Xen internal
> xen/libelf/libelf.h. This results in build failures for components
> using libxenguest when being built outside the Xen build environment.
>
> Fix that by guarding the include of
On 23/09/2020 07:48, Olaf Hering wrote:
> The caller of writev_exact should be notified about malloc errors
> when dealing with partial writes.
>
> Signed-off-by: Olaf Hering
Reviewed-by: Andrew Cooper
On 24/09/2020 19:08, Olaf Hering wrote:
> If the bitmap is used to represent domU pages, the amount of memory is
> limited to 8TB due to the 32bit value. Adjust the code to use 64bit
> values as input. All callers already use some form of 64bit as input,
> so no further adjustment is required.
>
>
flight 154728 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154728/
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 9/24/20 9:58 AM, Christoph Hellwig wrote:
> Replace the last call to alloc_vm_area with an open coded version using
> an iterator in struct gnttab_vm_area instead of the triple indirection
> magic in alloc_vm_area.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Boris Ostrovsky
On 9/24/20 9:58 AM, Christoph Hellwig wrote:
> Replacing alloc_vm_area with get_vm_area_caller + apply_page_range
> allows to fill put the phys_addr values directly instead of doing
> another loop over all addresses.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Boris Ostrovsky
-boris
flight 154649 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154649/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail
REGR. vs.
On Thu, Sep 24, 2020 at 05:44:09PM +0200, Jan Beulich wrote:
> On 02.09.2020 03:08, Elliott Mitchell wrote:
> > @@ -33,12 +38,12 @@ cscope.po.out
> > .vscode
> >
> > dist
> > -stubdom/*.tar.gz
> >
> > autom4te.cache/
> > config.log
> > config.status
> > config.cache
> > +config.h
> >
flight 154651 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154651/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-xtf-amd64-amd64-3 93 xtf/test-pv32pae-xsa-339 fail never pass
test-xtf-amd64-amd64-1 93
Hi all,
We have our answer in regards to getting away from "master" as default
branch name. GitHub will default to "main" from Oct 1.
https://github.com/github/renaming
https://www.zdnet.com/article/github-to-replace-master-with-main-starting-next-month/
Cheers,
Stefano
> -Original Message-
> From: Xen-devel On Behalf Of Paul
> Durrant
> Sent: Thursday, September 24, 2020 9:10 AM
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Andrew Cooper
> ; Daniel De Graaf ;
> George Dunlap ; Ian Jackson
> ; Jan Beulich ; Julien Grall
> ; Marek
flight 154644 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154644/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 154428
On Tue, Sep 1, 2020 at 1:33 AM Roger Pau Monne wrote:
>
> This is in preparation for the logic behind MEMORY_DEVICE_DEVDAX also
> being used by non DAX devices.
>
FWIW I would not call this MEMORY_DEVICE_GENERIC. This is really
MEMORY_DEVICE_SIMPLE and the kernel-doc can clarify in contrast to
On 24.09.20 20:25, Julien Grall wrote:
Hi Julien.
On 23/09/2020 21:16, Oleksandr wrote:
On 23.09.20 21:03, Julien Grall wrote:
Hi,
Hi Julien
On 10/09/2020 21:22, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
I believe I am the originally author of this code...
If the bitmap is used to represent domU pages, the amount of memory is
limited to 8TB due to the 32bit value. Adjust the code to use 64bit
values as input. All callers already use some form of 64bit as input,
so no further adjustment is required.
Signed-off-by: Olaf Hering
---
Hello Jürgen,
Jürgen Groß writes:
> On 12.06.20 13:30, Volodymyr Babchuk wrote:
>> On Fri, 2020-06-12 at 06:43 +0200, Jürgen Groß wrote:
>>> On 12.06.20 02:22, Volodymyr Babchuk wrote:
[...]
+delta = NOW() - v->hyp_entry_time;
+atomic_add(delta, >sched_unit->hyp_time);
+
On 24.09.20 19:02, Oleksandr wrote:
Hi
On 24.09.20 14:08, Jan Beulich wrote:
Hi Jan
On 23.09.2020 22:16, Oleksandr wrote:
On 23.09.20 21:03, Julien Grall wrote:
On 10/09/2020 21:22, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
@@ -91,6 +108,28 @@ struct arch_domain
On 10/09/2020 21:21, Oleksandr Tyshchenko wrote:
+static bool hvm_wait_for_io(struct hvm_ioreq_vcpu *sv, ioreq_t *p)
+{
+unsigned int prev_state = STATE_IOREQ_NONE;
+unsigned int state = p->state;
+uint64_t data = ~0;
+
+smp_rmb();
+
+/*
+ * The only reason we should
> On 24 Sep 2020, at 18:25, Bertrand Marquis wrote:
>
> Hi,
>
> Sorry for the delay.
>
>> On 11 Sep 2020, at 01:33, Stefano Stabellini wrote:
>>
>> On Thu, 10 Sep 2020, Jan Beulich wrote:
>> - should we backport the support for this hypercall in older kernel
>> releases ?
>
On 23/09/2020 21:16, Oleksandr wrote:
On 23.09.20 21:03, Julien Grall wrote:
Hi,
Hi Julien
On 10/09/2020 21:22, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
I believe I am the originally author of this code...
Sorry, will fix
This patch adds basic IOREQ/DM support
Hi,
Sorry for the delay.
> On 11 Sep 2020, at 01:33, Stefano Stabellini wrote:
>
> On Thu, 10 Sep 2020, Jan Beulich wrote:
> - should we backport the support for this hypercall in older kernel
> releases ?
It's a bug fix to KPTI, and as such ought to be at least eligible for
On 24/09/2020 12:08, Jan Beulich wrote:
On 23.09.2020 22:16, Oleksandr wrote:
On 23.09.20 21:03, Julien Grall wrote:
On 10/09/2020 21:22, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
@@ -91,6 +108,28 @@ struct arch_domain
#endif
} __cacheline_aligned;
+enum
On 24.09.20 14:16, Jan Beulich wrote:
Hi Jan
On 22.09.2020 21:32, Oleksandr wrote:
On 16.09.20 11:50, Jan Beulich wrote:
On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1651,6 +1651,11 @@ long do_memory_op(unsigned long cmd,
The stretch (Debian oldstable) kernel has been updated, causing our
Xen 4.10 tests (which are still using stretch) to break. This update
seems to fix it.
Reported-by: Jan Beulich
Signed-off-by: Ian Jackson
---
production-config | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 24.09.20 14:08, Jan Beulich wrote:
Hi Jan
On 23.09.2020 22:16, Oleksandr wrote:
On 23.09.20 21:03, Julien Grall wrote:
On 10/09/2020 21:22, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
@@ -91,6 +108,28 @@ struct arch_domain
#endif
} __cacheline_aligned;
+enum
.snip..
> > For the reason, I'd like to suggest to keep this as is for now and expand it
> > with the 'exceptions list' idea or something better, if a real use case
> > comes
> > out later.
>
> I agree. I'm happy to take patches to implement more fine grained
> control, but that shouldn't
On 24.09.2020 17:38, Oleksandr wrote:
> On 24.09.20 13:58, Jan Beulich wrote:
>> On 23.09.2020 14:28, Oleksandr wrote:
>>> On 22.09.20 18:52, Jan Beulich wrote:
On 22.09.2020 17:05, Oleksandr wrote:
> @@ -247,7 +247,7 @@ static gfn_t hvm_alloc_legacy_ioreq_gfn(struct
>
flight 154679 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154679/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
On 02.09.2020 03:08, Elliott Mitchell wrote:
> @@ -33,12 +38,12 @@ cscope.po.out
> .vscode
>
> dist
> -stubdom/*.tar.gz
>
> autom4te.cache/
> config.log
> config.status
> config.cache
> +config.h
> config/Toplevel.mk
> config/Paths.mk
While in userland config.h may indeed be a
On 24.09.20 13:58, Jan Beulich wrote:
Hi Jan
On 23.09.2020 14:28, Oleksandr wrote:
On 22.09.20 18:52, Jan Beulich wrote:
On 22.09.2020 17:05, Oleksandr wrote:
3. *arch.hvm.hvm_io*: We could also use the following:
#define ioreq_get_io_completion(v)
On 24/09/2020 11:06, Paul Durrant wrote:
>> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
>> index d1cfc8fb4a..e82307bdae 100644
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -4591,6 +4591,26 @@ int xenmem_add_to_physmap_one(
>> return rc;
>> }
>>
>> +unsigned int
On 23.09.2020 12:18, Andrew Cooper wrote:
> Despite appearing to be a deliberate design choice of early PV64, the
> resulting behaviour for unregistered SYSCALL callbacks creates an untenable
> testability problem for Xen. Furthermore, the behaviour is undocumented,
> bizarre, and inconsistent
On Thu, Sep 24, 2020 at 12:27:14PM +0200, SeongJae Park wrote:
> On Thu, 24 Sep 2020 12:13:44 +0200 "Roger Pau Monné"
> wrote:
>
> > On Wed, Sep 23, 2020 at 04:09:30PM -0400, Konrad Rzeszutek Wilk wrote:
> > > On Tue, Sep 22, 2020 at 09:01:25AM +0200, SeongJae Park wrote:
> > > > From: SeongJae
Fix the warning:
arch/x86/pci/xen.c:423:13: warning:
no previous prototype for ‘xen_msi_init’ [-Wmissing-prototypes]
Reported-by: Hulk Robot
Signed-off-by: Li Heng
---
arch/x86/pci/xen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
When running as a stubdom Xenstore should set the maximum number of
grants needed via a call of xengnttab_set_max_grants(), as otherwise
the number of domains which can be supported will be 128 only (the
default number of grants supported by Mini-OS).
Signed-off-by: Juergen Gross
---
This is a
>> If that would ever change, the optimization here would be lost and we
>> would have to think of something else. Nothing would actually break -
>> and it's all kept directly in page_alloc.c
>
> Sure, but then it can become a pointless code churn.
Indeed, and if there are valid concerns that
On Wed, Sep 23, 2020 at 04:09:30PM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Sep 22, 2020 at 09:01:25AM +0200, SeongJae Park wrote:
> > From: SeongJae Park
> >
> > Persistent grants feature provides high scalability. On some small
> > systems, however, it could incur data copy overhead[1]
flight 154641 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154641/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-2 68 xtf/test-hvm64-xsa-221 fail REGR. vs. 154350
Hi Stefano,
> On 23 Sep 2020, at 18:41, Stefano Stabellini wrote:
>
> On Wed, 23 Sep 2020, Bertrand Marquis wrote:
>>> On 23 Sep 2020, at 12:17, Julien Grall wrote:
>>> On 23/09/2020 11:50, Bertrand Marquis wrote:
Hi,
> On 23 Sep 2020, at 09:28, Julien Grall wrote:
>
> From:
On 9/23/20 5:26 PM, David Hildenbrand wrote:
> On 23.09.20 16:31, Vlastimil Babka wrote:
>> On 9/16/20 9:31 PM, David Hildenbrand wrote:
>>
>
> Hi Vlastimil,
>
>> I see the point, but I don't think the head/tail mechanism is great for
>> this. It
>> might sort of work, but with other
From: "Matthew Wilcox (Oracle)"
* Document that you can call vfree() on an address returned from vmap()
* Remove the note about the minimum size -- the minimum size of a vmalloc
allocation is one page
* Add a Context: section
* Fix capitalisation
* Reword the prohibition on calling from
All users are gone now.
Signed-off-by: Christoph Hellwig
---
include/linux/vmalloc.h | 5 +
mm/nommu.c | 7 --
mm/vmalloc.c| 48 -
3 files changed, 1 insertion(+), 59 deletions(-)
diff --git a/include/linux/vmalloc.h
Replace the last call to alloc_vm_area with an open coded version using
an iterator in struct gnttab_vm_area instead of the triple indirection
magic in alloc_vm_area.
Signed-off-by: Christoph Hellwig
---
arch/x86/xen/grant-table.c | 27 ---
1 file changed, 20
i915_gem_object_map implements fairly low-level vmap functionality in
a driver. Split it into two helpers, one for remapping kernel memory
which can use vmap, and one for I/O memory that uses vmap_pfn.
The only practical difference is that alloc_vm_area prefeaults the
vmalloc area PTEs, which
Just manually pre-fault the PTEs using apply_to_page_range.
Co-developed-by: Minchan Kim
Signed-off-by: Christoph Hellwig
---
mm/zsmalloc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index c36fdff9a37131..918c7b019b3d78 100644
Add a proper helper to remap PFNs into kernel virtual space so that
drivers don't have to abuse alloc_vm_area and open coded PTE
manipulation for it.
Signed-off-by: Christoph Hellwig
---
include/linux/vmalloc.h | 1 +
mm/Kconfig | 3 +++
mm/vmalloc.c| 45
Replacing alloc_vm_area with get_vm_area_caller + apply_page_range
allows to fill put the phys_addr values directly instead of doing
another loop over all addresses.
Signed-off-by: Christoph Hellwig
---
drivers/xen/xenbus/xenbus_client.c | 30 --
1 file changed, 16
Hi Andrew,
this series removes alloc_vm_area, which was left over from the big
vmalloc interface rework. It is a rather arkane interface, basicaly
the equivalent of get_vm_area + actually faulting in all PTEs in
the allocated area. It was originally addeds for Xen (which isn't
modular to start
Besides calling the callback on each page, apply_to_page_range also has
the effect of pre-faulting all PTEs for the range. To support callers
that only need the pre-faulting, make the callback optional.
Based on a patch from Minchan Kim .
Signed-off-by: Christoph Hellwig
---
mm/memory.c | 16
Add a flag so that vmap takes ownership of the passed in page array.
When vfree is called on such an allocation it will put one reference
on each page, and free the page array itself.
Signed-off-by: Christoph Hellwig
---
include/linux/vmalloc.h | 1 +
mm/vmalloc.c| 9 +++--
2
kmap for !PageHighmem is just a convoluted way to say page_address,
and kunmap is a no-op in that case.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git
shmem_pin_map somewhat awkwardly reimplements vmap using
alloc_vm_area and manual pte setup. The only practical difference
is that alloc_vm_area prefeaults the vmalloc area PTEs, which doesn't
seem to be required here (and could be added to vmap using a flag if
actually required). Switch to use
On 23.09.2020 12:18, Andrew Cooper wrote:
> A 64bit IRET can restore NT - the faulting case is when NT is set in the live
> flags. This change had an unintended consequence of causing the NT flag to
> spontaneously disappear from guest context whenever a interrupt/exception
> occurred.
>
> In
On 23.09.2020 12:18, Andrew Cooper wrote:
> It is a matter of guest kernel policy what to do with offending userspace, and
> terminating said userspace may not be the action chosen.
>
> Linux explicitly tolerates this case.
>
> Reported-by: Andy Lutomirski
> Fixes: fdac951560 ("x86: clear
On 9/16/20 8:34 PM, David Hildenbrand wrote:
> __free_pages_core() is used when exposing fresh memory to the buddy
> during system boot and when onlining memory in generic_online_page().
>
> generic_online_page() is used in two cases:
>
> 1. Direct memory onlining in online_pages().
> 2.
On Thu, Sep 24, 2020 at 01:22:35PM +0100, Tvrtko Ursulin wrote:
> CI says series looks good from the i915 perspective (*).
>
> I don't know how will you handle it logistically, but when you have final
> version I am happy to re-read and r-b the i915 patches.
I'll resend the series later today,
From: Paul Durrant
Paul Durrant (8):
xen/common: introduce a new framework for save/restore of 'domain'
context
xen/common/domctl: introduce XEN_DOMCTL_get/setdomaincontext
tools/misc: add xen-domctx to present domain context
docs/specs: add missing definitions to
From: Paul Durrant
... and update xen-domctx to dump some information describing the record.
NOTE: Whilst the record definition is x86 specific, it is visible directly
in the common header as context record numbers should be unique across
all architectures.
Signed-off-by: Paul
These domctls provide a mechanism to get and set domain context from
the toolstack.
Signed-off-by: Paul Durrant
Reviewed-by: Julien Grall
---
Cc: Daniel De Graaf
Cc: Ian Jackson
Cc: Wei Liu
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Jan Beulich
Cc: Stefano Stabellini
v4:
- Add missing
From: Paul Durrant
A new 'domain context' framework was recently introduced to facilitate
transfer of state for both PV and HVM guests. Hence this patch mandates the
presence of a new DOMAIN_CONTEXT record in version 4 of the libxc migration
stream.
This record will incorprate the content of the
To allow enlightened HVM guests (i.e. those that have PV drivers) to be
migrated without their co-operation it will be necessary to transfer 'PV'
state such as event channel state, grant entry state, etc.
Currently there is a framework (entered via the hvm_save/load() functions)
that allows a
From: Paul Durrant
... and bump the version.
This patch implements version 4 of the migration stream by adding the code
necessary to save and restore DOMAIN_CONTEXT records, and removing the code
to save the SHARED_INFO and TSC_INFO records (as these are deprecated in
version 4).
From: Paul Durrant
The STATIC_DATA_END, X86_CPUID_POLICY and X86_MSR_POLICY record types have
sections explaining what they are but their values are not defined. Indeed
their values are defined as "Reserved for future mandatory records."
Also, the spec revision is adjusted to match the
This tool is analogous to 'xen-hvmctx' which presents HVM context.
Subsequent patches will add 'dump' functions when new records are
introduced.
Signed-off-by: Paul Durrant
Acked-by: Ian Jackson
---
Cc: Andrew Cooper
Cc: Wei Liu
NOTE: Ian requested ack from Andrew
v3:
- Re-worked to avoid
From: Paul Durrant
... and update xen-domctx to dump some information describing the record.
NOTE: Processing of the content during restore is currently limited to
PV domains, and matches processing of the PV-only SHARED_INFO record
done by libxc. All content is, however, saved such
On 24.09.20 14:03, Jan Beulich wrote:
Hi Jan
On 22.09.2020 18:46, Oleksandr wrote:
On 14.09.20 18:56, Jan Beulich wrote:
Hi Jan
On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
--- a/xen/include/xen/hypercall.h
+++ b/xen/include/xen/hypercall.h
@@ -150,6 +150,18 @@ do_dm_op(
Hi Julien,
> >>> Do you have Linux running on baremetal on this board? If so would
> >>> you mind to dump the DT from the userspace (via /proc/device-tree)
> >>> this time?
> >
> > I do have linux running on baremetal on the plattform.
> > You were right, after the boot, the memory node contains
On 23/09/2020 15:44, Christoph Hellwig wrote:
On Wed, Sep 23, 2020 at 02:58:43PM +0100, Tvrtko Ursulin wrote:
Series did not get a CI run from our side because of a different base so I
don't know if you would like to have a run there? If so you would need to
rebase against
Time to ask once again: do we want to drop Solaris support?
Reason for asking: since commit 38eeb3864de40 Xenstore isn't supported
on Solaris any longer, as Solaris has no support for mapping memory via
libxengnttab.
There has been no activity at all on the related Open-Solaris branch
since Xen
flight 154636 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154636/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 6 xen-install fail REGR. vs. 152332
> -Original Message-
> From: Jan Beulich
> Sent: 16 September 2020 15:43
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> Ian Jackson
> ; Wei Liu ; Andrew Cooper
> ; George
> Dunlap ; Julien Grall ; Stefano
> Stabellini
>
> Subject: RE: [EXTERNAL] [PATCH v8
On 22.09.2020 21:32, Oleksandr wrote:
> On 16.09.20 11:50, Jan Beulich wrote:
>> On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
>>> --- a/xen/common/memory.c
>>> +++ b/xen/common/memory.c
>>> @@ -1651,6 +1651,11 @@ long do_memory_op(unsigned long cmd,
>>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>>
On 9/16/20 8:34 PM, David Hildenbrand wrote:
> Page isolation doesn't actually touch the pages, it simply isolates
> pageblocks and moves all free pages to the MIGRATE_ISOLATE freelist.
>
> We already place pages to the tail of the freelists when undoing
> isolation via __putback_isolated_page(),
Hi,
On 23/09/2020 23:57, Stefano Stabellini wrote:
On Mon, 21 Sep 2020, Julien Grall wrote:
On 21/09/2020 13:55, Durrant, Paul wrote:
(+ Xen-devel)
Sorry I forgot to CC xen-devel.
On 21/09/2020 12:38, Julien Grall wrote:
Hi all,
I have started to look at the deferral code (see
On 23.09.2020 22:16, Oleksandr wrote:
> On 23.09.20 21:03, Julien Grall wrote:
>> On 10/09/2020 21:22, Oleksandr Tyshchenko wrote:
>>> From: Oleksandr Tyshchenko
>>> @@ -91,6 +108,28 @@ struct arch_domain
>>> #endif
>>> } __cacheline_aligned;
>>> +enum hvm_io_completion {
>>> +
> -Original Message-
> From: Andrew Cooper
> Sent: 24 September 2020 11:58
> To: p...@xen.org; 'Xen-devel'
> Cc: 'George Dunlap' ; 'Ian Jackson'
> ; 'Jan Beulich'
> ; 'Stefano Stabellini' ; 'Wei Liu'
> ; 'Julien
> Grall' ; 'Michał Leszczyński' ;
> 'Hubert Jasudowicz'
> ; 'Tamas K
On 22.09.2020 18:46, Oleksandr wrote:
>
> On 14.09.20 18:56, Jan Beulich wrote:
> Hi Jan
>
>> On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
>>> --- a/xen/include/xen/hypercall.h
>>> +++ b/xen/include/xen/hypercall.h
>>> @@ -150,6 +150,18 @@ do_dm_op(
>>> unsigned int nr_bufs,
>>>
On 23.09.2020 14:28, Oleksandr wrote:
> On 22.09.20 18:52, Jan Beulich wrote:
>> On 22.09.2020 17:05, Oleksandr wrote:
>>> 3. *arch.hvm.hvm_io*: We could also use the following:
>>>
>>> #define ioreq_get_io_completion(v) ((v)->arch.hvm.hvm_io.io_completion)
>>> #define
xmalloc() & Co may not be called with IRQs off, or else check_lock()
will have its assertion trigger about locks getting acquired
inconsistently. Re-arranging the locking in evtchn_send() doesn't seem
very reasonable, especially since the per-channel lock was introduced to
avoid acquiring the
> -Original Message-
> From: Andrew Cooper
> Sent: 22 September 2020 19:25
> To: Xen-devel
> Cc: Andrew Cooper ; George Dunlap
> ; Ian
> Jackson ; Jan Beulich ; Stefano
> Stabellini
> ; Wei Liu ; Julien Grall
> ; Paul Durrant
> ; Michał Leszczyński ; Hubert
> Jasudowicz
> ; Tamas K
On 9/16/20 8:34 PM, David Hildenbrand wrote:
> __putback_isolated_page() already documents that pages will be placed to
> the tail of the freelist - this is, however, not the case for
> "order >= MAX_ORDER - 2" (see buddy_merge_likely()) - which should be
> the case for all existing users.
I
> -Original Message-
> From: Andrew Cooper
> Sent: 22 September 2020 19:25
> To: Xen-devel
> Cc: Andrew Cooper ; George Dunlap
> ; Ian
> Jackson ; Jan Beulich ; Stefano
> Stabellini
> ; Wei Liu ; Julien Grall
> ; Paul Durrant
> ; Michał Leszczyński ; Hubert
> Jasudowicz
> ; Tamas K
On 9/16/20 8:34 PM, David Hildenbrand wrote:
> Let's prepare for additional flags and avoid long parameter lists of bools.
> Follow-up patches will also make use of the flags in __free_pages_ok(),
> however, I wasn't able to come up with a better name for the type - should
> be good enough for
On Wed, Sep 23, 2020 at 05:26:06PM +0200, David Hildenbrand wrote:
> >>> ???On 2020-09-16 20:34, David Hildenbrand wrote:
> When adding separate memory blocks via add_memory*() and onlining them
> immediately, the metadata (especially the memmap) of the next block will
> be
>
> -Original Message-
> From: Andrew Cooper
> Sent: 22 September 2020 19:25
> To: Xen-devel
> Cc: Andrew Cooper ; George Dunlap
> ; Ian
> Jackson ; Jan Beulich ; Stefano
> Stabellini
> ; Wei Liu ; Julien Grall
> ; Paul Durrant
> ; Michał Leszczyński ; Hubert
> Jasudowicz
> ; Tamas K
On Thu, Sep 24, 2020 at 11:50:44AM +0300, Dan Carpenter wrote:
> Hello Christoph Hellwig,
>
> The patch a0e7ac6b4907: "x86/xen: open code alloc_vm_area in
> arch_gnttab_valloc" from Sep 23, 2020, leads to the following static
> checker warning:
>
> arch/x86/xen/grant-table.c:110
> -Original Message-
> From: Andrew Cooper
> Sent: 22 September 2020 19:25
> To: Xen-devel
> Cc: Andrew Cooper ; George Dunlap
> ; Ian
> Jackson ; Jan Beulich ; Stefano
> Stabellini
> ; Wei Liu ; Julien Grall
> ; Paul Durrant
> ; Michał Leszczyński ; Hubert
> Jasudowicz
> ; Tamas K
Ping?
Patches 2-4 could need some Acks...
Juergen
On 09.09.20 13:46, Juergen Gross wrote:
The rest batch of the library build rework: the two remaining main
libraries libxenlight and libxlutil are moved to tools/libs/ directory.
Changes in V5:
- removed already applied patches (1-27)
-
> -Original Message-
> From: Andrew Cooper
> Sent: 22 September 2020 19:25
> To: Xen-devel
> Cc: Andrew Cooper ; George Dunlap
> ; Ian
> Jackson ; Jan Beulich ; Stefano
> Stabellini
> ; Wei Liu ; Julien Grall
> ; Paul Durrant
> ; Michał Leszczyński ; Hubert
> Jasudowicz
> ; Tamas K
On 24.09.20 11:40, Mel Gorman wrote:
> On Wed, Sep 23, 2020 at 05:26:06PM +0200, David Hildenbrand wrote:
> ???On 2020-09-16 20:34, David Hildenbrand wrote:
>> When adding separate memory blocks via add_memory*() and onlining them
>> immediately, the metadata (especially the memmap) of
> -Original Message-
> From: Andrew Cooper
> Sent: 22 September 2020 19:25
> To: Xen-devel
> Cc: Andrew Cooper ; George Dunlap
> ; Ian
> Jackson ; Jan Beulich ; Stefano
> Stabellini
> ; Wei Liu ; Julien Grall
> ; Paul Durrant
> ; Michał Leszczyński ; Hubert
> Jasudowicz
> ; Tamas K
flight 154634 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154634/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-4 68 xtf/test-hvm64-xsa-221 fail REGR. vs. 154611
Hello Christoph Hellwig,
The patch a0e7ac6b4907: "x86/xen: open code alloc_vm_area in
arch_gnttab_valloc" from Sep 23, 2020, leads to the following static
checker warning:
arch/x86/xen/grant-table.c:110 arch_gnttab_valloc()
warn: did you mean to pass the address of 'area->ptes'
On 22.09.2020 21:16, Andrew Cooper wrote:
> In addition, this removes the unqualified 0/1 passed to msi_data_reg()
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
On 22.09.2020 21:34, Andrew Cooper wrote:
> On 14/09/2020 11:18, Jan Beulich wrote:
>> Build this code into an archive, which results in not linking it into
>> x86 final binaries. This saves a little bit of dead code.
>>
>> Signed-off-by: Jan Beulich
>
> This wants to be an extern inline in the
1 - 100 of 102 matches
Mail list logo
