On 09.09.2021 04:20, Penny Zheng wrote:
>> From: Stefano Stabellini
>> Sent: Thursday, September 9, 2021 7:58 AM
>>
>> On Wed, 8 Sep 2021, Penny Zheng wrote:
>>> 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
>>>
On 09.09.2021 07:22, Oleksandr Andrushchenko wrote:
>
> On 08.09.21 18:00, Jan Beulich wrote:
>> On 08.09.2021 16:31, Oleksandr Andrushchenko wrote:
>>> On 06.09.21 17:47, Jan Beulich wrote:
On 03.09.2021 12:08, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> I
On 09.09.2021 08:13, Oleksandr Andrushchenko wrote:
>
> On 06.09.21 17:51, Jan Beulich wrote:
>> On 03.09.2021 12:08, Oleksandr Andrushchenko wrote:
>>> @@ -37,12 +41,28 @@ static int map_range(unsigned long s, unsigned long e,
>>> void *data,
>>>unsigned long *c)
>>> {
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. Switch the default to not
building it.
NOTE: This should be mentioned in the release notes!
Juergen Gross (2):
stubdom: fix build with disabled pv-grub
stubdom: disable building pv-grub
Makefile | 4 ++--
stubdom/Makefile | 13 ++
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
---
Makefile
On 07.09.21 13:06, Jan Beulich wrote:
> On 07.09.2021 11:52, Oleksandr Andrushchenko wrote:
>> On 07.09.21 12:19, Jan Beulich wrote:
>>> On 07.09.2021 11:07, Oleksandr Andrushchenko wrote:
On 07.09.21 11:49, Jan Beulich wrote:
> On 07.09.2021 10:18, Oleksandr Andrushchenko wrote:
>> S
On 09.09.2021 10:39, Oleksandr Andrushchenko wrote:
>
> On 07.09.21 13:06, Jan Beulich wrote:
>> On 07.09.2021 11:52, Oleksandr Andrushchenko wrote:
>>> On 07.09.21 12:19, Jan Beulich wrote:
On 07.09.2021 11:07, Oleksandr Andrushchenko wrote:
> On 07.09.21 11:49, Jan Beulich wrote:
>>
On 09.09.2021 10:27, Juergen Gross wrote:
> This is a first step of deprecating pv-grub. Switch the default to not
> building it.
>
> NOTE: This should be mentioned in the release notes!
And/or perhaps in ./CHANGELOG.md?
Jan
On 09.09.21 11:43, Jan Beulich wrote:
> On 09.09.2021 10:39, Oleksandr Andrushchenko wrote:
>> On 07.09.21 13:06, Jan Beulich wrote:
>>> On 07.09.2021 11:52, Oleksandr Andrushchenko wrote:
On 07.09.21 12:19, Jan Beulich wrote:
> On 07.09.2021 11:07, Oleksandr Andrushchenko wrote:
>> O
On 09.09.21 10:44, Jan Beulich wrote:
On 09.09.2021 10:27, Juergen Gross wrote:
This is a first step of deprecating pv-grub. Switch the default to not
building it.
NOTE: This should be mentioned in the release notes!
And/or perhaps in ./CHANGELOG.md?
Oh yes, of course!
I'll add this to pat
Juergen Gross, le jeu. 09 sept. 2021 10:27:04 +0200, a ecrit:
> 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
Juergen Gross, le jeu. 09 sept. 2021 10:27:05 +0200, a ecrit:
> 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.
>
On 08.09.2021 11:52, Penny Zheng wrote:
> 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
> introduces a new helper assign_page for original page with a single order.
>
> Signed-off-b
On 07/09/2021 09:05, Hongda Deng wrote:
Hi Julien,
Hi,
(+ Stefano)
On 06/09/2021 10:04, Hongda Deng wrote:
Hi Julien,
If Xen wants a complete GICD ICPENDRn emulation to fix it, do you have any
suggestions.
Emulating ICPENDR is not easy with the existing vGIC. It would be great
to finally
On 09.09.21 11:24, Jan Beulich wrote:
> On 09.09.2021 07:22, Oleksandr Andrushchenko wrote:
>> On 08.09.21 18:00, Jan Beulich wrote:
>>> On 08.09.2021 16:31, Oleksandr Andrushchenko wrote:
On 06.09.21 17:47, Jan Beulich wrote:
> On 03.09.2021 12:08, Oleksandr Andrushchenko wrote:
>> F
On 09.09.21 11:26, Jan Beulich wrote:
> On 09.09.2021 08:13, Oleksandr Andrushchenko wrote:
>> On 06.09.21 17:51, Jan Beulich wrote:
>>> On 03.09.2021 12:08, Oleksandr Andrushchenko wrote:
@@ -37,12 +41,28 @@ static int map_range(unsigned long s, unsigned long e,
void *data,
On 09.09.2021 10:50, Oleksandr Andrushchenko wrote:
>
> On 09.09.21 11:43, Jan Beulich wrote:
>> On 09.09.2021 10:39, Oleksandr Andrushchenko wrote:
>>> On 07.09.21 13:06, Jan Beulich wrote:
On 07.09.2021 11:52, Oleksandr Andrushchenko wrote:
> On 07.09.21 12:19, Jan Beulich wrote:
>>
Hi Jan and Stefano
> -Original Message-
> From: Jan Beulich
> Sent: Thursday, September 9, 2021 5:06 PM
> To: Penny Zheng
> Cc: Bertrand Marquis ; Wei Chen
> ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org; jul...@xen.org
> Subject: Re: [PATCH v6 5/7] xen: re-define assign_pag
On 09.09.2021 11:12, Oleksandr Andrushchenko wrote:
> Anyways, I am open to any decision on what would be the right approach here:
>
> 1. Use range sets per BAR as in the patch
>
> 2. Remove range sets completely and have a per-vCPU list with mapping
>
> data as I described above
>
> 3. Anythin
On 09.09.2021 11:16, Oleksandr Andrushchenko wrote:
>
> On 09.09.21 11:26, Jan Beulich wrote:
>> On 09.09.2021 08:13, Oleksandr Andrushchenko wrote:
>>> On 06.09.21 17:51, Jan Beulich wrote:
On 03.09.2021 12:08, Oleksandr Andrushchenko wrote:
> @@ -37,12 +41,28 @@ static int map_range(uns
On 08.09.2021 19:33, Andrew Cooper wrote:
> We already print Intel features that aren't yet implemented/used, so be
> consistent on AMD too.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
branch xen-4.13-testing
xenbranch xen-4.13-testing
job build-amd64
testid xen-build
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tre
On 09.09.21 12:40, Jan Beulich wrote:
> On 09.09.2021 11:16, Oleksandr Andrushchenko wrote:
>> On 09.09.21 11:26, Jan Beulich wrote:
>>> On 09.09.2021 08:13, Oleksandr Andrushchenko wrote:
On 06.09.21 17:51, Jan Beulich wrote:
> On 03.09.2021 12:08, Oleksandr Andrushchenko wrote:
>> @
On 9/9/21 1:20 AM, 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 +-
> block.c
On 08.09.2021 18:19, Andrew Cooper wrote:
> The RDPRU instruction isn't supported at all (and it is unclear how this can
> ever be offered safely to guests).
An implicit hint to me to consider "x86emul: support RDPRU" rejected? That's
still in my queue waiting for ...
> However, a guest which ig
Ian,
On 09.09.2021 11:52, osstest service owner wrote:
> branch xen-4.13-testing
> xenbranch xen-4.13-testing
> job build-amd64
> testid xen-build
>
> Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
> Tree: qemuu git://xenbits.xen.org/
On 09/09/21 01:20, Philippe Mathieu-Daudé wrote:
+static QemuOptsList qemu_security_policy_opts = {
+.name = "security-policy",
+.implied_opt_name = "policy",
+.merge_lists = true,
+.head = QTAILQ_HEAD_INITIALIZER(qemu_security_policy_opts.head),
+.desc = {
+{
+
On Wed, Sep 08, 2021 at 02:01:43PM +0200, Jan Beulich wrote:
> On 08.09.2021 13:14, Anthony PERARD wrote:
> > What kind of issue is there with those tiny source files?
>
> To me they're ugly and their presence is at least mildly confusing.
> And apparently I'm not the only one thinking that way, o
On 09.09.21 12:39, Jan Beulich wrote:
> On 09.09.2021 11:12, Oleksandr Andrushchenko wrote:
>> Anyways, I am open to any decision on what would be the right approach here:
>>
>> 1. Use range sets per BAR as in the patch
>>
>> 2. Remove range sets completely and have a per-vCPU list with mapping
>>
Jan Beulich writes ("Re: [xen-4.13-testing bisection] complete build-amd64"):
> On 09.09.2021 11:52, osstest service owner wrote:
> > commit 9f3eda177a4b2d4a33ff1b0307cad42906396562
> > Author: Lin, Gary (HPS OE-Linux)
> > Date: Tue Aug 31 09:29:48 2021 +0800
> >
> > OvmfPkg/OvmfX
On Thu, Sep 09, 2021 at 01:20:14AM +0200, Philippe Mathieu-Daudé wrote:
> Hi,
>
> This series is experimental! The goal is to better limit the
> boundary of what code is considerated security critical, and
> what is less critical (but still important!).
>
> This approach was quickly discussed few
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: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 09.09.2021 12:03, Oleksandr Andrushchenko wrote:
> On 09.09.21 12:39, Jan Beulich wrote:
>> On 09.09.2021 11:12, Oleksandr Andrushchenko wrote:
>>> Anyways, I am open to any decision on what would be the right approach here:
>>>
>>> 1. Use range sets per BAR as in the patch
>>>
>>> 2. Remove ran
On Thu, Sep 09, 2021 at 11:40:07AM +0100, Daniel P. Berrangé wrote:
> 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-
On Thu, Sep 09, 2021 at 01:20:20AM +0200, Philippe Mathieu-Daudé wrote:
> Add DeviceClass::taints_security_policy field to allow an
> unsafe device to eventually taint the global security policy
> in DeviceRealize().
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> include/hw/qdev-core.h | 6 +
On Wed, Sep 08, 2021 at 02:27:17PM +0200, Jan Beulich wrote:
> On 08.09.2021 11:54, Anthony PERARD wrote:
> > --- a/tools/flask/policy/Makefile.common
> > +++ b/tools/flask/policy/Makefile.common
> > @@ -35,7 +35,7 @@ OUTPUT_POLICY ?= $(BEST_POLICY_VER)
> > #
> > #
On 09.09.21 13:46, Jan Beulich wrote:
> On 09.09.2021 12:03, Oleksandr Andrushchenko wrote:
>> On 09.09.21 12:39, Jan Beulich wrote:
>>> On 09.09.2021 11:12, Oleksandr Andrushchenko wrote:
Anyways, I am open to any decision on what would be the right approach
here:
1. Use rang
Hi Rahul,
On 19/08/2021 13:02, 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
On 09/09/2021 10:57, Jan Beulich wrote:
> On 08.09.2021 18:19, Andrew Cooper wrote:
>> The RDPRU instruction isn't supported at all (and it is unclear how this can
>> ever be offered safely to guests).
> An implicit hint to me to consider "x86emul: support RDPRU" rejected? That's
> still in my queu
On 09.09.2021 13:10, Anthony PERARD wrote:
> :-( I think I just found a package overriding XEN_VENDORVERSION with a
> command line argument, the AUR package. So ./version.sh needs help from
> the build system:
>
> Maybe
>
> XEN_FULLVERSION=$(shell env XEN_EXTRAVERSION=$(XEN_EXTRAVERSION)
> X
On 09.09.2021 13:34, Andrew Cooper wrote:
> On 09/09/2021 10:57, Jan Beulich wrote:
>> On 08.09.2021 18:19, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/hvm/svm/vmcb.c
>>> +++ b/xen/arch/x86/hvm/svm/vmcb.c
>>> @@ -70,7 +70,8 @@ static int construct_vmcb(struct vcpu *v)
>>> GENERAL2_INTERCEP
On 09.09.21 12:21, Jan Beulich wrote:
> On 09.09.2021 10:50, Oleksandr Andrushchenko wrote:
>> On 09.09.21 11:43, Jan Beulich wrote:
>>> On 09.09.2021 10:39, Oleksandr Andrushchenko wrote:
On 07.09.21 13:06, Jan Beulich wrote:
> On 07.09.2021 11:52, Oleksandr Andrushchenko wrote:
>> O
On 09.09.21 12:21, Jan Beulich wrote:
> On 09.09.2021 10:50, Oleksandr Andrushchenko wrote:
>> On 09.09.21 11:43, Jan Beulich wrote:
>>> On 09.09.2021 10:39, Oleksandr Andrushchenko wrote:
On 07.09.21 13:06, Jan Beulich wrote:
> On 07.09.2021 11:52, Oleksandr Andrushchenko wrote:
>> O
On 09.09.2021 13:30, Oleksandr Andrushchenko wrote:
> On 09.09.21 13:46, Jan Beulich wrote:
>> On 09.09.2021 12:03, Oleksandr Andrushchenko wrote:
>>> On 09.09.21 12:39, Jan Beulich wrote:
And in fact I wonder whether for DomU-s you want to support BAR changes
in the first place while mem
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 the MSI / MSI-X bits might be chosen: Mainta
On 210909 0120, Philippe Mathieu-Daudé wrote:
> Hi,
>
> This series is experimental! The goal is to better limit the
> boundary of what code is considerated security critical, and
> what is less critical (but still important!).
>
> This approach was quickly discussed few months ago with Markus
>
On 09/09/2021 12:47, Jan Beulich wrote:
> On 09.09.2021 13:34, Andrew Cooper wrote:
>> On 09/09/2021 10:57, Jan Beulich wrote:
>>> On 08.09.2021 18:19, Andrew Cooper wrote:
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -70,7 +70,8 @@ static int construct_vmcb
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
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
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 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
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
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 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
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
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
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
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
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.
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
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
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
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
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
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-
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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: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 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 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
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
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
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
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
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
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
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/
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
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
1 - 100 of 149 matches
Mail list logo
