09.01.2022 02:35, Michał Mirosław пишет:
> On Mon, Dec 13, 2021 at 12:02:52AM +0300, Dmitry Osipenko wrote:
> [...]
>> +/**
>> + * struct power_off_data - Power-off callback argument
>> + *
>> + * @cb_data: Callback data.
>> + */
>> +struct power_off_data {
>> +void *cb_data;
>> +};
>> +
>> +/*
On 10.01.2022 18:04, Jan Beulich wrote:
> On 10.01.2022 16:43, Andrew Cooper wrote:
>> On 10/01/2022 13:11, Jan Beulich wrote:
>>> On 10.01.2022 13:37, Roger Pau Monné wrote:
On Fri, Jan 07, 2022 at 12:39:04PM +0100, Jan Beulich wrote:
> @@ -415,16 +416,35 @@ static int64_t __init init_hpe
On 11.01.2022 00:08, Stefano Stabellini wrote:
> On Mon, 10 Jan 2022, Jan Beulich wrote:
>> On 08.01.2022 01:49, Stefano Stabellini wrote:
>>> Introduce a new feature flag to signal that xenstore will not be
>>> immediately available at boot time. Instead, xenstore will become
>>> available later,
On 11.01.2022 06:32, Juergen Gross wrote:
> On 10.01.22 18:04, Jan Beulich wrote:
>> On 10.01.2022 16:43, Andrew Cooper wrote:
>>> On 10/01/2022 13:11, Jan Beulich wrote:
On 10.01.2022 13:37, Roger Pau Monné wrote:
> On Fri, Jan 07, 2022 at 12:39:04PM +0100, Jan Beulich wrote:
>> @@ -4
On 10.01.22 19:56, Andrew Cooper wrote:
On 07/01/2022 10:35, Juergen Gross wrote:
@@ -54,8 +70,11 @@ int osdep_gnttab_close(xengnttab_handle *xgt)
void minios_gnttab_close_fd(int fd)
{
-gntmap_fini(&files[fd].gntmap);
-files[fd].type = FTYPE_NONE;
+struct file *file = get_fil
On 10.01.22 19:51, Andrew Cooper wrote:
On 10/01/2022 12:49, Juergen Gross wrote:
On 10.01.22 13:25, Andrew Cooper wrote:
On 07/01/2022 10:35, Juergen Gross wrote:
@@ -75,12 +86,25 @@ static void port_dealloc(struct evtchn_port_info
*port_info)
*/
int osdep_evtchn_open(xenevtchn_handle
On 10.01.22 18:04, Jan Beulich wrote:
On 10.01.2022 16:43, Andrew Cooper wrote:
On 10/01/2022 13:11, Jan Beulich wrote:
On 10.01.2022 13:37, Roger Pau Monné wrote:
On Fri, Jan 07, 2022 at 12:39:04PM +0100, Jan Beulich wrote:
@@ -415,16 +416,35 @@ static int64_t __init init_hpet(struct p
flight 167653 linux-linus real [real]
flight 167655 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167653/
http://logs.test-lab.xenproject.org/osstest/logs/167655/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-
Hi Stefano,
Stefano Stabellini writes:
> From: Stefano Stabellini
>
> Introduce a new "xen,enhanced" dom0less property to enable/disable PV
> driver interfaces for dom0less guests. Currently only "enabled" and
> "disabled" are supported property values (and empty). Leave the option
> open to
flight 167652 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167652/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail REGR. vs. 167643
Tests which did not succee
On Mon, 10 Jan 2022, Jan Beulich wrote:
> On 08.01.2022 01:49, Stefano Stabellini wrote:
> > Introduce a new feature flag to signal that xenstore will not be
> > immediately available at boot time. Instead, xenstore will become
> > available later, and a notification of xenstore readiness will be
>
On Sat, 8 Jan 2022, Julien Grall wrote:
> On 08/01/2022 00:49, Stefano Stabellini wrote:
> > From: Luca Miccio
> >
> > Add an example application that can be run in dom0 to complete the
> > dom0less domains initialization so that they can get access to xenstore
> > and use PV drivers.
> >
> > Si
On Sat, 8 Jan 2022, Julien Grall wrote:
> On 08/01/2022 00:49, Stefano Stabellini wrote:
> > From: Luca Miccio
> >
> > Introduce a new feature flag to signal that xenstore will not be
> > immediately available at boot time. Instead, xenstore will become
> > available later, and a notification of
On Sat, 8 Jan 2022, Julien Grall wrote:
> Hi Stefano,
>
> On 08/01/2022 00:49, Stefano Stabellini wrote:
> > From: Luca Miccio
> >
> > If the function is called with late_init set then also notify the domain
> > using the xenstore event channel.
> >
> > Signed-off-by: Luca Miccio
> > Signed-of
Hi everyone,
Happy New Year! I hope you all enjoyed a lovely holiday.
Our next meeting is tomorrow, January 11th at 4pm UTC.
The proposed agenda is in
https://cryptpad.fr/pad/#/2/pad/edit/xoyB4pnwFfULo6K+O7mi0c10/ Please add
or edit any items to this agenda. Alternatively, please feel free to em
On 07/01/2022 10:35, Juergen Gross wrote:
> @@ -54,8 +70,11 @@ int osdep_gnttab_close(xengnttab_handle *xgt)
>
> void minios_gnttab_close_fd(int fd)
> {
> -gntmap_fini(&files[fd].gntmap);
> -files[fd].type = FTYPE_NONE;
> +struct file *file = get_file_from_fd(fd);
> +
> +gntmap_
On 10/01/2022 12:49, Juergen Gross wrote:
> On 10.01.22 13:25, Andrew Cooper wrote:
>> On 07/01/2022 10:35, Juergen Gross wrote:
>>> @@ -75,12 +86,25 @@ static void port_dealloc(struct evtchn_port_info
>>> *port_info)
>>> */
>>> int osdep_evtchn_open(xenevtchn_handle *xce, unsigned int flags)
The MSI entries for multi-MSI are populated en bloc for the MSI descriptor,
but the current code invokes the population inside the per interrupt loop
which triggers a warning in the sysfs code and causes the interrupt
allocation to fail.
Move it outside of the loop so it works correctly for single
On 10.01.2022 16:43, Andrew Cooper wrote:
> On 10/01/2022 13:11, Jan Beulich wrote:
>> On 10.01.2022 13:37, Roger Pau Monné wrote:
>>> On Fri, Jan 07, 2022 at 12:39:04PM +0100, Jan Beulich wrote:
@@ -415,16 +416,35 @@ static int64_t __init init_hpet(struct p
pts->frequency = h
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -283,6 +283,8 @@ static int iommu_pde_from_dfn(struct dom
level, PTE_kind_table);
*flush_flags |= IOMMU_FLUSH
When a page table ends up with all contiguous entries (including all
identical attributes), it can be replaced by a superpage entry at the
next higher level. The page table itself can then be scheduled for
freeing.
The adjustment to LEVEL_MASK is merely to avoid leaving a latent trap
for whenever
When a page table ends up with all contiguous entries (including all
identical attributes), it can be replaced by a superpage entry at the
next higher level. The page table itself can then be scheduled for
freeing.
Signed-off-by: Jan Beulich
---
Unlike the freeing of all-empty page tables, this c
When a page table ends up with no present entries left, it can be
replaced by a non-present entry at the next higher level. The page table
itself can then be scheduled for freeing.
Note that while its output isn't used there yet,
pt_update_contig_markers() right away needs to be called in all plac
When a page table ends up with no present entries left, it can be
replaced by a non-present entry at the next higher level. The page table
itself can then be scheduled for freeing.
Note that while its output isn't used there yet,
pt_update_contig_markers() right away needs to be called in all plac
This is a re-usable helper (kind of a template) which gets introduced
without users so that the individual subsequent patches introducing such
users can get committed independently of one another.
See the comment at the top of the new file. To demonstrate the effect,
if a page table had just 16 en
Page tables are used for two purposes after allocation: They either
start out all empty, or they get filled to replace a superpage.
Subsequently, to replace all empty or fully contiguous page tables,
contiguous sub-regions will be recorded within individual page tables.
Install the initial set of m
Having a separate flush-all hook has always been puzzling me some. We
will want to be able to force a full flush via accumulated flush flags
from the map/unmap functions. Introduce a respective new flag and fold
all flush handling to use the single remaining hook.
Note that because of the respecti
... depending on feature availability (and absence of quirks).
Also make the page table dumping function aware of superpages.
Signed-off-by: Jan Beulich
---
v3: Rename queue_free_pt()'s last parameter. Replace "level > 1" checks
where possible. Tighten assertion.
--- a/xen/drivers/passthrou
No separate feature flags exist which would control availability of
these; the only restriction is HATS (establishing the maximum number of
page table levels in general), and even that has a lower bound of 4.
Thus we can unconditionally announce 2M, 1G, and 512G mappings. (Via
non-default page size
In order to free intermediate page tables when replacing smaller
mappings by a single larger one callers will need to know the full PTE.
Flush indicators can be derived from this in the callers (and outside
the locked regions). First split set_iommu_pte_present() from
set_iommu_ptes_present(): Only
This is to aid diagnosing issues and largely matches VT-d's behavior.
Since I'm adding permissions output here as well, take the opportunity
and also add their displaying to amd_dump_page_table_level().
Signed-off-by: Jan Beulich
---
Note: "largely matches VT-d's behavior" includes the lack of an
I think this flush was overlooked when flushing was moved out of the
core (un)mapping functions. The flush the caller is required to invoke
anyway will satisfy the needs resulting from the splitting of a
superpage.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
--- a/xen/drivers/passth
For vendor specific code to support superpages we need to be able to
deal with a superpage mapping replacing an intermediate page table (or
hierarchy thereof). Consequently an iommu_alloc_pgtable() counterpart is
needed to free individual page tables while a domain is still alive.
Since the freeing
For large page mappings to be easily usable (i.e. in particular without
un-shattering of smaller page mappings) and for mapping operations to
then also be more efficient, pass batches of Dom0 memory to iommu_map().
In dom0_construct_pv() and its helpers (covering strict mode) this
additionally requ
While already the case for PVH, there's no reason to treat PV
differently here, though of course the addresses get taken from another
source in this case. Except that, to match CPU side mappings, by default
we permit r/o ones. This then also means we now deal consistently with
IO-APICs whose MMIO i
Introduce a helper function to determine the largest possible mapping
that allows covering a request (or the next part of it that is left to
be processed).
In order to not add yet more recurring dfn_add() / mfn_add() to the two
callers of the new helper, also introduce local variables holding the
Or really, in the case of ->map_page(), accommodate it in the existing
"flags" parameter. All call sites will pass 0 for now.
Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
Reviewed-by: Roger Pau Monné
[Arm]
Acked-by: Julien Grall
---
v3: Re-base over new earlier patch.
v2: Re-base over ch
As of 68a8aa5d7264 ("iommu: make map and unmap take a page count,
similar to flush") there's no need anymore to have a loop here.
Suggested-by: Roger Pau Monné
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -285,11 +285,9 @
Generic code will use this information to determine what order values
can legitimately be passed to the ->{,un}map_page() hooks. For now all
ops structures simply get to announce 4k mappings (as base page size),
and there is (and always has been) an assumption that this matches the
CPU's MMU base p
I have to admit that I never understood why domain_pgd_maddr() wants to
populate all page table levels for DFN 0. I can only assume that despite
the comment there what is needed is population just down to the smallest
possible nr_pt_levels that the loop later in the function may need to
run to. Hen
In order to be able to insert/remove super-pages we need to allow
callers of the walking function to specify at which point to stop the
walk.
For intel_iommu_lookup_page() integrate the last level access into
the main walking function.
dma_pte_clear_one() gets only partly adjusted for now: Error
In order to be able to insert/remove super-pages we need to allow
callers of the walking function to specify at which point to stop the
walk. (For now at least gcc will instantiate just a variant of the
function with the parameter eliminated, so effectively no change to
generated code as far as the
For a long time we've been rather inefficient with IOMMU page table
management when not sharing page tables, i.e. in particular for PV (and
further specifically also for PV Dom0) and AMD (where nowadays we never
share page tables). While up to about 2.5 years ago AMD code had logic
to un-shatter pa
On 10/01/2022 13:11, Jan Beulich wrote:
> On 10.01.2022 13:37, Roger Pau Monné wrote:
>> On Fri, Jan 07, 2022 at 12:39:04PM +0100, Jan Beulich wrote:
>>> @@ -415,16 +416,35 @@ static int64_t __init init_hpet(struct p
>>>
>>> pts->frequency = hpet_rate;
>>>
>>> +for(i = 0; i < 16; ++i) {//t
On 10.01.2022 15:49, Roger Pau Monné wrote:
> On Mon, Jan 10, 2022 at 08:52:55AM +0100, Jan Beulich wrote:
>> On 07.01.2022 12:39, Jan Beulich wrote:
>>> --- a/xen/arch/x86/time.c
>>> +++ b/xen/arch/x86/time.c
>>> @@ -378,8 +378,9 @@ static u64 read_hpet_count(void)
>>>
>>> static int64_t __init
On Sat, Jan 08, 2022 at 01:14:26AM +0800, G.R. wrote:
> On Wed, Jan 5, 2022 at 10:33 PM Roger Pau Monné wrote:
> >
> > On Wed, Jan 05, 2022 at 12:05:39AM +0800, G.R. wrote:
> > > > > > > But seems like this patch is not stable enough yet and has its own
> > > > > > > issue -- memory is not properl
On Mon, Jan 10, 2022 at 08:52:55AM +0100, Jan Beulich wrote:
> On 07.01.2022 12:39, Jan Beulich wrote:
> > --- a/xen/arch/x86/time.c
> > +++ b/xen/arch/x86/time.c
> > @@ -378,8 +378,9 @@ static u64 read_hpet_count(void)
> >
> > static int64_t __init init_hpet(struct platform_timesource *pts)
> >
Hi Andre,
Many thanks for your inputs. It is making better sense now. Much
appreciated.
A few questions/clarifications :-
On 06/01/2022 15:33, Andre Przywara wrote:
On Wed, 5 Jan 2022 16:55:11 +
Ayan Kumar Halder wrote:
Hi,
Thank you so much for your feedback.
I need a couple of cla
On 10.01.2022 13:37, Roger Pau Monné wrote:
> On Fri, Jan 07, 2022 at 12:39:04PM +0100, Jan Beulich wrote:
>> x86: improve TSC / CPU freq calibration accuracy
>>
>> While the problem report was for extreme errors, even smaller ones would
>> better be avoided: The calculated period to run calibratio
On 10.01.22 13:36, Andrew Cooper wrote:
struct xenevtchn_handle is common in private.h, meaning that xenevtchn_fd()
has exactly one correct implementation.
Implement it in core.c, rather than identically for each OS. This matches all
other libraries (call, gnttab, gntshr) which implement an fd
On 10.01.22 13:25, Andrew Cooper wrote:
On 07/01/2022 10:35, Juergen Gross wrote:
diff --git a/tools/libs/evtchn/minios.c b/tools/libs/evtchn/minios.c
index e5dfdc5ef5..3305102f22 100644
--- a/tools/libs/evtchn/minios.c
+++ b/tools/libs/evtchn/minios.c
@@ -38,16 +38,27 @@
#include "private.
flight 167649 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167649/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-arm64-xl-vhd 12 debian-di-install fail in 167634 pass in 167649
test-amd64-amd64-xl-rtds 20 gues
On Fri, Jan 07, 2022 at 12:39:04PM +0100, Jan Beulich wrote:
> On 06.01.2022 16:08, James Dingwall wrote:
> >>> On Wed, Jul 21, 2021 at 12:59:11PM +0200, Jan Beulich wrote:
> >>>
> On 21.07.2021 11:29, James Dingwall
struct xenevtchn_handle is common in private.h, meaning that xenevtchn_fd()
has exactly one correct implementation.
Implement it in core.c, rather than identically for each OS. This matches all
other libraries (call, gnttab, gntshr) which implement an fd getter.
Signed-off-by: Andrew Cooper
---
On 07/01/2022 10:35, Juergen Gross wrote:
> diff --git a/tools/libs/evtchn/minios.c b/tools/libs/evtchn/minios.c
> index e5dfdc5ef5..3305102f22 100644
> --- a/tools/libs/evtchn/minios.c
> +++ b/tools/libs/evtchn/minios.c
> @@ -38,16 +38,27 @@
>
> #include "private.h"
>
> +LIST_HEAD(port_list,
Andrew Cooper, le lun. 10 janv. 2022 11:35:14 +, a ecrit:
> On 09/01/2022 01:16, Samuel Thibault wrote:
> > Juergen Gross, le ven. 07 janv. 2022 11:47:04 +0100, a ecrit:
> >> can only be applied after the Xen libraries have stopped using the
> >> related union members.
> > Ah, ok :) Was that su
On 09/01/2022 01:16, Samuel Thibault wrote:
> Juergen Gross, le ven. 07 janv. 2022 11:47:04 +0100, a ecrit:
>> can only be applied after the Xen libraries have stopped using the
>> related union members.
> Ah, ok :) Was that submitted somewhere?
https://lore.kernel.org/xen-devel/20220107103544.927
On 25.11.2021 14:39, Anthony PERARD wrote:
> This implement out-of-tree support, there's two ways to create an
> out-of-tree build tree (after that, `make` in that new directory
> works):
> make O=build
> mkdir build; cd build; make -f ../Makefile
> also works with an absolute path for both
On 21.12.2021 16:26, Jan Beulich wrote:
> On 25.11.2021 14:39, Anthony PERARD wrote:
>> Patch series available in this git branch:
>> https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
>> br.build-system-xen-v8
>>
>> v8:
>> Mostly rework of v7. With many patch already applied.
>>
On Thu, Jan 6, 2022 at 9:05 PM amir masoud noohi
wrote:
> It looks like you can get the info you want for credit2
>
>
> How?
>
We're happy to help point you in the right direction, but I'm afraid you
will have to actually do some work on your own. Did you google
"xentrace"? Did you try running
On 08.01.2022 01:49, Stefano Stabellini wrote:
> @@ -284,11 +285,32 @@ void evtchn_free(struct domain *d, struct evtchn *chn)
> xsm_evtchn_close_post(chn);
> }
>
> -static int evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
> +struct evtchn *_evtchn_alloc_unbound(struct domain *d, domid
flight 167650 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167650/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
flight 167651 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167651/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6062002bd5a394fef46243dd866860c3480d918e
baseline version:
ovmf 14a731096d388aa20c0af
On 08.01.2022 01:49, Stefano Stabellini wrote:
> Introduce a new feature flag to signal that xenstore will not be
> immediately available at boot time. Instead, xenstore will become
> available later, and a notification of xenstore readiness will be
> signalled to the guest using the xenstore event
(also Cc-ing Paul)
On 09.01.2022 19:04, Jason Andryuk wrote:
> commit 0fdb48ffe7a1 "libxl: Make sure devices added by pci-attach are
> reflected in the config" broken PCI hotplug (xl pci-attach) for PV
> domains when it moved libxl__create_pci_backend() later in the function.
>
> This also broke
On 10.01.22 09:42, Jan Beulich wrote:
On 09.01.2022 11:01, Juergen Gross wrote:
"make distclean" will complain that "-c" is no supported flag for make.
Fix that by using "-C".
The error has been present for a long time, but it was uncovered only
recently.
And that's because the rule simply w
On 09.01.2022 11:01, Juergen Gross wrote:
> "make distclean" will complain that "-c" is no supported flag for make.
>
> Fix that by using "-C".
>
> The error has been present for a long time, but it was uncovered only
> recently.
And that's because the rule simply was unreachable before? Or it w
flight 167648 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167648/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 167647
test-amd64-amd64-qemuu-nested-amd 20
On 07.01.2022 16:20, Anthony PERARD wrote:
> On Tue, Dec 14, 2021 at 02:52:43PM +0100, Jan Beulich wrote:
>> On 14.12.2021 14:34, Jason Andryuk wrote:
>>> On Tue, Dec 14, 2021 at 2:50 AM Jan Beulich wrote:
Attempting to wait when the backend hasn't been created yet can't work:
the f
69 matches
Mail list logo
