Hi,
> On 9 Dec 2020, at 01:19, Stefano Stabellini wrote:
>
> On Tue, 8 Dec 2020, Julien Grall wrote:
>> On 07/12/2020 18:42, Rahul Singh wrote:
On 7 Dec 2020, at 5:39 pm, Julien Grall wrote:
On 07/12/2020 12:12, Rahul Singh wrote:
>>> +typedef paddr_t dma_addr_t;
>>> +typedef
On 09.12.2020 02:34, Stefano Stabellini wrote:
> On Tue, 8 Dec 2020, Julien Grall wrote:
>> On 08/12/2020 14:38, Bertrand Marquis wrote:
>>> Hi Julien,
>>>
On 8 Dec 2020, at 09:47, Julien Grall wrote:
Hi,
On 08/12/2020 07:23, Michal Orzel wrote:
> When executing in
On 08.12.20 19:43, Borislav Petkov wrote:
On Fri, Nov 20, 2020 at 12:46:25PM +0100, Juergen Gross wrote:
diff --git a/arch/x86/include/asm/cpufeatures.h
b/arch/x86/include/asm/cpufeatures.h
index dad350d42ecf..ffa23c655412 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/a
flight 157339 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157339/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
flight 157330 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157330/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On 12/4/20 7:23 AM, Paul Menzel wrote:
> Dear Wim, dear Daniel,
>
>
> First, thank you for including all parties in the discussion.
> Am 04.12.20 um 13:52 schrieb Wim Vervoorn:
>
>> I agree with you. Using an existing standard is better than inventing
>> a new one in this case. I think using the
flight 157333 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157333/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf cee5b0441af39dd6f76cc4e0447a1c7f788cbb00
baseline version:
ovmf 8e4cb8fbceb84b66b3b2f
flight 157328 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157328/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail REGR. vs. 152631
test-amd64-amd64
On Tue, 8 Dec 2020, Julien Grall wrote:
> On 08/12/2020 14:38, Bertrand Marquis wrote:
> > Hi Julien,
> >
> > > On 8 Dec 2020, at 09:47, Julien Grall wrote:
> > >
> > > Hi,
> > >
> > > On 08/12/2020 07:23, Michal Orzel wrote:
> > > > When executing in aarch32 state at EL0, a load at EL0 from a
On Tue, 8 Dec 2020, Julien Grall wrote:
> On 07/12/2020 18:42, Rahul Singh wrote:
> > > On 7 Dec 2020, at 5:39 pm, Julien Grall wrote:
> > > On 07/12/2020 12:12, Rahul Singh wrote:
> > > > > > +typedef paddr_t dma_addr_t;
> > > > > > +typedef unsigned int gfp_t;
> > > > > > +
> > > > > > +#define
The pipeline failed because the "fedora-gcc-debug" build failed with a
timeout:
ERROR: Job failed: execution took longer than 1h0m0s seconds
given that all the other jobs passed (including the other Fedora job), I
take this failed because the gitlab-ci x86 runners were overloaded?
On Tue, 8 De
flight 157327 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157327/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 157271
test-amd64-amd64-xl-qemuu-win7-amd64
flight 157303 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157303/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 157153
Tests which did not succeed, b
On 08.12.20 21:43, Paul Durrant wrote:
Hi Paul
-Original Message-
From: Oleksandr
Sent: 08 December 2020 16:57
To: Paul Durrant
Cc: Jan Beulich ; Oleksandr Tyshchenko
; Stefano
Stabellini ; Julien Grall ; Volodymyr
Babchuk
; Andrew Cooper ; George
Dunlap
; Ian Jackson ; Wei Liu
flight 157323 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157323/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8e4cb8fbceb84b66b3b2fc45b9e93d70f732e970
baseline version:
ovmf 4b69fab6e20a98f56acd3
From: Paul Durrant
This patch largely re-writes the code to parse a PCI_SPEC_STRING and enters
it via the newly introduced function. The new parser also deals with 'bdf'
and 'vslot' as non-positional paramaters, as per the documentation in
xl-pci-configuration(5).
The existing xlu_pci_parse_bdf(
From: Paul Durrant
... and put it into a new xl-pci-configuration(5) manpage, akin to the
xl-network-configration(5) and xl-disk-configuration(5) manpages.
This patch moves the content of the section verbatim. A subsequent patch
will improve the documentation, once it is in its new location.
Si
From: Paul Durrant
The code currently checks explicitly whether the device is already assigned,
but this is actually unnecessary as assigned devices do not form part of
the list returned by libxl_device_pci_assignable_list() and hence the
libxl_pci_assignable() test would have already failed.
Si
From: Paul Durrant
... to be used by callers of libxl_device_pci_assignable_list().
Currently there is no API for callers of libxl_device_pci_assignable_list()
to free the list. The xl function pciassignable_list() calls
libxl_device_pci_dispose() on each element of the returned list, but
libxl_
From: Paul Durrant
A subsequent patch will introduce code to allow a name to be specified to
'xl pci-assignable-add' such that the assignable device may be referred to
by than name in subsequent operations.
Signed-off-by: Paul Durrant
Acked-by: Wei Liu
---
Cc: Ian Jackson
---
docs/man/xl.1.p
From: Paul Durrant
... and use in 'libxl_device_pci'
This patch is preparatory work for restricting the type passed to functions
that only require BDF information, rather than passing a 'libxl_device_pci'
structure which is only partially filled. In this patch only the minimal
mechanical changes
From: Paul Durrant
A previous patch introduced libxl_device_pci_list_free() which should be used
by callers of libxl_device_pci_list() to properly dispose of the exported
'libxl_device_pci' types and the free the memory holding them. Whilst all
current callers do ensure the memory is freed, only
From: Paul Durrant
This patch adds a 'name' field into the idl for 'libxl_device_pci' and
libxlu_pci_parse_spec_string() is modified to parse the new 'name'
parameter of PCI_SPEC_STRING detailed in the updated documention in
xl-pci-configuration(5).
If the 'name' field is non-NULL then both libx
From: Paul Durrant
... rather than an open-coded equivalent.
This patch tidies up the is_pci_in_array() function, making it take a single
'libxl_device_pci' argument rather than separate domain, bus, device and
function arguments. The already-available COMPARE_PCI() macro can then be
used and it
From: Paul Durrant
which support naming and use 'libxl_pci_bdf' rather than 'libxl_device_pci',
as replacements for libxl_device_pci_assignable_add/remove/list/list_free().
libxl_pci_bdf_assignable_add() takes a 'name' parameter which is stored in
xenstore and facilitates two addtional functions
From: Paul Durrant
... to use 'libx_pci_bdf' where appropriate.
No API change.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
Cc: Anthony PERARD
v6:
- New in v6 (split out from "libxl: modify libxl_device_pci_assignable_add/
remove/list/list_free()..."
---
tools/libs/ligh
From: Paul Durrant
Use of this function is a very inefficient way to check whether a device
has already been assigned.
This patch adds code that saves the domain id in xenstore at the point of
assignment, and removes it again when the device id de-assigned (or the
domain is destroyed). It is the
From: Paul Durrant
Since assignable devices can be named, a subsequent patch will support use
of a PCI_SPEC_STRING containing a 'name' parameter instead of a 'bdf'. In
this case the name will be used to look up the 'bdf' in the list of assignable
(or assigned) devices.
Signed-off-by: Paul Durran
From: Paul Durrant
This patch converts libxl to use libxl_pci_bdf_assignable_add/remove/list/
list_free() rather than libxl_device_pci_assignable_add/remove/list/
list_free(), which then allows naming of assignable devices to be supported.
With this patch applied 'xl pci-assignable-add' will tak
From: Paul Durrant
Currently the documentation completely fails to mention the existence of
PCI_SPEC_STRING. This patch tidies things up, specifically clarifying that
'pci-assignable-add/remove' take arguments where as 'pci-attach/detach'
take arguments (which will be enforced in a subsequent
p
From: Paul Durrant
... and prepare for adding support for non-positional parsing of 'bdf' and
'vslot' in a subsequent patch.
Also document 'BDF' as a first-class parameter type and fix the documentation
to state that the default value of 'rdm_policy' is actually 'strict', not
'relaxed', as can b
> -Original Message-
> From: Oleksandr
> Sent: 08 December 2020 16:57
> To: Paul Durrant
> Cc: Jan Beulich ; Oleksandr Tyshchenko
> ; Stefano
> Stabellini ; Julien Grall ; Volodymyr
> Babchuk
> ; Andrew Cooper ;
> George Dunlap
> ; Ian Jackson ; Wei Liu
> ; Julien Grall
> ; xen-devel@
From: Paul Durrant
... to hold a pointer to the device.
There is already a 'pci' field in 'pci_add_state' so simply use that from
the start. This also allows the 'pci' (#3) argument to be dropped from
do_pci_add().
NOTE: This patch also changes the type of the 'pci_domid' field in
'pci_ad
From: Paul Durrant
Simply spelling correction. Purely cosmetic fix.
Signed-off-by: Paul Durrant
Reviewed-by: Oleksandr Andrushchenko
Acked-by: Wei Liu
---
Cc: Ian Jackson
---
tools/libs/light/libxl_pci.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --
From: Paul Durrant
Other parameters, such as 'msitranslate' and 'permissive' are dealt with
but 'rdm_policy' appears to be have been completely missed.
Signed-off-by: Paul Durrant
Reviewed-by: Oleksandr Andrushchenko
Acked-by: Wei Liu
---
Cc: Ian Jackson
---
tools/libs/light/libxl_pci.c | 9
From: Paul Durrant
Currently libxl__device_pci_add_xenstore() is broken in that does not
update the domain's configuration for the first device added (which causes
creation of the overall backend area in xenstore). This can be easily observed
by running 'xl list -l' after adding a single device:
From: Paul Durrant
The seemingly arbitrary use of 'pci' and 'pcidev' in the code in libxl_pci.c
is confusing and also compromises use of some macros used for other device
types. Indeed it seems that DEFINE_DEVICE_TYPE_STRUCT_X exists solely because
of this duality.
This patch purges use of 'pcid
From: Paul Durrant
For the purposes of re-binding a device to its previous driver
libxl__device_pci_assignable_add() writes the driver path into xenstore.
This path is then read back in libxl__device_pci_assignable_remove().
The functions that support this writing to and reading from xenstore ar
From: Paul Durrant
Both 'domid' and 'pci' are available in 'pci_remove_state' so there is no
need to also pass them as separate arguments.
Signed-off-by: Paul Durrant
Reviewed-by: Oleksandr Andrushchenko
Acked-by: Wei Liu
---
Cc: Ian Jackson
---
tools/libs/light/libxl_pci.c | 9 -
1
From: Paul Durrant
... devices.
Currently there is an assumption built into libxl__device_list() that device
backends are fully enumarated under the '/libxl' path in xenstore. This is
not the case for PCI backend devices, which are only properly enumerated
under '/local/domain/0/backend'.
This
From: Paul Durrant
Paul Durrant (25):
libxl: s/pcidev/pci and remove DEFINE_DEVICE_TYPE_STRUCT_X
xl: s/pcidev/pci where possible
libxl: make libxl__device_list() work correctly for
LIBXL__DEVICE_KIND_PCI...
libxl: Make sure devices added by pci-attach are reflected in the
config
From: Paul Durrant
To improve naming consistency, replaces occurrences of 'pcidev' with 'pci'.
The only remaining use of the term should be in relation to
'libxl_domain_config' where there are fields named 'pcidevs' and 'num_pcidevs'.
Purely cosmetic. No functional change.
Signed-off-by: Paul D
On 07/12/2020 18:42, Rahul Singh wrote:
Hello Julien,
Hi,
On 7 Dec 2020, at 5:39 pm, Julien Grall wrote:
On 07/12/2020 12:12, Rahul Singh wrote:
+typedef paddr_t dma_addr_t;
+typedef unsigned int gfp_t;
+
+#define platform_device device
+
+#define GFP_KERNEL 0
+
+/* Alias to Xen dev
On 08/12/2020 14:38, Bertrand Marquis wrote:
Hi Julien,
On 8 Dec 2020, at 09:47, Julien Grall wrote:
Hi,
On 08/12/2020 07:23, Michal Orzel wrote:
When executing in aarch32 state at EL0, a load at EL0 from a
virtual address that matches the bottom 32 bits of the virtual address
used by a
On Fri, Nov 20, 2020 at 12:46:25PM +0100, Juergen Gross wrote:
> diff --git a/arch/x86/include/asm/cpufeatures.h
> b/arch/x86/include/asm/cpufeatures.h
> index dad350d42ecf..ffa23c655412 100644
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -237,6 +237,9
On 08.12.20 09:52, Paul Durrant wrote:
Hi Paul, Jan
On 30.11.2020 11:31, Oleksandr Tyshchenko wrote:
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -142,8 +142,8 @@ void hvmemul_cancel(struct vcpu *v)
{
struct hvm_vcpu_io *vio = &v->arch.hvm.hvm_io;
-vio-
On 08/12/2020 17:57, Manuel Bouyer wrote:
> Hello,
> for the first time I tried to boot a xen kernel from devel with
> a NetBSD PV dom0. The kernel boots, but when the first userland prcess
> is launched, it seems to enter a loop involving search_pre_exception_table()
> (I see an endless stream fro
flight 157285 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157285/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-qem
Hello,
for the first time I tried to boot a xen kernel from devel with
a NetBSD PV dom0. The kernel boots, but when the first userland prcess
is launched, it seems to enter a loop involving search_pre_exception_table()
(I see an endless stream from the dprintk() at arch/x86/extable.c:202)
With xen
On 08.12.20 17:02, Jan Beulich wrote:
Hi Jan
On 08.12.2020 14:56, Oleksandr wrote:
On 08.12.20 11:21, Jan Beulich wrote:
Hi Jan
On 07.12.2020 20:43, Oleksandr wrote:
On 07.12.20 13:41, Jan Beulich wrote:
On 30.11.2020 11:31, Oleksandr Tyshchenko wrote:
@@ -38,42 +37,6 @@ int arch_ioreq
Hi Paul.
On 08.12.20 17:33, Oleksandr wrote:
On 08.12.20 17:11, Jan Beulich wrote:
Hi Jan
On 30.11.2020 11:31, Oleksandr Tyshchenko wrote:
--- a/xen/include/xen/ioreq.h
+++ b/xen/include/xen/ioreq.h
@@ -55,6 +55,20 @@ struct ioreq_server {
uint8_t bufioreq_handling;
On 08.12.20 17:24, Jan Beulich wrote:
Hi Jan
On 30.11.2020 11:31, Oleksandr Tyshchenko wrote:
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -552,6 +552,8 @@ struct domain
struct ioreq_server *server[MAX_NR_IOREQ_SERVERS];
unsigned intnr_se
On 08.12.20 16:24, Jan Beulich wrote:
Hi Jan
On 30.11.2020 11:31, Oleksandr Tyshchenko wrote:
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1134,12 +1134,8 @@ static int acquire_resource(
xen_pfn_t mfn_list[32];
int rc;
-/*
- * FIXME: Until foreign pages ins
On 08.12.20 17:11, Jan Beulich wrote:
Hi Jan
On 30.11.2020 11:31, Oleksandr Tyshchenko wrote:
--- a/xen/include/xen/ioreq.h
+++ b/xen/include/xen/ioreq.h
@@ -55,6 +55,20 @@ struct ioreq_server {
uint8_tbufioreq_handling;
};
+/*
+ * This should only be used when d
On 30.11.2020 11:31, Oleksandr Tyshchenko wrote:
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -552,6 +552,8 @@ struct domain
> struct ioreq_server *server[MAX_NR_IOREQ_SERVERS];
> unsigned intnr_servers;
> } ioreq_server;
> +
> +boo
flight 157268 qemu-mainline real [real]
flight 157320 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157268/
http://logs.test-lab.xenproject.org/osstest/logs/157320/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On 30.11.2020 11:31, Oleksandr Tyshchenko wrote:
> --- a/xen/include/xen/ioreq.h
> +++ b/xen/include/xen/ioreq.h
> @@ -55,6 +55,20 @@ struct ioreq_server {
> uint8_tbufioreq_handling;
> };
>
> +/*
> + * This should only be used when d == current->domain and it's not paused,
flight 157271 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157271/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 157249
test-amd64-amd64-xl-qemuu-win7-amd64
On 08.12.2020 14:56, Oleksandr wrote:
>
> On 08.12.20 11:21, Jan Beulich wrote:
>
> Hi Jan
>
>> On 07.12.2020 20:43, Oleksandr wrote:
>>> On 07.12.20 13:41, Jan Beulich wrote:
On 30.11.2020 11:31, Oleksandr Tyshchenko wrote:
> @@ -38,42 +37,6 @@ int arch_ioreq_server_get_type_addr(const
On 08.12.2020 15:33, Andrew Cooper wrote:
> On 08/12/2020 13:51, Juergen Gross wrote:
>> With CONFIG_PV_SHIM_EXCLUSIVE some sources required for CONFIG_HVM are
>> not built, so let CONFIG_HVM depend on !CONFIG_PV_SHIM_EXCLUSIVE.
>>
>> Let CONFIG_HVM default to !CONFIG_PV_SHIM instead.
>>
>> Signed-
On 08.12.20 11:30, Jan Beulich wrote:
Hi Jan
On 07.12.2020 21:23, Oleksandr wrote:
On 07.12.20 14:08, Jan Beulich wrote:
On 30.11.2020 11:31, Oleksandr Tyshchenko wrote:
From: Julien Grall
As a lot of x86 code can be re-used on Arm later on, this patch
splits devicemodel support into com
On 08.12.20 15:33, Andrew Cooper wrote:
On 08/12/2020 13:51, Juergen Gross wrote:
With CONFIG_PV_SHIM_EXCLUSIVE some sources required for CONFIG_HVM are
not built, so let CONFIG_HVM depend on !CONFIG_PV_SHIM_EXCLUSIVE.
Let CONFIG_HVM default to !CONFIG_PV_SHIM instead.
Signed-off-by: Juergen G
Hi Julien,
> On 8 Dec 2020, at 09:47, Julien Grall wrote:
>
> Hi,
>
> On 08/12/2020 07:23, Michal Orzel wrote:
>> When executing in aarch32 state at EL0, a load at EL0 from a
>> virtual address that matches the bottom 32 bits of the virtual address
>> used by a recent load at (aarch64) EL1 migh
On 08/12/2020 13:51, Juergen Gross wrote:
> With CONFIG_PV_SHIM_EXCLUSIVE some sources required for CONFIG_HVM are
> not built, so let CONFIG_HVM depend on !CONFIG_PV_SHIM_EXCLUSIVE.
>
> Let CONFIG_HVM default to !CONFIG_PV_SHIM instead.
>
> Signed-off-by: Juergen Gross
So while this will fix the
On 08.12.2020 14:51, Juergen Gross wrote:
> With CONFIG_PV_SHIM_EXCLUSIVE some sources required for CONFIG_HVM are
> not built, so let CONFIG_HVM depend on !CONFIG_PV_SHIM_EXCLUSIVE.
>
> Let CONFIG_HVM default to !CONFIG_PV_SHIM instead.
>
> Signed-off-by: Juergen Gross
> ---
> xen/arch/x86/Kco
On 30.11.2020 11:31, Oleksandr Tyshchenko wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -1134,12 +1134,8 @@ static int acquire_resource(
> xen_pfn_t mfn_list[32];
> int rc;
>
> -/*
> - * FIXME: Until foreign pages inserted into the P2M are properly
> -
On 08.12.20 11:21, Jan Beulich wrote:
Hi Jan
On 07.12.2020 20:43, Oleksandr wrote:
On 07.12.20 13:41, Jan Beulich wrote:
On 30.11.2020 11:31, Oleksandr Tyshchenko wrote:
@@ -38,42 +37,6 @@ int arch_ioreq_server_get_type_addr(const struct domain *d,
ui
With CONFIG_PV_SHIM_EXCLUSIVE some sources required for CONFIG_HVM are
not built, so let CONFIG_HVM depend on !CONFIG_PV_SHIM_EXCLUSIVE.
Let CONFIG_HVM default to !CONFIG_PV_SHIM instead.
Signed-off-by: Juergen Gross
---
xen/arch/x86/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(
flight 157274 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157274/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
On Tue, 2020-12-08 at 11:53 +0100, Jan Beulich wrote:
> On 08.12.2020 11:22, Fam Zheng wrote:
> > On 2020-12-08 10:12, Jan Beulich wrote:
> > > On 08.12.2020 10:07, Julien Grall wrote:
> > > > On 08/12/2020 05:21, Penny Zheng wrote:
> > > > > --- /dev/null
> > > > > +++ b/docs/designs/1_1_direct-ma
On 08.12.2020 11:22, Fam Zheng wrote:
> On 2020-12-08 10:12, Jan Beulich wrote:
>> On 08.12.2020 10:07, Julien Grall wrote:
>>> On 08/12/2020 05:21, Penny Zheng wrote:
--- /dev/null
+++ b/docs/designs/1_1_direct-map.md
@@ -0,0 +1,87 @@
+# Preface
+
+The document is an
On Tue, Dec 08, 2020 at 11:30:26AM +0100, Juergen Gross wrote:
> I have been the major contributor for C Xenstore the past few years.
>
> Add me as a maintainer for tools/xenstore/.
>
> Signed-off-by: Juergen Gross
Acked-by: Wei Liu
Thanks for stepping up.
> ---
> MAINTAINERS | 7 +++
>
I have been the major contributor for C Xenstore the past few years.
Add me as a maintainer for tools/xenstore/.
Signed-off-by: Juergen Gross
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index dab38a6a14..6dbd99aff4 100644
--- a/MAINTAINER
On 2020-12-08 13:21, Penny Zheng wrote:
> +The document is an early draft for direct-map memory map
> +(`guest physical == physical`) of domUs. And right now, it constrains to ARM
> +architecture.
I'm also working on direct-map DomU on x86, so let's coordinate and
cover both arches.
> +
> +It aim
On 2020-12-08 10:12, Jan Beulich wrote:
> On 08.12.2020 10:07, Julien Grall wrote:
> > On 08/12/2020 05:21, Penny Zheng wrote:
> >> --- /dev/null
> >> +++ b/docs/designs/1_1_direct-map.md
> >> @@ -0,0 +1,87 @@
> >> +# Preface
> >> +
> >> +The document is an early draft for direct-map memory map
> >
flight 157293 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157293/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Hi,
On 08/12/2020 07:23, Michal Orzel wrote:
When executing in aarch32 state at EL0, a load at EL0 from a
virtual address that matches the bottom 32 bits of the virtual address
used by a recent load at (aarch64) EL1 might return incorrect data.
The workaround is to insert a write of the context
On 08.12.2020 08:52, Paul Durrant wrote:
>> From: Oleksandr
>> Sent: 07 December 2020 21:00
>>
>> On 07.12.20 14:32, Jan Beulich wrote:
>>> On 30.11.2020 11:31, Oleksandr Tyshchenko wrote:
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -145,6 +145,21 @@ void evtchn_d
On 07.12.2020 21:23, Oleksandr wrote:
> On 07.12.20 14:08, Jan Beulich wrote:
>> On 30.11.2020 11:31, Oleksandr Tyshchenko wrote:
>>> From: Julien Grall
>>>
>>> As a lot of x86 code can be re-used on Arm later on, this patch
>>> splits devicemodel support into common and arch specific parts.
>>>
>
On 07.12.2020 20:43, Oleksandr wrote:
> On 07.12.20 13:41, Jan Beulich wrote:
>> On 30.11.2020 11:31, Oleksandr Tyshchenko wrote:
>>> @@ -38,42 +37,6 @@ int arch_ioreq_server_get_type_addr(const struct domain
>>> *d,
>>> uint64_t *addr);
>>> void arch_ioreq_
On 08.12.2020 10:07, Julien Grall wrote:
> On 08/12/2020 05:21, Penny Zheng wrote:
>> --- /dev/null
>> +++ b/docs/designs/1_1_direct-map.md
>> @@ -0,0 +1,87 @@
>> +# Preface
>> +
>> +The document is an early draft for direct-map memory map
>> +(`guest physical == physical`) of domUs. And right now,
Hi Penny,
I am adding Paul and Zheng in the thread as there are similar interest
for the x86 side.
On 08/12/2020 05:21, Penny Zheng wrote:
This is one draft design about the infrastructure for now, not ready
for upstream yet (hence the RFC tag), thought it'd be useful to firstly
start a discu
Hi,
> On 8 Dec 2020, at 07:23, Michal Orzel wrote:
>
> When executing in aarch32 state at EL0, a load at EL0 from a
> virtual address that matches the bottom 32 bits of the virtual address
> used by a recent load at (aarch64) EL1 might return incorrect data.
>
> The workaround is to insert a wr
83 matches
Mail list logo
