On 16.09.2021 03:16, Stefano Stabellini wrote:
> On Wed, 15 Sep 2021, Luca Fancellu wrote:
>> +static void __init handle_dom0less_domain_node(EFI_FILE_HANDLE dir_handle,
>> + int domain_node,
>> + int addr_c
flight 165001 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165001/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c19d18136ef920e3e84f961e2a335a41147adcb8
baseline version:
ovmf 3b69fcf5f849021aa3bc8
On 16.09.2021 02:16, Stefano Stabellini wrote:
> So I am thinking that we have no choice but introducing a new property
> to tell us whether we should or should not load xen.cfg when
> multiboot,modules are present.
>
> Taking inspiration from HyperLaunch, it could be a new node:
>
> chosen {
>
On 16.09.2021 00:13, Oleksandr wrote:
> On 15.09.21 13:06, Jan Beulich wrote:
>> On 14.09.2021 22:44, Oleksandr Tyshchenko wrote:
>>> --- a/xen/include/asm-arm/mm.h
>>> +++ b/xen/include/asm-arm/mm.h
>>> @@ -98,9 +98,18 @@ struct page_info
>>> #define PGT_writable_page PG_mask(1, 1) /* has writa
On 15.09.2021 20:12, Stefano Stabellini wrote:
> On Wed, 15 Sep 2021, Jan Beulich wrote:
>> On 10.09.2021 18:23, Stefano Stabellini wrote:
>>> On Fri, 10 Sep 2021, Jan Beulich wrote:
On 10.09.2021 04:52, Penny Zheng wrote:
> In order to deal with the trouble of count-to-order conversion wh
Sanitize CTR_EL0 value between cores and taint Xen if incompatible
values are found.
In the case of different i-cache types, the sanitize ctr_el0 will have a
sanitize value but this is currently not used or exposed to guest which
are seeing the original ctr_el0 value.
Use the opportunity to renam
Use arm64 cpu feature sanitization to TAINT Xen if different DCZID values
are found (ftr_dczid is using only STRICT method).
In this case actual memory being cleaned by DC ZVA operations would be
different depending on the cores which could make a guest zeroing too
much or too little memory if it i
Replace the code in p2m trying to find a sane value for the VMID size
supported and the PAR to use. We are now using the boot cpuinfo as the
values there are sanitized during boot and the value for those
parameters is now the safest possible value on the system.
Signed-off-by: Bertrand Marquis
Re
As we will sanitize the content of boot_cpu_data it will not really
contain the boot cpu information but the system sanitize information.
Rename the structure to system_cpuinfo so the user is informed that this
is the system wide available feature and not anymore the features of the
boot cpu.
The o
Define a sanitize_cpu function to be called on secondary cores to
sanitize the system cpuinfo structure.
The safest value is taken when possible and the system is marked tainted
if we encounter values which are incompatible with each other.
Call the update_system_features function on all secondar
Import structures declared in Linux file arch/arm64/kernel/cpufeature.c
and the required types from arch/arm64/include/asm/cpufeature.h.
Current code has been imported from Linux 5.13-rc5 (Commit ID
cd1245d75ce93b8fd206f4b34eb58bcfe156d5e9) and copied into cpufeature.c
in arm64 code and cpufeature
Import some ID registers definitions from Linux sysreg header to have
required shift definitions for all ID registers fields.
Those are required to reuse the cpufeature sanitization system from
Linux kernel.
Signed-off-by: Bertrand Marquis
Acked-by: Julien Grall
---
Changes in v4: Add acked-by
On arm architecture we might have heterogeneous platforms with different
types of cores. As a guest can potentialy run on any of those cores we
have to present them cpu features which are compatible with all cores
and discard the features which are only available on some cores.
As the features can
flight 164996 xen-unstable real [real]
flight 165002 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164996/
http://logs.test-lab.xenproject.org/osstest/logs/165002/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
flight 164997 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164997/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 152332
test-arm64-arm64-li
Hi Jan
Sorry for the broken.
> -Original Message-
> From: Jan Beulich
> Sent: Wednesday, September 15, 2021 9:56 PM
> To: Penny Zheng
> Cc: Bertrand Marquis ; Wei Chen
> ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org; jul...@xen.org
> Subject: Re: [PATCH v7 3/7] xen: introdu
On Wed, 15 Sep 2021, Trilok Soni wrote:
> On 9/14/2021 8:29 PM, Stefano Stabellini wrote:
> > On Tue, 14 Sep 2021, Trilok Soni wrote:
> > > On 9/13/2021 4:51 PM, Stefano Stabellini via Stratos-dev wrote:
> > > > On Mon, 6 Sep 2021, AKASHI Takahiro wrote:
> > > > > > the second is how many context s
On Wed, 15 Sep 2021, Luca Fancellu wrote:
> This patch introduces the support for dom0less configuration
> when using UEFI boot on ARM, it permits the EFI boot to
> continue if no dom0 kernel is specified but at least one domU
> is found.
>
> Introduce the new property "uefi,binary" for device tre
Adding Jan for an opinion on the EFI common code changes. See below.
On Wed, 15 Sep 2021, Luca Fancellu wrote:
> When Xen is started as EFI application, it is checking
> the presence of multiboot,module in the DT, if any is
> found, the configuration file is skipped.
> Restrict this check to just
Hi Stefano,
On 9/14/2021 8:29 PM, Stefano Stabellini wrote:
On Tue, 14 Sep 2021, Trilok Soni wrote:
On 9/13/2021 4:51 PM, Stefano Stabellini via Stratos-dev wrote:
On Mon, 6 Sep 2021, AKASHI Takahiro wrote:
the second is how many context switches are involved in a transaction.
Of course with
On 15.09.21 13:06, Jan Beulich wrote:
Hi Jan
On 14.09.2021 22:44, Oleksandr Tyshchenko wrote:
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1376,14 +1376,18 @@ unsigned long domain_get_maximum_gpfn(struct domain *d)
void share_xen_page_with_guest(struct page_info *page, struct domain
I checked only the cases "dom0_mem=101376M" and "dom0_mem=-24832M,max:-24832M".In both cases, the regex worked correctly. Simultaneous restoration of several (1-15) virtual machines from snapshots also works stably in our production (on xen 4.14). 14.09.2021, 14:08, "Ian Jackson" :Dmitry Isaikin wr
flight 164993 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164993/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 164960
test-amd64-i386-xl-qemut-win7-amd64 19
On Wed, 15 Sep 2021, Oleksandr wrote:
> > On Fri, 10 Sep 2021, Oleksandr Tyshchenko wrote:
> > > From: Oleksandr Tyshchenko
> > >
> > > 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 mapping
On Wed, 15 Sep 2021, Rahul Singh wrote:
> > On 15 Sep 2021, at 12:06 am, Stefano Stabellini
> > wrote:
> > On Tue, 14 Sep 2021, Rahul Singh wrote:
> +return NULL;
> +
> +busn -= cfg->busn_start;
> +base = cfg->win + (busn << cfg->ops->bus_shift);
> +
> >>>
On Wed, 15 Sep 2021, Rahul Singh wrote:
> Hi Oleksandr, Stefano,
>
> > On 15 Sep 2021, at 6:30 am, Oleksandr Andrushchenko
> > wrote:
> >
> > Hi, Rahul!
> >
> > On 14.09.21 17:24, Oleksandr Andrushchenko wrote:
> >>
> >> }
> +static int pci_ecam_register_mmio_handler(struct domain *d,
flight 164992 qemu-mainline real [real]
flight 164999 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164992/
http://logs.test-lab.xenproject.org/osstest/logs/164999/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Wed, 15 Sep 2021, Stefano Stabellini wrote:
> On Wed, 15 Sep 2021, Oleksandr Andrushchenko wrote:
> > On 15.09.21 03:36, Stefano Stabellini wrote:
> > > On Tue, 14 Sep 2021, Oleksandr Andrushchenko wrote:
> > >> With the patch above I have the following log in Domain-0:
> > >>
> > >> generic-arm
On Wed, 15 Sep 2021, Oleksandr Andrushchenko wrote:
> On 15.09.21 03:36, Stefano Stabellini wrote:
> > On Tue, 14 Sep 2021, Oleksandr Andrushchenko wrote:
> >> With the patch above I have the following log in Domain-0:
> >>
> >> generic-armv8-xt-dom0 login: root
> >> root@generic-armv8-xt-dom0:~# (
On 14.09.21 03:55, Stefano Stabellini wrote:
Hi Stefano
On Fri, 10 Sep 2021, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
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
On Wed, 15 Sep 2021, Jan Beulich wrote:
> On 10.09.2021 18:23, Stefano Stabellini wrote:
> > On Fri, 10 Sep 2021, Jan Beulich wrote:
> >> On 10.09.2021 04: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-t
flight 164998 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164998/
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
> -Original Message-
> From: Michael Kelley
> Sent: Wednesday, September 15, 2021 12:22 PM
> To: Tianyu Lan ; KY Srinivasan ;
> > + memset(vmap_pages, 0,
> > + sizeof(*vmap_pages) * vmap_page_index);
> > +
Hi Oleksandr,
> On 15 Sep 2021, at 6:35 am, Oleksandr Andrushchenko
> wrote:
>
> Hi, Stefano, Rahul!
>
> On 15.09.21 03:36, Stefano Stabellini wrote:
>> On Tue, 14 Sep 2021, Oleksandr Andrushchenko wrote:
>>> With the patch above I have the following log in Domain-0:
>>>
>>> generic-armv8-xt-
Hi Stefano,
> On 15 Sep 2021, at 12:06 am, Stefano Stabellini
> wrote:
>
> On Tue, 14 Sep 2021, Rahul Singh wrote:
+return NULL;
+
+busn -= cfg->busn_start;
+base = cfg->win + (busn << cfg->ops->bus_shift);
+
+return base + (PCI_DEVFN(sbdf_t.dev
From: Tianyu Lan Sent: Tuesday, September 14, 2021 6:39
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 nee
From: Tianyu Lan Sent: Tuesday, September 14, 2021 6:39 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
> storvsc rx/tx ring buffer. The page buffer used by vmbus_sendpacket_
> mpb_desc() still needs t
From: Tianyu Lan Sent: Tuesday, September 14, 2021 6:39 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
From: Tianyu Lan Sent: Tuesday, September 14, 2021 6:39 AM
>
> In Isolation VM with AMD SEV, bounce buffer needs to be accessed via
> extra address space which is above shared_gpa_boundary
> (E.G 39 bit address line) reported by Hyper-V CPUID ISOLATION_CONFIG.
> The access physical address will b
From: Tianyu Lan Sent: Tuesday, September 14, 2021 6:39 AM
>
> 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 AMD SEV SNP, the access
> address should be in the
From: Tianyu Lan Sent: Tuesday, September 14, 2021 6:39 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. Fi
From: Tianyu Lan Sent: Tuesday, September 14, 2021 6:39 AM
>
> Mark vmbus ring buffer visible with set_memory_decrypted() when
> establish gpadl handle.
>
> Signed-off-by: Tianyu Lan
> ---
> Change sincv v4
> * Change gpadl handle in netvsc and uio driver from u32 to
> struct vmbu
> On 8 Sep 2021, at 14:04, Juergen Gross wrote:
>
> In case a domain is created with a cpupool other than Pool-0 specified
> it will be moved to that cpupool before any vcpus are allocated.
>
> This will lead to a NULL pointer dereference in sched_move_domain().
>
> Fix that by tolerating vc
Re,
Juergen Gross, le mer. 15 sept. 2021 16:08:15 +0200, a ecrit:
> +while (off != len)
> +{
> +wait_event(xb_waitq, xenstore_buf->rsp_prod !=
> xenstore_buf->rsp_cons);
> +
> +prod = xenstore_buf->rsp_prod;
> +cons = xenstore_buf->rsp_cons;
> +DEBUG("Rsp_c
The memory allocator currently calculates alignment in libxl's virtual
address space, rather than guest physical address space. This results
in the FACS being commonly misaligned.
Furthermore, the allocator has several other bugs.
The opencoded align-up calculation is currently susceptible to a b
This patch introduces the support for dom0less configuration
when using UEFI boot on ARM, it permits the EFI boot to
continue if no dom0 kernel is specified but at least one domU
is found.
Introduce the new property "uefi,binary" for device tree boot
module nodes that are subnode of "xen,domain" c
When Xen is started as EFI application, it is checking
the presence of multiboot,module in the DT, if any is
found, the configuration file is skipped.
Restrict this check to just any multiboot,module that
is a direct child of the /chosen node.
Signed-off-by: Luca Fancellu
---
xen/arch/arm/efi/ef
This serie introduces a way to start a dom0less setup when Xen is booting as EFI
application.
Using the device tree it's now possible to fetch from the disk and load in
memory all the modules needed to start any domU defined in the DT.
Dom0less for now is supported only by the arm architecture.
Lu
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 by allowing to transfer the xenbus message
On 10.09.2021 04:52, Penny Zheng wrote:
> 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
On Wed, Sep 15, 2021 at 03:49:52PM +0200, Jan Beulich wrote:
> But the question remains: Why does the framebuffer need to be mapped
> in a single giant chunk?
More importantly: if you use dynamic dma mappings for your framebuffer
you're doing something wrong.
On 15.09.2021 15:37, Roman Skakun wrote:
>>> From: Roman Skakun
>>>
>>> It is possible when default IO TLB size is not
>>> enough to fit a long buffers as described here [1].
>>>
>>> This patch makes a way to set this parameter
>>> using cmdline instead of recompiling a kernel.
>>>
>>> [1] https:/
Hi Jan,
Thanks for the answer.
>> From: Roman Skakun
>>
>> It is possible when default IO TLB size is not
>> enough to fit a long buffers as described here [1].
>>
>> This patch makes a way to set this parameter
>> using cmdline instead of recompiling a kernel.
>>
>> [1] https://www.xilinx.com/s
There's no point going through %ax; the addition can be done directly in
%di.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/boot/mem.S
+++ b/xen/arch/x86/boot/mem.S
@@ -24,9 +24,7 @@ get_memory_map:
cmpw$E820_BIOS_MAX, bootsym(bios_e820nr) # up to this many entries
Replace (mainly) MOV forms with shorter insns (or sequences thereof).
Signed-off-by: Jan Beulich
---
Of course there's more room for improvement. For example there look to
be a number of LEAs which really could be MOVs.
--- a/xen/arch/x86/boot/video.S
+++ b/xen/arch/x86/boot/video.S
@@ -121,8 +1
Using Jcc to branch around a JMP is necessary only in pre-386 code,
where Jcc is limited to disp8. Use the opposite Jcc directly in two
places. Since it's adjacent, also convert an ORB to TESTB.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/boot/video.S
+++ b/xen/arch/x86/boot/video.S
@@ -332,8
There's no point in writing 80x25 text mode information via multiple
insns all storing immediate values. The data can simply be included
first thing in the vga_modes table, allowing the already present
REP MOVSB to take care of everything in one go.
While touching this also correct a related but s
When booting directly from EFI, obtaining this information from EFI is
the only possible way. And even when booting with a boot loader
interposed, it's more clean not to use legacy BIOS calls for this
purpose. (The downside being that there are no "capabilities" that we
can retrieve the EFI way.)
With MB2 the boot loader may provide this information, allowing us to
obtain it without needing to enter real mode (assuming we don't need to
set a new mode from "vga=", but can instead inherit the one the
bootloader may have established).
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x
GrUB2 can be told to leave the screen in the graphics mode it has been
using (or any other one), via "set gfxpayload=keep" (or suitable
variants thereof). In this case we can avoid doing another mode switch
ourselves. This in particular avoids possibly setting the screen to a
less desirable mode: O
1: make "vga=current" work with graphics modes
2: obtain video info from boot loader
3: EFI: retrieve EDID
4: simplify mode_table
5: fold branches in video handling code
6: fold/replace moves in video handling code
7: fold two MOVs into an ADD
Jan
flight 164995 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164995/
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
flight 164988 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164988/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 152332
test-arm64-arm64-xl
Kevin,
On 24.08.2021 16:27, Jan Beulich wrote:
> map_domain_page() et al never fail; no need to check their return values
> against NULL, and no need to carry dead printk()s.
>
> Signed-off-by: Jan Beulich
may I get an ack (or otherwise) on this patch please? Ideally also
for some other VT-d sp
Juergen Gross, le mer. 15 sept. 2021 14:03:35 +0200, a ecrit:
> On 15.09.21 13:20, Samuel Thibault wrote:
> > So we really need to make the test after the rsp_cons update, like Linux
> > does:
> >
> > > > Linux' code uses (intf->rsp_prod - cons >= XENSTORE_RING_SIZE), *after*
> > > > the rsp_cons
On 15.09.21 13:20, Samuel Thibault wrote:
Juergen Gross, le mer. 15 sept. 2021 12:48:44 +0200, a ecrit:
On 15.09.21 01:17, Samuel Thibault wrote:
+prod = xenstore_buf->rsp_prod;
+DEBUG("Rsp_cons %d, rsp_prod %d.\n", xenstore_buf->rsp_cons, prod);
+size = min(len - off, p
On 15.09.21 13:45, Rahul Singh wrote:
> Hi Oleksandr, Stefano,
>
>> On 15 Sep 2021, at 6:30 am, Oleksandr Andrushchenko
>> wrote:
>>
>> Hi, Rahul!
>>
>> On 14.09.21 17:24, Oleksandr Andrushchenko wrote:
>>> }
>+static int pci_ecam_register_mmio_handler(struct domain *d,
> +
flight 164987 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164987/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-raw 17 guest-start/debian.repeat fail REGR. vs. 164945
Tests which are f
Juergen Gross, le mer. 15 sept. 2021 12:48:44 +0200, a ecrit:
> On 15.09.21 01:17, Samuel Thibault wrote:
> > > +prod = xenstore_buf->rsp_prod;
> > > +DEBUG("Rsp_cons %d, rsp_prod %d.\n", xenstore_buf->rsp_cons,
> > > prod);
> > > +size = min(len - off, prod - xenstore_buf-
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 by allowing to transfer the xenbus message
On 15/09/2021 10:30, Jan Beulich wrote:
> On 14.09.2021 18:43, Kevin Stefanov wrote:
>> --- a/tools/libs/light/libxl_x86_acpi.c
>> +++ b/tools/libs/light/libxl_x86_acpi.c
>> @@ -20,6 +20,7 @@
>>
>> /* Number of pages holding ACPI tables */
>> #define NUM_ACPI_PAGES 16
>> +#define ALIGN(p, a) (
You forgot to Cc Mike, lemme add him.
And drop stable@ too.
On Tue, Sep 14, 2021 at 01:06:22PM +0200, Juergen Gross wrote:
> On 14.09.21 12:03, Jan Beulich wrote:
> > On 14.09.2021 11:41, Juergen Gross wrote:
> > > Commit a799c2bd29d19c565 ("x86/setup: Consolidate early memory
> > > reservations"
On 15.09.21 01:17, Samuel Thibault wrote:
Hello,
Thanks for having worked on this!
Juergen Gross, le mer. 18 août 2021 17:26:10 +0200, a ecrit:
+static void xenbus_read_data(char *buf, unsigned int len)
+{
+unsigned int off = 0;
+unsigned int prod;
+unsigned int size;
+int noti
Hi Oleksandr,
> On 15 Sep 2021, at 8:54 am, Oleksandr Andrushchenko
> wrote:
>
> Hi, Rahul!
static void pci_config_write(pci_sbdf_t sbdf, unsigned int reg,
unsigned int len, uint32_t val)
{
+struct pci_host_bridge *bridge = pci_find_host_brid
Hi Oleksandr, Stefano,
> On 15 Sep 2021, at 6:30 am, Oleksandr Andrushchenko
> wrote:
>
> Hi, Rahul!
>
> On 14.09.21 17:24, Oleksandr Andrushchenko wrote:
>>
>> }
+static int pci_ecam_register_mmio_handler(struct domain *d,
+ struct pci_hos
flight 164990 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164990/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
On 14.09.2021 22:44, Oleksandr Tyshchenko wrote:
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1376,14 +1376,18 @@ unsigned long domain_get_maximum_gpfn(struct domain
> *d)
> void share_xen_page_with_guest(struct page_info *page, struct domain *d,
> enu
flight 164994 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164994/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 487975df53b5298316b594550c79934d646701bd
baseline version:
xen 6d45
Hi Anthony,
On 24.08.2021 12:49, Anthony PERARD wrote:
> Patch series available in this git branch:
> https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
> br.build-system-xen-v7
>
> v7:
> Out-of-tree build!
>
> This mean many more patches. Everything after patch 27 is new.
On 15.09.2021 10:44, Roger Pau Monné wrote:
> On Wed, Sep 15, 2021 at 10:16:41AM +0200, Jan Beulich wrote:
>> On 15.09.2021 10:03, Roger Pau Monne wrote:
>>> If the new gfn matches the previous one (ie: gpfn == old_gpfn)
>>> xenmem_add_to_physmap_one will issue a duplicated call to
>>> guest_physma
On 14.09.2021 18:43, Kevin Stefanov wrote:
> --- a/tools/libs/light/libxl_x86_acpi.c
> +++ b/tools/libs/light/libxl_x86_acpi.c
> @@ -20,6 +20,7 @@
>
> /* Number of pages holding ACPI tables */
> #define NUM_ACPI_PAGES 16
> +#define ALIGN(p, a) (((p) + ((a) - 1)) & ~((a) - 1))
Wouldn't this be
Hidden devices are associated with DomXEN but usable by the
hardware domain. Hence they need flushing as well when all devices are
to have flushes invoked.
While there drop a redundant ATS-enabled check and constify the first
parameter of the involved function.
Signed-off-by: Jan Beulich
--- a/
Doing the cleanup also for phantom devices is at best redundant with
doing it for the corresponding real device. I couldn't force myself into
checking all the code paths whether it really is: It seems better to
explicitly skip this step in such cases.
Signed-off-by: Jan Beulich
--- a/xen/drivers
Whether to clear an IOMMU's bit in the domain's bitmap should depend on
all devices the domain can control. For the hardware domain this
includes hidden devices, which are associated with DomXEN.
While touching related logic, convert "found" to "bool".
Signed-off-by: Jan Beulich
--- a/xen/drive
If devices are to be skipped anyway (which is the case in particular for
host bridges), there's no point complaining about a missing DRHD (and
hence a missing association with an IOMMU).
While there convert assignments to initializers and constify "drhd"
local variables.
Signed-off-by: Jan Beulic
While making the first change here it occurred to me that the recent
vPCI-related discussion about hidden devices has some relevance also
elsewhere. In the course I then came to also notice a phantom device
related quirk.
1: VT-d: defer "no DRHD" check when (un)mapping devices
2: VT-d: consider hi
While making the first change here it occurred to me that the recent
vPCI-related discussion about hidden devices has some relevance also
elsewhere. In the course I then came to also notice a phantom device
related quirk.
1: VT-d: defer "no DRHD" check when (un)mapping devices
2: VT-d: consider hi
On 15.09.2021 10:21, Roger Pau Monne wrote:
> LLVM ld seems to require section names to be quoted at both definition
> and when referencing them for a match to happen, or else we get the
> following errors:
>
> ld: error: xen.lds:45: undefined section ".text"
> ld: error: xen.lds:69: undefined sec
On Wed, Sep 15, 2021 at 10:16:41AM +0200, Jan Beulich wrote:
> On 15.09.2021 10:03, Roger Pau Monne wrote:
> > If the new gfn matches the previous one (ie: gpfn == old_gpfn)
> > xenmem_add_to_physmap_one will issue a duplicated call to
> > guest_physmap_remove_page with the same guest frame number,
On 14.09.2021 18:27, Roger Pau Monné wrote:
> On Tue, Sep 14, 2021 at 05:13:52PM +0200, Jan Beulich wrote:
>> On 14.09.2021 14:41, Roger Pau Monné wrote:
>>> On Tue, Sep 14, 2021 at 01:58:29PM +0200, Jan Beulich wrote:
On 14.09.2021 13:15, Roger Pau Monné wrote:
> On Tue, Sep 14, 2021 at 1
On 15.09.2021 03:54, Stefano Stabellini wrote:
> On Tue, 14 Sep 2021, Stefano Stabellini wrote:
>> On Tue, 14 Sep 2021, Jan Beulich wrote:
>>> On 13.09.2021 22:31, Stefano Stabellini wrote:
On Mon, 13 Sep 2021, Jan Beulich wrote:
> On 11.09.2021 01:14, Stefano Stabellini wrote:
>> On T
LLVM ld seems to require section names to be quoted at both definition
and when referencing them for a match to happen, or else we get the
following errors:
ld: error: xen.lds:45: undefined section ".text"
ld: error: xen.lds:69: undefined section ".rodata"
ld: error: xen.lds:104: undefined section
On 15.09.2021 10:03, Roger Pau Monne wrote:
> If the new gfn matches the previous one (ie: gpfn == old_gpfn)
> xenmem_add_to_physmap_one will issue a duplicated call to
> guest_physmap_remove_page with the same guest frame number, because
> the get_gpfn_from_mfn call has been moved by commit f8582d
Hello,
On 9/13/2021 4:51 PM, Stefano Stabellini via Stratos-dev wrote:
On Mon, 6 Sep 2021, AKASHI Takahiro wrote:
the second is how many context switches are involved in a transaction.
Of course with all things there is a trade off. Things involving the
very tightest latency would probably op
If the new gfn matches the previous one (ie: gpfn == old_gpfn)
xenmem_add_to_physmap_one will issue a duplicated call to
guest_physmap_remove_page with the same guest frame number, because
the get_gpfn_from_mfn call has been moved by commit f8582da041 to be
performed before the original page is rem
On 10.09.2021 18:23, Stefano Stabellini wrote:
> On Fri, 10 Sep 2021, Jan Beulich wrote:
>> On 10.09.2021 04: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
flight 164985 qemu-mainline real [real]
flight 164991 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164985/
http://logs.test-lab.xenproject.org/osstest/logs/164991/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
Hi, Rahul!
>>> static void pci_config_write(pci_sbdf_t sbdf, unsigned int reg,
>>> unsigned int len, uint32_t val)
>>> {
>>> +struct pci_host_bridge *bridge = pci_find_host_bridge(sbdf.seg,
>>> sbdf.bus);
>>> +
>>> +if ( unlikely(!bridge) )
>>> +{
>>> +
On Tue, Sep 14, 2021 at 04:32:53PM +0200, Jan Beulich wrote:
> On 14.09.2021 15:34, Roger Pau Monne wrote:
> > If the new gfn matches the previous one (ie: gfn == old_gpfn)
>
> It took me a while to realize that you probably mean "gpfn" here.
Indeed. The variable names could probably do with some
99 matches
Mail list logo
