Signed-off-by: Vikram Garhwal
---
tools/xl/xl.h | 2 ++
tools/xl/xl_cmdtable.c | 12
tools/xl/xl_vmcontrol.c | 51 +
3 files changed, 65 insertions(+)
diff --git a/tools/xl/xl.h b/tools/xl/xl.h
index 7e23f30..63be31e 100644
xc_domain_add_fpga() sends the device tree binary overlay and size of .dtbo to
xen.
xc_domain_del_fpga() sends full path for the node to be removed.
Signed-off-by: Vikram Garhwal
---
tools/include/xenctrl.h | 4 +++
tools/libs/ctrl/Makefile | 1 +
tools/libs/ctrl/xc_fpga.c | 82
Introduce domctl XEN_DOMCTL_addfpga to add a device-tree node through device
tree overlay. This works with a device tree overlay(.dtbo) as input.
Add check_pfdt() to do sanity check on the dtbo.
Also, added overlay_get_node_info() to get the node's full name with path. This
comes handy when check
Signed-off-by: Vikram Garhwal
---
tools/include/libxl.h | 5 +++
tools/libs/light/Makefile | 1 +
tools/libs/light/libxl_fpga.c | 73 +++
3 files changed, 79 insertions(+)
create mode 100644 tools/libs/light/libxl_fpga.c
diff --git a/tools/i
Introduce domctl XEN_DOMCTL_delfpga to remove a device-tree node added through
device tree overlay. Currently, this supports removing one node at a time.
DT node removal works with the following steps:
1. finds a node with given path.
2. Check if the node is used by any of dom0 or domus. I
iommu_remove_dt_device function is introduced for supporting dynamic programming
i.e. adding and removing a node during runtime. When user removes the device
node, iommu_remove_dt_device() removes the device entry from smmu-masters too
using following steps:
1. Find if SMMU master exists for th
Remove static function type from overlay_get_target().
Signed-off-by: Vikram Garhwal
---
xen/common/libfdt/fdt_overlay.c | 2 +-
xen/include/xen/libfdt/libfdt.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/xen/common/libfdt/fdt_overlay.c b/xen/common/libfdt/fdt_overlay.c
fdt_overlay.c uses a number of functions. Below is the list of functions copied
from Linux tree(commid: 6e9c9686d826564f44c93cdd6f111b1c0a9dc224) to compile
the fdt_overlay.c():
libfdt_internal.h: FDT_RO_PROBE() and can_assume().
libfdt.h: fdt_for_each_subnode(), fdt_get_max_phandle(),
fdt_fo
Add _dt_find_by_path() to find a matching node with path for a dt_device_node.
Signed-off-by: Vikram Garhwal
---
xen/common/device_tree.c | 10 --
xen/include/xen/device_tree.h | 9 +
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/xen/common/device_tree.c b
Hi,
This RFC patch series is for introducing dynamic programming i.e. add/remove the
devices during run time. Using "xl fpga-add" a device can be added with dtbo.
fdt_overlay.c file is taken from Linux and other existing fdt files are modified
to accommodate the fdt_overlay. The changes w.r.t. exi
Keep libfdt library functionalities after boot of hw_domain. This is done to
access fdt library function which are required for adding device tree overlay
nodes for dynamic programming of nodes.
Signed-off-by: Vikram Garhwal
---
xen/common/libfdt/Makefile | 1 -
1 file changed, 1 deletion(-)
di
Change function type of following function to access during runtime:
1. handle_device_interrupt()
2. map_irq_to_domain()
3. map_range_to_domain()
4. unflatten_dt_node()
5. unflatten_device_tree()
Remove .init from domain_build.o and move map_range_data declaration to
domain_bui
Add dt_print_node_names() to print all nodes under a dt_device_node.
dt_print_node_names() takes a dt_device_node type input and prints the node name
of all the subsequent nodes. This is added for debugging purpose for device tree
overlays.
Signed-off-by: Vikram Garhwal
---
xen/common/device_tre
Xen is missing fdt overlay functionalities. FDT overlay is required for changing
the device tree nodes during run-time.
fdt_overlay.c file is copied from Linux tree's following patch:
commit: 6e9c9686d826564f44c93cdd6f111b1c0a9dc224
scripts/dtc: Update to upstream version v1.6.0-31-gcbca977ea121
On 01.09.2021 20:11, Julien Grall wrote:
> On 01/09/2021 14:39, Jan Beulich wrote:
>> back in 2016 Andrew added code to x86'es variant to avoid interleaving
>> of output. The same issue ought to exist on Arm.
>
> Agree. I guess we got away so far because it is pretty rare to have two
> CPUs runni
Hi Michael:
Thanks for your review.
On 9/2/2021 8:15 AM, Michael Kelley wrote:
From: Tianyu Lan Sent: Friday, August 27, 2021 10:21 AM
Hyper-V exposes shared memory boundary via cpuid
HYPERV_CPUID_ISOLATION_CONFIG and store it in the
shared_gpa_boundary of ms_hyperv struct. This prepa
On 01.09.2021 18:13, Roger Pau Monné wrote:
> On Wed, Sep 01, 2021 at 04:19:40PM +0200, Jan Beulich wrote:
>> On 01.09.2021 15:56, Roger Pau Monné wrote:
>>> On Tue, Aug 31, 2021 at 10:53:59AM +0200, Jan Beulich wrote:
On 30.08.2021 15:01, Jan Beulich wrote:
> The code building PVH Dom0 ma
flight 164725 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164725/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 164690
test-armhf-armhf-libvirt 16 sav
Hi Stefano,
On 01.09.2021 19:54, Stefano Stabellini wrote:
> On Wed, 1 Sep 2021, Julien Grall wrote:
>> On 01/09/2021 14:10, Bertrand Marquis wrote:
On 1 Sep 2021, at 13:55, Julien Grall wrote:
Hi,
On 01/09/2021 13:43, Michal Orzel wrote:
> Introduce new Xen command l
flight 164746 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164746/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 164674
build-amd64-xsm
On 01.09.2021 18:21, Stefano Stabellini wrote:
> On Wed, 1 Sep 2021, Wei Chen wrote:
>>> Stefano Stabellini
>>> Sent: 2021年9月1日 5:36
>>>
>>> On Tue, 31 Aug 2021, Wei Chen wrote:
I don't really like this implementation. I want the behavior of
numa_set_distance just like the function name,
From: Michael Kelley Sent: Wednesday, September 1,
2021 7:34 PM
[snip]
> > +int netvsc_dma_map(struct hv_device *hv_dev,
> > + struct hv_netvsc_packet *packet,
> > + struct hv_page_buffer *pb)
> > +{
> > + u32 page_count = packet->cp_partial ?
> > + packet
flight 164743 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164743/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 164674
build-amd64-xsm
From: Tianyu Lan Sent: Friday, August 27, 2021 10:21 AM
>
> Hyperv provides GHCB protocol to write Synthetic Interrupt
> Controller MSR registers in Isolation VM with AMD SEV SNP
> and these registers are emulated by hypervisor directly.
> Hyperv requires to write SINTx MSR registers twice. First
flight 164740 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164740/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 164674
build-amd64-xsm
> -Original Message-
> From: Stefano Stabellini
> Sent: 2021年9月2日 2:31
> To: Julien Grall
> Cc: Stefano Stabellini ; Wei Chen
> ; xen-devel@lists.xenproject.org; jbeul...@suse.com;
> Bertrand Marquis
> Subject: Re: [XEN RFC PATCH 25/40] xen/arm: unified entry to parse all
> NUMA data f
flight 164737 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164737/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 164674
build-amd64-xsm
From: Tianyu Lan Sent: Friday, August 27, 2021 10:21 AM
>
> In Isolation VM, all shared memory with host needs to mark visible
> to host via hvcall. vmbus_establish_gpadl() has already done it for
> netvsc rx/tx ring buffer. The page buffer used by vmbus_sendpacket_
> pagebuffer() stills need to
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini
> Sent: 2021年9月2日 0:22
> To: Wei Chen
> Cc: Stefano Stabellini ; xen-
> de...@lists.xenproject.org; jul...@xen.org; Bertrand Marquis
>
> Subject: RE: [XEN RFC PATCH 24/40] xen/arm: introduce a helper to parse
> device tree NUMA
flight 164693 xen-4.11-testing real [real]
flight 164735 xen-4.11-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164693/
http://logs.test-lab.xenproject.org/osstest/logs/164735/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
From: Tianyu Lan Sent: Friday, August 27, 2021 10:21 AM
>
Per previous comment, the Subject line tag should be "scsi: storvsc: "
> In Isolation VM, all shared memory with host needs to mark visible
> to host via hvcall. vmbus_establish_gpadl() has already done it for
> storvsc rx/tx ring buffer
Hi Akashi, Oleksandr,
> -Original Message-
> From: Xen-devel On Behalf Of Wei
> Chen
> Sent: 2021年9月2日 9:31
> To: AKASHI Takahiro
> Cc: Oleksandr Tyshchenko ; Stefano Stabellini
> ; Alex Benn??e ; Kaly Xin
> ; Stratos Mailing List ;
> virtio-...@lists.oasis-open.org; Arnd Bergmann ;
> Vi
flight 164733 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164733/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 164674
build-amd64-xsm
Hi Akashi,
> -Original Message-
> From: AKASHI Takahiro
> Sent: 2021年9月1日 20:29
> To: Wei Chen
> Cc: Oleksandr Tyshchenko ; Stefano Stabellini
> ; Alex Benn??e ; Kaly Xin
> ; Stratos Mailing List ;
> virtio-...@lists.oasis-open.org; Arnd Bergmann ;
> Viresh Kumar ; Stefano Stabellini
> ;
From: Tianyu Lan Sent: Friday, August 27, 2021 10:21 AM
>
> hyperv Isolation VM requires bounce buffer support to copy
> data from/to encrypted memory and so enable swiotlb force
> mode to use swiotlb bounce buffer for DMA transaction.
>
> In Isolation VM with AMD SEV, the bounce buffer needs to
From: Tianyu Lan Sent: Friday, August 27, 2021 10:21 AM
>
Subject tag should be "Drivers: hv: vmbus: "
> VMbus ring buffer are shared with host and it's need to
> be accessed via extra address space of Isolation VM with
> AMD SNP support. This patch is to map the ring buffer
> address in extra
From: Tianyu Lan Sent: Friday, August 27, 2021 10:21 AM
>
Subject line tag should be "Drivers: hv: vmbus:"
> The monitor pages in the CHANNELMSG_INITIATE_CONTACT msg are shared
> with host in Isolation VM and so it's necessary to use hvcall to set
> them visible to host. In Isolation VM with AM
From: Tianyu Lan Sent: Friday, August 27, 2021 10:21 AM
>
Subject line tag should probably be "x86/hyperv:" since the majority
of the code added is under arch/x86.
> hyperv provides ghcb hvcall to handle VMBus
> HVCALL_SIGNAL_EVENT and HVCALL_POST_MESSAGE
> msg in SNP Isolation VM. Add such sup
From: Tianyu Lan Sent: Friday, August 27, 2021 10:21 AM
>
> Mark vmbus ring buffer visible with set_memory_decrypted() when
> establish gpadl handle.
>
> Signed-off-by: Tianyu Lan
> ---
> Change since v3:
>* Change vmbus_teardown_gpadl() parameter and put gpadl handle,
>buffer a
From: Tianyu Lan Sent: Friday, August 27, 2021 10:21 AM
>
> Add new hvcall guest address host visibility support to mark
> memory visible to host. Call it inside set_memory_decrypted
> /encrypted(). Add HYPERVISOR feature check in the
> hv_is_isolation_supported() to optimize in non-virtualizatio
From: Tianyu Lan Sent: Friday, August 27, 2021 10:21 AM
>
> Hyper-V exposes shared memory boundary via cpuid
> HYPERV_CPUID_ISOLATION_CONFIG and store it in the
> shared_gpa_boundary of ms_hyperv struct. This prepares
> to share memory with host for SNP guest.
>
> Signed-off-by: Tianyu Lan
> --
From: Tianyu Lan Sent: Friday, August 27, 2021 10:21 AM
>
> Hyperv exposes GHCB page via SEV ES GHCB MSR for SNP guest
> to communicate with hypervisor. Map GHCB page for all
> cpus to read/write MSR register and submit hvcall request
> via ghcb page.
>
> Signed-off-by: Tianyu Lan
> ---
> Chagn
flight 164728 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164728/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 164674
build-amd64-xsm
flight 164709 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164709/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 6 kernel-build fail REGR. vs. 152332
test-arm64-arm64-xl
flight 164718 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164718/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 164674
build-amd64-xsm
flight 164690 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164690/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 164601
test-armhf-armhf-libvirt 16 sav
On 01/09/2021 17:06, Jan Beulich wrote:
> The function may fail; it is not correct to indicate "success" in this
> case up the call stack. Mark the function must-check to prove all
> cases have been caught (and no new ones will get introduced).
>
> Signed-off-by: Jan Beulich
> ---
> In the grant-t
flight 164687 xen-unstable real [real]
flight 164724 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164687/
http://logs.test-lab.xenproject.org/osstest/logs/164724/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm6
Hi Stefano,
On 01/09/2021 18:54, Stefano Stabellini wrote:
On Wed, 1 Sep 2021, Julien Grall wrote:
On 01/09/2021 14:10, Bertrand Marquis wrote:
On 1 Sep 2021, at 13:55, Julien Grall wrote:
Hi,
On 01/09/2021 13:43, Michal Orzel wrote:
Introduce new Xen command line parameter called "pmu_acc
On Tue, 31 Aug 2021, Julien Grall wrote:
> Hi Stefano,
>
> On 31/08/2021 01:54, Stefano Stabellini wrote:
> > On Wed, 11 Aug 2021, Wei Chen wrote:
> > > In this API, we scan whole device tree to parse CPU node id, memory
> > > node id and distance-map. Though early_scan_node will invoke has a
> >
On 01/09/2021 14:39, Jan Beulich wrote:
All,
back in 2016 Andrew added code to x86'es variant to avoid interleaving
of output. The same issue ought to exist on Arm.
Agree. I guess we got away so far because it is pretty rare to have two
CPUs running at the same.
The lock acquired,
or mo
On Wed, 1 Sep 2021, Julien Grall wrote:
> On 01/09/2021 14:10, Bertrand Marquis wrote:
> > > On 1 Sep 2021, at 13:55, Julien Grall wrote:
> > >
> > > Hi,
> > >
> > > On 01/09/2021 13:43, Michal Orzel wrote:
> > > > Introduce new Xen command line parameter called "pmu_access".
> > > > The default
branch xen-unstable
xenbranch xen-unstable
job build-amd64-xsm
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.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
Tree: xe
Hi Akashi,
I am sorry for the possible format issues.
>
> > > >
> > > > It's a RFC discussion. We have tested this RFC patch internally.
> > > > https://lists.xenproject.org/archives/html/xen-devel/2021-
> > > 07/msg01532.html
> > >
> > > I'm afraid that I miss something here, but I don't know
>
flight 164704 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164704/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 164674
build-amd64-xsm
On Wed, 1 Sep 2021, Wei Chen wrote:
> Hi Stefano,
>
> > -Original Message-
> > From: Xen-devel On Behalf Of
> > Stefano Stabellini
> > Sent: 2021年9月1日 5:36
> > To: Wei Chen
> > Cc: Stefano Stabellini ; xen-
> > de...@lists.xenproject.org; jul...@xen.org; Bertrand Marquis
> >
> > Subject
On Wed, Sep 01, 2021 at 04:19:40PM +0200, Jan Beulich wrote:
> On 01.09.2021 15:56, Roger Pau Monné wrote:
> > On Tue, Aug 31, 2021 at 10:53:59AM +0200, Jan Beulich wrote:
> >> On 30.08.2021 15:01, Jan Beulich wrote:
> >>> The code building PVH Dom0 made use of sequences of P2M changes
> >>> which
The function may fail; it is not correct to indicate "success" in this
case up the call stack. Mark the function must-check to prove all
cases have been caught (and no new ones will get introduced).
Signed-off-by: Jan Beulich
---
In the grant-transfer case it is not really clear to me whether we
On 01.09.2021 17:24, Juergen Gross wrote:
> On 01.09.21 17:06, Jan Beulich wrote:
>> On 30.08.2021 15:01, Jan Beulich wrote:
>>> The code building PVH Dom0 made use of sequences of P2M changes
>>> which are disallowed as of XSA-378. First of all population of the
>>> first Mb of memory needs to be
On 01.09.21 17:06, Jan Beulich wrote:
On 30.08.2021 15:01, Jan Beulich wrote:
The code building PVH Dom0 made use of sequences of P2M changes
which are disallowed as of XSA-378. First of all population of the
first Mb of memory needs to be redone. Then, largely as a
workaround, checking introduc
On 30.08.2021 15:01, Jan Beulich wrote:
> The code building PVH Dom0 made use of sequences of P2M changes
> which are disallowed as of XSA-378. First of all population of the
> first Mb of memory needs to be redone. Then, largely as a
> workaround, checking introduced by XSA-378 needs to be slightl
branch xen-unstable
xenbranch xen-unstable
job build-amd64
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.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
Tree: xen gi
On 01.09.2021 16:19, Jan Beulich wrote:
> On 01.09.2021 15:56, Roger Pau Monné wrote:
>> Do you have iommu debug/verbose enabled to catch iommu faults?
>
> I'll try to remember to check that, but since Linux hasn't
> brought up APs yet I don't think there's any device activity
> just yet.
No IOMM
On 01/09/2021 14:10, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 1 Sep 2021, at 13:55, Julien Grall wrote:
Hi,
On 01/09/2021 13:43, Michal Orzel wrote:
Introduce new Xen command line parameter called "pmu_access".
The default value is "trap": Xen traps PMU accesses.
In case of
On 01.09.2021 15:56, Roger Pau Monné wrote:
> On Tue, Aug 31, 2021 at 10:53:59AM +0200, Jan Beulich wrote:
>> On 30.08.2021 15:01, Jan Beulich wrote:
>>> The code building PVH Dom0 made use of sequences of P2M changes
>>> which are disallowed as of XSA-378. First of all population of the
>>> first
On 01/09/2021 14:22, Jason Andryuk wrote:
> On Wed, Sep 1, 2021 at 5:34 AM Xen.org security team wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Xen Security Advisory CVE-2021-28694,CVE-2021-28695,CVE-2021-28696 / XSA-378
>>version 3
>>
>>
On 01.09.2021 15:48, Roger Pau Monné wrote:
> On Wed, Sep 01, 2021 at 11:53:03AM +0200, Jan Beulich wrote:
>> The issue isn't just with execution, though, and as a result I may
>> need to change the logic here to also include at least W. As of
>> one of the XSA-378 changes we may now pass just p2m_
On Tue, Aug 31, 2021 at 10:53:59AM +0200, Jan Beulich wrote:
> On 30.08.2021 15:01, Jan Beulich wrote:
> > The code building PVH Dom0 made use of sequences of P2M changes
> > which are disallowed as of XSA-378. First of all population of the
> > first Mb of memory needs to be redone. Then, largely
flight 164689 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164689/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 6 kernel-build fail REGR. vs. 152332
test-arm64-arm64-xl
On Wed, Sep 01, 2021 at 11:53:03AM +0200, Jan Beulich wrote:
> On 01.09.2021 10:50, Roger Pau Monné wrote:
> > On Tue, Aug 31, 2021 at 05:38:49PM +0200, Jan Beulich wrote:
> >> On 31.08.2021 17:25, Andrew Cooper wrote:
> >>> On 31/08/2021 14:26, Jan Beulich wrote:
> On 31.08.2021 15:16, Andrew
(removing all lists inappropriate for a question like this one)
On 01.09.2021 15:22, Jason Andryuk wrote:
> On Wed, Sep 1, 2021 at 5:34 AM Xen.org security team wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Xen Security Advisory CVE-2021-28694,CVE-2021-28695,CVE-2021-2869
All,
back in 2016 Andrew added code to x86'es variant to avoid interleaving
of output. The same issue ought to exist on Arm. The lock acquired,
or more importantly the turning off of IRQs while doing so, is now
getting in the way of having PVH Dom0's state dumped the 2nd time. For
register state I
On Wed, Sep 1, 2021 at 5:34 AM Xen.org security team wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Xen Security Advisory CVE-2021-28694,CVE-2021-28695,CVE-2021-28696 / XSA-378
>version 3
>
>IOMMU page mapping issues on x86
Stefan Hajnoczi writes:
> [[PGP Signed Part:Undecided]]
> On Wed, Aug 04, 2021 at 12:20:01PM -0700, Stefano Stabellini wrote:
>> > Could we consider the kernel internally converting IOREQ messages from
>> > the Xen hypervisor to eventfd events? Would this scale with other kernel
>> > hypercall
flight 164679 qemu-upstream-unstable real [real]
flight 164696 qemu-upstream-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164679/
http://logs.test-lab.xenproject.org/osstest/logs/164696/
Failures :-/ but no regressions.
Tests which are failing intermittently (not b
Hi Julien,
> On 1 Sep 2021, at 13:55, Julien Grall wrote:
>
> Hi,
>
> On 01/09/2021 13:43, Michal Orzel wrote:
>> Introduce new Xen command line parameter called "pmu_access".
>> The default value is "trap": Xen traps PMU accesses.
>> In case of setting pmu_access to "native", Xen does not trap
On 01.09.2021 14:47, Andrew Cooper wrote:
> On 31/08/2021 16:38, Jan Beulich wrote:
>> On 31.08.2021 17:25, Andrew Cooper wrote:
>>> On 31/08/2021 14:26, Jan Beulich wrote:
On 31.08.2021 15:16, Andrew Cooper wrote:
> On 30/08/2021 14:02, Jan Beulich wrote:
>> Further permit "access" to
Hi,
On 01/09/2021 13:43, Michal Orzel wrote:
Introduce new Xen command line parameter called "pmu_access".
The default value is "trap": Xen traps PMU accesses.
In case of setting pmu_access to "native", Xen does not trap
PMU accesses allowing all the guests to access PMU registers.
However, gues
On 31/08/2021 16:38, Jan Beulich wrote:
> On 31.08.2021 17:25, Andrew Cooper wrote:
>> On 31/08/2021 14:26, Jan Beulich wrote:
>>> On 31.08.2021 15:16, Andrew Cooper wrote:
On 30/08/2021 14:02, Jan Beulich wrote:
> Further permit "access" to differ in the "executable" attribute. While
Introduce new Xen command line parameter called "pmu_access".
The default value is "trap": Xen traps PMU accesses.
In case of setting pmu_access to "native", Xen does not trap
PMU accesses allowing all the guests to access PMU registers.
However, guests cannot make use of PMU overflow interrupts as
Hi Wei,
On Wed, Sep 01, 2021 at 11:12:58AM +, Wei Chen wrote:
> Hi Akashi,
>
> > -Original Message-
> > From: AKASHI Takahiro
> > Sent: 2021年8月31日 14:18
> > To: Wei Chen
> > Cc: Oleksandr Tyshchenko ; Stefano Stabellini
> > ; Alex Benn??e ; Kaly Xin
> > ; Stratos Mailing List ;
> >
flight 164695 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164695/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 164674
build-amd64-xsm
On 31/08/2021 14:36, Jan Beulich wrote:
> On 31.08.2021 15:27, Andrew Cooper wrote:
>> On 31/08/2021 14:19, Jan Beulich wrote:
>> @@ -1095,6 +1101,17 @@ static int __init pvh_setup_acpi(struct
>> nr_pages = PFN_UP((d->arch.e820[i].addr & ~PAGE_MASK) +
>>
flight 164688 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164688/
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-amd64-libvirt
Hi Akashi,
> -Original Message-
> From: AKASHI Takahiro
> Sent: 2021年8月31日 14:18
> To: Wei Chen
> Cc: Oleksandr Tyshchenko ; Stefano Stabellini
> ; Alex Benn??e ; Kaly Xin
> ; Stratos Mailing List ;
> virtio-...@lists.oasis-open.org; Arnd Bergmann ;
> Viresh Kumar ; Stefano Stabellini
>
Hi Stefano,
> -Original Message-
> From: Xen-devel On Behalf Of
> Stefano Stabellini
> Sent: 2021年9月1日 5:36
> To: Wei Chen
> Cc: Stefano Stabellini ; xen-
> de...@lists.xenproject.org; jul...@xen.org; Bertrand Marquis
>
> Subject: RE: [XEN RFC PATCH 24/40] xen/arm: introduce a helper to
Juergen Gross writes ("Re: [PATCH] Config: use Mini-OS master for
xen-unstable"):
> How do you suggest to proceed then?
>
> Will every Mini-OS commit require to be followed by a Xen commit then,
> which will either result in a test success, or in a revert of that Xen
> commit?
That is how the cu
flight 164686 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164686/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 164674
build-amd64-xsm
Hi Roman
On 01/09/2021 10:59, Roman Skakun wrote:
If you have a setup where Dom0 is not 1:1 mapped (which is not currently
possible with upstream Xen but it is possible with cache coloring) and
uses the IOMMU to make device DMA work like regular DomUs, then passing
XENFEAT_not_direct_mapped
flight 164692 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164692/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 96607a8e680e7f965ca868d11f8b0636317d2618
baseline version:
xen 8064
Hi, Stefano!
Thanks for responding!
> If you have a setup where Dom0 is not 1:1 mapped (which is not currently
> possible with upstream Xen but it is possible with cache coloring) and
> uses the IOMMU to make device DMA work like regular DomUs, then passing
> XENFEAT_not_direct_mapped to Linux wo
On 01.09.2021 11:53, Juergen Gross wrote:
> On 01.09.21 10:59, Jan Beulich wrote:
>> On 31.08.2021 09:30, Juergen Gross wrote:
>>> In order to get Mini-OS master branch tested by OSStest, use it for
>>> xen-unstable.
>>>
>>> Signed-off-by: Juergen Gross
>>> ---
>>> There are some Mini-OS patches p
On 01.09.21 10:59, Jan Beulich wrote:
On 31.08.2021 09:30, Juergen Gross wrote:
In order to get Mini-OS master branch tested by OSStest, use it for
xen-unstable.
Signed-off-by: Juergen Gross
---
There are some Mini-OS patches pending, of which at least the Mini-OS
netfront fix should be commit
On 01.09.2021 10:50, Roger Pau Monné wrote:
> On Tue, Aug 31, 2021 at 05:38:49PM +0200, Jan Beulich wrote:
>> On 31.08.2021 17:25, Andrew Cooper wrote:
>>> On 31/08/2021 14:26, Jan Beulich wrote:
On 31.08.2021 15:16, Andrew Cooper wrote:
> On 30/08/2021 14:02, Jan Beulich wrote:
>> Fur
Hi Julien,
On 06.08.2021 13:12, Julien Grall wrote:
>
>
> On 29/07/2021 12:47, Michal Orzel wrote:
>> Hi Julien,
>
> Hi Michal,
>
>> On 29.07.2021 13:20, Julien Grall wrote:
>>> Hi Michal,
>>>
>>> On 29/07/2021 11:42, Michal Orzel wrote:
According to ARMv8A architecture, AArch64 registers
flight 164676 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164676/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs.
162548
test-amd64-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2021-28698 / XSA-380
version 3
long running loops in grant table handling
UPDATES IN VERSION 3
New bugfix patch on top of the prior set.
ISSUE
On 31.08.2021 09:30, Juergen Gross wrote:
> In order to get Mini-OS master branch tested by OSStest, use it for
> xen-unstable.
>
> Signed-off-by: Juergen Gross
> ---
> There are some Mini-OS patches pending, of which at least the Mini-OS
> netfront fix should be committed as it will be required
AKASHI Takahiro writes:
> Hi François,
>
> On Thu, Aug 12, 2021 at 09:55:52AM +0200, Fran??ois Ozog wrote:
>> I top post as I find it difficult to identify where to make the comments.
>
> Thank you for the posting.
> I think that we should first discuss more about the goal/requirements/
> prac
Hi Penny,
On 24/08/2021 10:50, Penny Zheng wrote:
A few functions iterate over the device tree property to get memory info,
like "reg" or the later "xen,static-mem", so this commit creates a new helper
device_tree_get_meminfo to extract the common codes.
The commit message needs to be updated
1 - 100 of 108 matches
Mail list logo
