On 09.09.2021 21:31, Andrew Cooper wrote:
> On 09/09/2021 15:56, Jan Beulich wrote:
>> asm() constraints need to fit both the intended insn(s) which the
>> respective operands are going to be used with as well as the actual kind
>> of value specified. "m" (alone) together with a constant, however,
On 18.08.21 17:26, Juergen Gross wrote:
Today the implementation of the xenbus protocol in Mini-OS will only
allow to transfer the complete message to or from the ring page buffer.
This is limiting the maximum message size to lower values as the xenbus
protocol normally would allow.
Change that
On 10.09.2021 04:12, Daniel P. Smith wrote:
> @@ -70,7 +73,7 @@ void __xsm_action_mismatch_detected(void);
> #endif /* CONFIG_XSM */
>
> static always_inline int xsm_default_action(
> -xsm_default_t action, struct domain *src, struct domain *target)
> + xsm_default_t action, struct doma
On 10.09.2021 04:12, Daniel P. Smith wrote:
> In c/s fcb8baddf00e the xsm_memtype hook was removed but some remnants were
> left behind. This commit cleans up those remnants.
>
> Signed-off-by: Daniel P. Smith
Acked-by: Jan Beulich
On 10.09.2021 04:12, Daniel P. Smith wrote:
> From: Andrew Cooper
>
> The alternative call infrastructure is x86-only for now, but the common iommu
> code has a variant and more common code wants to use the infrastructure.
>
> Introduce CONFIG_ALTERNATIVE_CALL and a conditional implemetnation so
Using qemu-traditional as device model is deprecated for some time now.
So change the default for building it to "disable". This will affect
ioemu-stubdom, too, as there is a direct dependency between the two.
Today it is possible to use a PVH/HVM Linux-based stubdom as device
model. Additionally
The stubdom based pv-grub is using a very outdated version of grub
(0.97) and should not be used any longer. Mainline grub has support for
PV guests for a long time now, so that should be used as a boot loader
of a PV domain.
So disable building pv-grub per default. In case someone really wants
to
This is a first step of deprecating pv-grub and qemu-trad including
ioemu-stubdom. Switch the default to not building it.
Changes in V3:
- rename pv-grub32 make target
Changes in V2:
- new patch 3
- added CHANGELOG.md entry in patch 2
Juergen Gross (3):
stubdom: fix build with disabled pv-grub
Today the build will fail if --disable-pv-grub as a parameter of
configure, as the main Makefile will unconditionally try to build a
32-bit pv-grub stubdom.
Fix that by introducing a pv-grub-if-enabled target in
stubdom/Makefile taking care of this situation.
Signed-off-by: Juergen Gross
Reviewe
On 09.09.21 18:08, Ian Jackson wrote:
Juergen Gross writes ("Re: [PATCH v2 1/3] stubdom: fix build with disabled
pv-grub"):
On 09.09.21 15:23, Ian Jackson wrote:
How about "pv-grub-maybe" ? Or something.
What about "pv-grub-if-enabled"?
Fine by me.
And could that be done when committing
flight 164913 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164913/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d248516b3a190c5cb5d51164b5721ead9d24469a
baseline version:
ovmf a7cf2c5664b9605162b20
flight 164898 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164898/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 163761
test-amd64-i386-xl-qemuu-win7-am
The request_queue pointer returned from bdev_get_queue() shall
never be NULL, so the null check is unnecessary, just remove it.
Signed-off-by: Xu Wang
---
drivers/block/xen-blkback/xenbus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/xen-blkback/xenbus.c
b/
The request_queue pointer returned from bdev_get_queue() shall
never be NULL, so the null check is unnecessary, just remove it.
Signed-off-by: Xu Wang
---
Changes since v2:
- Add missing parenthesis.
- Remove another null pointer check.
---
drivers/block/xen-blkback/xenbus.c | 4 ++--
1 file cha
On 09.09.21 18:47, Ian Jackson wrote:
This makes radical changes to the test ste for the linux-linus and
linux-next branches.
Mostly, tests are dropped but some 64-bit dom0 tests are added to
replace them.
Requested-by: Juergen Gross
Signed-off-by: Ian Jackson
Thanks!
Reviewed-by: Juergen
Hi Christopher,
On Tue, Sep 07, 2021 at 11:09:34AM -0700, Christopher Clark wrote:
> On Tue, Sep 7, 2021 at 4:55 AM AKASHI Takahiro
> wrote:
>
> > Hi,
> >
> > I have not covered all your comments below yet.
> > So just one comment:
> >
> > On Mon, Sep 06, 2021 at 05:57:43PM -0700, Christopher Cl
This commit introduces a new function allocate_static_memory to allocate
static memory as guest RAM for domains on Static Allocation.
It uses acquire_domstatic_pages to acquire pre-configured static memory
for the domain, and uses guest_physmap_add_pages to set up the P2M table.
These pre-defined
In order to deal with the trouble of count-to-order conversion when page number
is not in a power-of-two, this commit re-define assign_pages for nr pages and
assign_page for original page with a single order.
Backporting confusion could be helped by altering the order of assign_pages
parameters, s
New function acquire_staticmem_pages aims to acquire nr_mfns contiguous pages
of static memory, starting at #smfn. And it is the equivalent of
alloc_heap_pages for static memory.
For each page, it shall check if the page is reserved(PGC_reserved)
and free. It shall also do a set of necessary initi
This patch introduces static memory initialization, during system boot-up.
The new function init_staticmem_pages is responsible for static memory
initialization.
Helper free_staticmem_pages is the equivalent of free_heap_pages, to free
nr_mfns pages of static memory.
This commit also introduces
This commit defines a new helper mark_page_free to extract common code,
like following the same cache/TLB coherency policy, between free_heap_pages
and the new function free_staticmem_pages, which will be introduced later.
The PDX compression makes that conversion between the MFN and the page can
Static Allocation refers to system or sub-system(domains) for which memory
areas are pre-defined by configuration using physical address ranges.
Those pre-defined memory, -- Static Memory, as parts of RAM reserved in the
beginning, shall never go to heap allocator or boot allocator for any use.
M
This commit creates a new helper device_tree_get_meminfo to iterate over a
device tree property to get memory info, like "reg".
Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
---
xen/arch/arm/bootfdt.c | 83 --
1 file changed, 47 insertions(+)
Static Allocation refers to system or sub-system(domains) for which memory
areas are pre-defined by configuration using physical address ranges.
Those pre-defined memory, -- Static Memory, as parts of RAM reserved in the
beginning, shall never go to heap allocator or boot allocator for any use.
M
On Mon, Sep 06, 2021 at 07:41:48PM -0700, Christopher Clark wrote:
> On Sun, Sep 5, 2021 at 7:24 PM AKASHI Takahiro via Stratos-dev <
> stratos-...@op-lists.linaro.org> wrote:
>
> > Alex,
> >
> > On Fri, Sep 03, 2021 at 10:28:06AM +0100, Alex Benn??e wrote:
> > >
> > > AKASHI Takahiro writes:
> >
On 2021/09/10 11:32, Xu Wang wrote:
> The request_queue pointer returned from bdev_get_queue() shall
> never be NULL, so the null check is unnecessary, just remove it.
>
> Signed-off-by: Xu Wang
> ---
> drivers/block/xen-blkback/xenbus.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
flight 164896 xen-4.12-testing real [real]
flight 164928 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164896/
http://logs.test-lab.xenproject.org/osstest/logs/164928/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
On Thu, 19 Aug 2021, Rahul Singh wrote:
> If the property is not present in the device tree node for host bridge,
> XEN while creating the dtb for hwdom will create this property and
> assigns the already allocated segment to the host bridge
> so that XEN and linux will have the same segment for th
On Thu, 19 Aug 2021, Rahul Singh wrote:
> libxl will create an emulated PCI device tree node in the device tree to
> enable the guest OS to discover the virtual PCI during guest boot.
> Emulated PCI device tree node will only be created when there is any
> device assigned to guest.
>
> A new area
On Thu, 19 Aug 2021, Rahul Singh wrote:
> The existing VPCI support available for X86 is adapted for Arm.
> When the device is added to XEN via the hyper call
> “PHYSDEVOP_pci_device_add”, VPCI handler for the config space
> access is added to the Xen to emulate the PCI devices config space.
This
From: Juergen Gross
[ Upstream commit 58e636039b512697554b579c2bb23774061877f5 ]
In cpu_bringup() there is a call of preempt_disable() without a paired
preempt_enable(). This is not needed as interrupts are off initially.
Additionally this will result in early boot messages like:
BUG: schedulin
From: Juergen Gross
[ Upstream commit 58e636039b512697554b579c2bb23774061877f5 ]
In cpu_bringup() there is a call of preempt_disable() without a paired
preempt_enable(). This is not needed as interrupts are off initially.
Additionally this will result in early boot messages like:
BUG: schedulin
From: Juergen Gross
[ Upstream commit 58e636039b512697554b579c2bb23774061877f5 ]
In cpu_bringup() there is a call of preempt_disable() without a paired
preempt_enable(). This is not needed as interrupts are off initially.
Additionally this will result in early boot messages like:
BUG: schedulin
From: Juergen Gross
[ Upstream commit 58e636039b512697554b579c2bb23774061877f5 ]
In cpu_bringup() there is a call of preempt_disable() without a paired
preempt_enable(). This is not needed as interrupts are off initially.
Additionally this will result in early boot messages like:
BUG: schedulin
From: Juergen Gross
[ Upstream commit 58e636039b512697554b579c2bb23774061877f5 ]
In cpu_bringup() there is a call of preempt_disable() without a paired
preempt_enable(). This is not needed as interrupts are off initially.
Additionally this will result in early boot messages like:
BUG: schedulin
From: Juergen Gross
[ Upstream commit 58e636039b512697554b579c2bb23774061877f5 ]
In cpu_bringup() there is a call of preempt_disable() without a paired
preempt_enable(). This is not needed as interrupts are off initially.
Additionally this will result in early boot messages like:
BUG: schedulin
On Thu, 19 Aug 2021, Rahul Singh wrote:
> Add cmdline boot option "pci=on" to enable/disable the PCI init during
> boot.
>
> Signed-off-by: Rahul Singh
> ---
> xen/arch/arm/pci/pci.c | 30 ++
> 1 file changed, 30 insertions(+)
>
> diff --git a/xen/arch/arm/pci/pci.c
On Fri, 20 Aug 2021, Jan Beulich wrote:
> On 20.08.2021 16:34, Julien Grall wrote:
> > On 20/08/2021 13:19, Rahul Singh wrote:
> >>> On 19 Aug 2021, at 1:31 pm, Julien Grall wrote:
> >>> On 19/08/2021 13:02, Rahul Singh wrote:
> Add cmdline boot option "pci=on" to enable/disable the PCI init
On Thu, 19 Aug 2021, Rahul Singh wrote:
> Implement generic pci access functions to read/write the configuration
> space.
>
> Signed-off-by: Rahul Singh
> ---
> xen/arch/arm/pci/pci-access.c | 31 +-
> xen/arch/arm/pci/pci-host-common.c | 19 ++
>
On Thu, 19 Aug 2021, Rahul Singh wrote:
> From: Oleksandr Andrushchenko
>
> Add support for Xilinx ZynqMP PCI host controller to map the PCI config
> space to the XEN memory.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> xen/arch/arm/pci/Makefile | 1 +
> xen/arch/arm/pci/pci-ho
On Thu, 19 Aug 2021, Rahul Singh wrote:
> Add support for PCI ecam operations to access the PCI
> configuration space.
>
> Signed-off-by: Rahul Singh
> ---
> xen/arch/arm/pci/Makefile | 1 +
> xen/arch/arm/pci/ecam.c | 63 +
> xen/arch/arm/pci/p
Hello all
On 07.09.21 20:09, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
You can find an initial discussion at [1].
The extended region (safe range) is a region of guest physical
address space which is unused and could be safely used to create
grant/foreign mappings instead of wa
From: Oleksandr Tyshchenko
Rework Arm implementation to store grant table frame GFN
in struct page_info directly instead of keeping it in
standalone status/shared arrays.
To cover 64-bit/40-bit IPA on Arm64/Arm32 we need the new
field to hold 52-bit/28-bit respectively. In order to not
grow the
Juergen Gross, le jeu. 09 sept. 2021 14:49:24 +0200, a ecrit:
> Using qemu-traditional as device model is deprecated for some time now.
>
> So change the default for building it to "disable". This will affect
> ioemu-stubdom, too, as there is a direct dependency between the two.
>
> Today it is p
On Thu, 19 Aug 2021, Rahul Singh wrote:
> XEN during boot will read the PCI device tree node “reg” property
> and will map the PCI config space to the XEN memory.
>
> As of now "pci-host-ecam-generic" compatible board is supported.
>
> "linux,pci-domain" device tree property assigns a fixed PCI d
Hidden behind macro magic is an alternative xsm hook interface dedicated for
use when the dummy/default policy is the only one built. This alternative
interface increases code complexity and code size in the core security
framework of Xen. This results in code requiring additional maintanence and
It has been a very long time since XSM Flask was the only XSM module, yet the
concenpt of turning XSM on/off continues to be synonymous with enabling and
disabling XSM Flask. Even when XSM Flask was the only module, turning XSM
on/off did not disable or remove the XSM hooks but simply controlled wh
Multiple preprocessor defines were used as a mechanism to selective include
parts of the xsm.h header file. This makes it difficult to know which portion
is being included at any one time. This commit works to simplify this by
separating the core structures and functions of XSM into xsm-core.h away
To reduce retpolines convert all the pointer function calls of the
xsm_ops hooks over to the alternative_call infrastructure.
Signed-off-by: Daniel P. Smith
Acked-by: Andrew Cooper
---
xen/include/xsm/xsm.h | 191 +-
1 file changed, 96 insertions(+), 95 d
This renames the `struct xsm_operations` to the shorter `struct xsm_ops` and
converts the global xsm_ops from being a pointer to an explicit instance. As
part of this conversion, it reworks the XSM modules init function to return
their xsm_ops struct which is copied in to the global xsm_ops instanc
Instead of intermixing coding style changes with code changes as they
are come upon in this patch set, moving all coding style changes
into a single commit. The focus of coding style changes here are,
- move trailing comments to line above
- ensuring line length does not exceed 80 chars
- ensur
The type xsm_op_t masks the use of void pointers. This commit drops the
xsm_op_t type and replaces it and all its uses with an explicit void.
Signed-off-by: Daniel P. Smith
Acked-by: Andrew Cooper
---
xen/include/xen/hypercall.h | 4 ++--
xen/include/xsm/dummy.h | 4 ++--
xen/include/xsm/
In c/s fcb8baddf00e the xsm_memtype hook was removed but some remnants were
left behind. This commit cleans up those remnants.
Signed-off-by: Daniel P. Smith
---
xen/include/xsm/xsm.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index ad3
On Linux when SELinux is put into permissive mode the descretionary access
controls are still in place. Whereas for Xen when the enforcing state of flask
is set to permissive, all operations for all domains would succeed, i.e. it
does not fall back to the default access controls. To provide a means
From: Andrew Cooper
The alternative call infrastructure is x86-only for now, but the common iommu
code has a variant and more common code wants to use the infrastructure.
Introduce CONFIG_ALTERNATIVE_CALL and a conditional implemetnation so common
code can use the optimisation when available, wi
Based on feedback from 2021 Xen Developers Summit the xsm-roles RFC patch set
is being split into two separate patch sets. This is the first patch set and is
focused purely on the clean up and refactoring of the XSM hooks.
This patch set refactors the xsm_ops wrapper hooks to use the alternative_c
flight 164892 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164892/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 164883
Tests which did not succeed
I am fine with adding this functionality only to device tree initially.
It is certainly true that if a DMA-capable device is behind an IOMMU,
then we can skip swiotlb-xen for foreign pages address transactions.
Those addresses will be translated just fine thanks to the IOMMU.
Skipping swiotlb-xen
On 09/09/2021 15:56, Jan Beulich wrote:
> asm() constraints need to fit both the intended insn(s) which the
> respective operands are going to be used with as well as the actual kind
> of value specified. "m" (alone) together with a constant, however, leads
> to gcc saying
>
> error: memory input
On 9/9/21 11:45 AM, Jan Beulich wrote:
> On 03.09.2021 21:06, Daniel P. Smith wrote:
>> SILO implements a few XSM hooks to extended the decision logic beyond
>> what is defined in the dummy/default policy. For each of the hooks, it
>> falls back to the dummy/default policy. The fall back is done a
On Thu, Sep 09, 2021 at 01:20:17AM +0200, Philippe Mathieu-Daudé wrote:
> Add the BlockDriver::bdrv_taints_security_policy() handler.
> Drivers implementing it might taint the global QEMU security
> policy.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> include/block/block_int.h | 6 +-
>
On Thu, Sep 09, 2021 at 01:20:16AM +0200, Philippe Mathieu-Daudé wrote:
> Add the AccelClass::secure_policy_supported field to classify
> safe (within security boundary) vs unsafe accelerators.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> include/qemu/accel.h | 5 +
> accel/kvm/kvm-all.
On Thu, Sep 09, 2021 at 01:20:15AM +0200, Philippe Mathieu-Daudé wrote:
> Introduce qemu_security_policy_taint() which allows unsafe (read
> "not very maintained") code to 'taint' QEMU security policy.
>
> The "security policy" is the @SecurityPolicy QAPI enum, composed of:
> - "none" (no policy
Hi Oleksandr,
On 03/09/2021 09:33, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Host bridge controller's ECAM space is mapped into Domain-0's p2m,
thus it is not possible to trap the same for vPCI via MMIO handlers.
For this to work we need to not map those while constructing t
Hi Oleksandr,
On 03/09/2021 09:33, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
In order vPCI to work it needs all access to PCI configuration space
(ECAM) to be synchronized among all entities, e.g. hardware domain and
guests.
I am not entirely sure what you mean by "synchro
flight 164895 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164895/
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-arm64-libvirt
Hi Oleksandr,
On 03/09/2021 09:33, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Add new device type (DEV_PCI) to distinguish PCI devices from platform
DT devices, so some drivers, like IOMMU, can handle PCI devices
differently.
I think it would be better to fold this change i
On 09/09/2021 17:34, Kevin Stefanov wrote:
> The spec requires 64-byte alignment, not 16.
>
> Signed-off-by: Kevin Stefanov
> ---
> CC: Jan Beulich
> CC: Andrew Cooper
>
> Note: This does not fix the FACS alignment inside guests yet. See next
> patch.
The history here is complex.
c/s 938cee9d4
This will make us reallocate fmt tests when the arch list changes.
It's not ideal because it means tests jumping about across arches and
might let regressions go through but it's better than just dropping
them, and doing a better approach is complex.
This changes some jobs and adds others, roughly
Change the order to match fmtarches_outer in do_pv_debian_tests.
We are going to want to add an indirection here but not change
anything.
No change to output from standalone-generate-dump-flight-runvars.
Signed-off-by: Ian Jackson
---
mfi-common | 2 +-
1 file changed, 1 insertion(+), 1 deleti
This makes radical changes to the test ste for the linux-linus and
linux-next branches.
Mostly, tests are dropped but some 64-bit dom0 tests are added to
replace them.
Requested-by: Juergen Gross
Signed-off-by: Ian Jackson
---
mfi-common | 5 +
1 file changed, 5 insertions(+)
diff --git a
This will allow test choices to depend on the actual rather than
entire dom0arches.
No change to output from standalone-generate-dump-flight-runvars.
Signed-off-by: Ian Jackson
---
mfi-common | 6 ++
1 file changed, 6 insertions(+)
diff --git a/mfi-common b/mfi-common
index 2834411f..70e17
On 9/9/21 11:35 AM, Jan Beulich wrote:
> On 03.09.2021 21:06, Daniel P. Smith wrote:
>> The internal define flag is not used by any XSM module, removing the #ifdef
>> leaving the generic event channel labeling as always present.
>
> Already on v2 I did ask
>
> "I'm not fully convinced of this rem
RSDP's size is 64 bytes and later in the function, its buffer is
hardcoded to be 64 bytes long. Don't bother to allocate a whole page.
Signed-off-by: Kevin Stefanov
---
CC: Andrew Cooper
CC: Ian Jackson
CC: Wei Liu
CC: Anthony PERARD
---
tools/libs/light/libxl_x86_acpi.c | 2 +-
1 file chang
The pointer resulting from libxl__malloc() has no explicit alignment.
As an implementation detail, it has 16-byte alignment.
When this buffer is used by libacpi aligning ACPI tables to greater
than 16 does not work correctly. This causes the FACS to not be
64-byte aligned when the ACPI tables are
When booting Xen as a PVH guest, it currently complains:
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:b004,1:0], pm1x_evt[1:b000,1:0]
(XEN) ACPI: FACS is not 64-byte aligned: 0xfc001010
(XEN) ACPI: wakeup_vec[fc00101c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee0
This is caused by severa
The spec requires 64-byte alignment, not 16.
Signed-off-by: Kevin Stefanov
---
CC: Jan Beulich
CC: Andrew Cooper
Note: This does not fix the FACS alignment inside guests yet. See next
patch.
---
tools/libacpi/build.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/li
Juergen Gross writes ("Re: [PATCH v2 1/3] stubdom: fix build with disabled
pv-grub"):
> On 09.09.21 15:23, Ian Jackson wrote:
> > How about "pv-grub-maybe" ? Or something.
>
> What about "pv-grub-if-enabled"?
Fine by me.
> And could that be done when committing, or should I send another round?
flight 164912 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164912/
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
On 03.09.2021 21:06, Daniel P. Smith wrote:
> SILO implements a few XSM hooks to extended the decision logic beyond
> what is defined in the dummy/default policy. For each of the hooks, it
> falls back to the dummy/default policy. The fall back is done a slight
> round-about way. This commit makes
On 03.09.2021 21:06, Daniel P. Smith wrote:
> The internal define flag is not used by any XSM module, removing the #ifdef
> leaving the generic event channel labeling as always present.
Already on v2 I did ask
"I'm not fully convinced of this removal: Does it get in the way of
anything?"
I have
asm() constraints need to fit both the intended insn(s) which the
respective operands are going to be used with as well as the actual kind
of value specified. "m" (alone) together with a constant, however, leads
to gcc saying
error: memory input is not directly addressable
while clang complains
flight 164890 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164890/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
While LLVM's lld is supposed to be a drop-in replacement for GNU ld [1],
it appears to not understand quoted section names as operands to e.g.
ADDR(). Therefore the original workaround broke the build in
environments where ld is actually LLVM's, like on FreeBSD.
Fixes: 58ad654ebce7 ("x86: work aro
Running $(MAKE) like that in a $(shell ) while parsing the Makefile
doesn't work reliably. In some case, make will complain with
"jobserver unavailable: using -j1. Add '+' to parent make rule.".
Also, it isn't possible to distinguish between the output produced by
the target "xenversion" and `make
Hi Julien,
Thanks for the clarification!
I aim towards to prepare implementation for upstream to disable SWIOTLB for
IOMMU-protected devices in Dom0.
To provide this functionality need to add additional binding for each protected
device in device-tree.
After this step, I will also prepare the p
On 09.09.21 15:23, Ian Jackson wrote:
Juergen Gross writes ("[PATCH v2 1/3] stubdom: fix build with disabled
pv-grub"):
Today the build will fail if --disable-pv-grub as a parameter of
configure, as the main Makefile will unconditionally try to build a
32-bit pv-grub stubdom.
Fix that by intro
On 20/08/2021 17:03, Rahul Singh wrote:
Hi Julien,
Hi Rahul,
On 19 Aug 2021, at 2:00 pm, Julien Grall wrote:
Hi Rahul,
On 19/08/2021 13:02, Rahul Singh wrote:
libxl will create an emulated PCI device tree node in the device tree to
enable the guest OS to discover the virtual PCI during
Hi Rahul,
On 19/08/2021 13:02, Rahul Singh wrote:
The existing VPCI support available for X86 is adapted for Arm.
When the device is added to XEN via the hyper call
“PHYSDEVOP_pci_device_add”, VPCI handler for the config space
access is added to the Xen to emulate the PCI devices config space.
Juergen Gross writes ("[PATCH v2 1/3] stubdom: fix build with disabled
pv-grub"):
> Today the build will fail if --disable-pv-grub as a parameter of
> configure, as the main Makefile will unconditionally try to build a
> 32-bit pv-grub stubdom.
>
> Fix that by introducing a pv-grub32 target in st
On 09.09.21 15:47, Jan Beulich wrote:
> On 09.09.2021 14:42, Oleksandr Andrushchenko wrote:
>> On 09.09.21 14:53, Jan Beulich wrote:
>>> On 09.09.2021 13:48, Oleksandr Andrushchenko wrote:
On 09.09.21 12:21, Jan Beulich wrote:
> For the bit in question, where the goal appears to be to hav
Hi,
On 19/08/2021 13:02, Rahul Singh wrote:
Compilation error is observed when HAS_PCI is enabled for ARM
architecture.
Add definition for arch_iommu_use_permitted() and
arch_pci_clean_pirqs().Implement dummy functions for pci_conf_read*() to
fix compilation error.
pci.c: In function ‘deassign
Using qemu-traditional as device model is deprecated for some time now.
So change the default for building it to "disable". This will affect
ioemu-stubdom, too, as there is a direct dependency between the two.
Today it is possible to use a PVH/HVM Linux-based stubdom as device
model. Additionally
This is a first step of deprecating pv-grub and qemu-trad including
ioemu-stubdom. Switch the default to not building it.
Changes in V2:
- new patch 3
- added CHANGELOG.md entry in patch 2
Juergen Gross (3):
stubdom: fix build with disabled pv-grub
stubdom: disable building pv-grub
tools: d
The stubdom based pv-grub is using a very outdated version of grub
(0.97) and should not be used any longer. Mainline grub has support for
PV guests for a long time now, so that should be used as a boot loader
of a PV domain.
So disable building pv-grub per default. In case someone really wants
to
Today the build will fail if --disable-pv-grub as a parameter of
configure, as the main Makefile will unconditionally try to build a
32-bit pv-grub stubdom.
Fix that by introducing a pv-grub32 target in stubdom/Makefile taking
care of this situation.
Signed-off-by: Juergen Gross
Reviewed-by: Sam
On 09.09.21 15:47, Jan Beulich wrote:
> On 09.09.2021 14:42, Oleksandr Andrushchenko wrote:
>> On 09.09.21 14:53, Jan Beulich wrote:
>>> On 09.09.2021 13:48, Oleksandr Andrushchenko wrote:
On 09.09.21 12:21, Jan Beulich wrote:
> For the bit in question, where the goal appears to be to hav
On 09.09.2021 14:42, Oleksandr Andrushchenko wrote:
> On 09.09.21 14:53, Jan Beulich wrote:
>> On 09.09.2021 13:48, Oleksandr Andrushchenko wrote:
>>> On 09.09.21 12:21, Jan Beulich wrote:
For the bit in question, where the goal appears to be to have hardware
hold the OR of guest and host
On 09.09.21 14:53, Jan Beulich wrote:
> On 09.09.2021 13:48, Oleksandr Andrushchenko wrote:
>> On 09.09.21 12:21, Jan Beulich wrote:
>>> For the bit in question, where the goal appears to be to have hardware
>>> hold the OR of guest and host values, an approach similar to that used
>>> for some of
flight 164889 xen-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164889/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail REGR. vs. 163759
test-armhf-armhf-xl-rtd
1 - 100 of 149 matches
Mail list logo
