>>> On 06.06.19 at 09:15, wrote:
On 05.06.19 at 20:02, wrote:
> > Jan Beulich writes ("Re: [Xen-devel] [xen-4.7-testing test] 137065:
> > regressions
> -
> > FAIL"):
> >> The one you've picked looks to be a "fail never pass" one, so is perhaps
> >> not ideal. I've looked at a couple other
1: guard top-of-stack reads
2: widen condition for logging top-of-stack
The issue patch 2 fixes (a curious lack of an intermediate call stack
entry) was observed in practice; patch 1 is a result of me just looking
at the code.
Jan
___
Xen-devel maili
Nothing (afaics) guarantees that the original frame's stack pointer
points at readable memory. Avoid a (likely nested) crash by attaching
exception recovery to the read (making it a single read at the same
time). Don't even invoke _show_trace() in case of a non-readable top
slot.
Signed-off-by: Ja
Hi Jan,
On 6/17/19 7:40 AM, Jan Beulich wrote:
On 14.06.19 at 18:52, wrote:
The title and commit message are a bit odd to read because you are modifying
common code but everything is geared towards x86.
Indeed. There's no caller of {en,dis}able_nonboot_cpus() in Arm code
at present, afaics.
Despite -fno-omit-frame-pointer the compiler may omit the frame pointer,
often for relatively simple leaf functions. (To give a specific example,
the case I've run into this with is _pci_hide_device() and gcc 8.
Interestingly the even more simple neighboring iommu_has_feature() does
get a frame poi
>>> On 27.05.19 at 11:28, wrote:
On 02.04.19 at 15:04, wrote:
> > In x2APIC mode it is 32 bits wide.
> >
> > In __print_IO_APIC() drop logging of both physical and logical IDs:
> > The latter covers a superset of the bits of the former in the RTE, and
> > we write full 8-bit values anyway e
On Thu, Jun 13, 2019 at 05:00:57PM -0400, Konrad Rzeszutek Wilk wrote:
> > As Christoph didn't react when I posted possible solutions I think I'll
> > just modify patch 3 according to Jan's comment and post V3.
>
> OK, will await that patchset. Thank you!
>
> BTW, your patch #1 should be upstream
Currently, the time_ref_count enlightened time source maintains an offset
such that time is frozen when the domain paused, but the reference_tsc
enlightened time source does not. After migrate, the reference_tsc source
may become invalidated (e.g. because of host cpu frequency mismatch) which
will
flight 137847 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137847/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs.
127792
test-am
On 09.05.19 19:25, Ankur Arora wrote:
Xen ballooning uses hollow struct pages (with the underlying GFNs being
populated/unpopulated via hypercalls) which are used by the grant logic
to map grants from other domains.
This patch allows the default xenhost to provide an alternate ballooning
allocat
On 09.05.19 19:25, Ankur Arora wrote:
Largely mechanical changes: the exported grant table symbols now take
xenhost_t * as a parameter. Also, move the grant table global state
inside xenhost_t.
If there's more than one xenhost, then initialize both.
Signed-off-by: Ankur Arora
---
arch/x86/xe
On 09.05.19 19:25, Ankur Arora wrote:
As part of xenbus init, both frontend, backend interfaces need to talk
on the correct xenbus. This might be a local xenstore (backend) or might
be a XS_PV/XS_HVM interface (frontend) which needs to talk over xenbus
with the remote xenstored. We bootstrap all
>>> On 07.06.19 at 11:22, wrote:
> --- a/xen/drivers/acpi/reboot.c
> +++ b/xen/drivers/acpi/reboot.c
> @@ -23,9 +23,9 @@ void acpi_reboot(void)
> case ACPI_ADR_SPACE_PCI_CONFIG:
> printk("Resetting with ACPI PCI RESET_REG.\n");
> /* Write the value that resets us.
>>> On 07.06.19 at 11:22, wrote:
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -707,11 +707,11 @@ static void init_amd(struct cpuinfo_x86 *c)
> (h & 0x1) ? "clearing D18F3x5C[0]" : "");
>
> if (l & 0x1f)
> -
On 09.05.19 19:25, Ankur Arora wrote:
Mechanical changes, now most of these calls take xenhost_t *
as parameter.
Co-developed-by: Joao Martins
Signed-off-by: Ankur Arora
---
drivers/xen/cpu_hotplug.c | 14 ++---
drivers/xen/gntalloc.c| 13
drivers/xen/gntde
On 09.05.19 19:25, Ankur Arora wrote:
For the most part, we now pass xenhost_t * as a parameter.
Co-developed-by: Joao Martins
Signed-off-by: Ankur Arora
I don't see how this can be a patch on its own.
The only way to be able to use a patch for each driver would be to
keep the original gran
On 09.05.19 19:25, Ankur Arora wrote:
For the most part, we now pass xenhost_t * as parameter.
Co-developed-by: Joao Martins
Signed-off-by: Ankur Arora
Same as previous patch.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
htt
When passthrough a PLX PCI9056 PCI to IOBus bridge,
hvmloader will crashed for it disallow init bridge class pci device
except intel PIIX4 ACPI PM.
Signed-off-by: Beyond Lee
diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index 0b708bf..33aadc7 1006
>>> On 07.06.19 at 11:22, wrote:
> This reduces the number of parameters of the function to two, and
> simplifies some of the calling sites.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenp
>>> On 17.06.19 at 12:16, wrote:
> When passthrough a PLX PCI9056 PCI to IOBus bridge,
> hvmloader will crashed for it disallow init bridge class pci device
> except intel PIIX4 ACPI PM.
Right now the conceptual model implies that bridges aren't supposed
to be passed through in the first
On 6/13/19 11:56 AM, Alexandru Stefan ISAILA wrote:
>
>
> On 26.09.2018 19:47, George Dunlap wrote:
>> From: Isaila Alexandru
>>
>> This patch adds access control for NPT mode.
>>
>> There aren’t enough extra bits to store the access rights in the NPT p2m
>> table, so we add a radix tree to stor
On 09.05.19 19:25, Ankur Arora wrote:
Xenhost type xenhost_r0 does not support standard GNTTABOP_map_grant_ref
semantics (map a gref onto a specified host_addr). That's because
since the hypervisor is local (same address space as the caller of
GNTTABOP_map_grant_ref), there is no external entity
On 17/06/2019 11:48, George Dunlap wrote:
> On 6/13/19 11:56 AM, Alexandru Stefan ISAILA wrote:
>>
>> On 26.09.2018 19:47, George Dunlap wrote:
>>> From: Isaila Alexandru
>>>
>>> This patch adds access control for NPT mode.
>>>
>>> There aren’t enough extra bits to store the access rights in the N
On Thu, May 16, 2019 at 11:38 PM Tamas K Lengyel wrote:
>
> Calling _put_page_type while also holding the page_lock
> for that page can cause a deadlock.
>
> The comment being dropped is incorrect since it's now out-of-date.
>
> Signed-off-by: Tamas K Lengyel
Patch ping. Unclear whose Ack is str
flight 137848 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137848/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 133596
build-amd64-pre
VMExit doesn't switch all state. The FS/GS/TS/LDTR/GSBASE segment
information, and SYSCALL/SYSENTER MSRs may still be cached in hardware, rather
than up-to-date in the VMCB.
Export svm_sync_vmcb() via svmdebug.h so svm_vmcb_dump() can use it, and bring
the VMCB into sync in current context.
As a
On Thu, May 16, 2019 at 11:38 PM Tamas K Lengyel wrote:
>
> Disable it by default as it is only an experimental subsystem.
>
> Signed-off-by: Tamas K Lengyel
Patch ping, are any more ack's missing on this one? Current tally is:
Acked-by: Razvan Cojocaru
Acked-by: Jan Beulich
Acked-by: Daniel
Jan Beulich writes ("Re: [xen-4.8-testing test] 136566: regressions - FAIL"):
> Am I mistaken in understanding that these two will go away only once
> the 4.7 tree gets a push (which, even when its own build failures have
> got addressed, will require a 4.6 push to occur first), and in turn the
> r
On architectures that have a larger dma_addr_t than phys_addr_t,
the swiotlb_tbl_map_single() function truncates its return code
in the failure path, making it impossible to identify the error
later, as we compare to the original value:
kernel/dma/swiotlb.c:551:9: error: implicit conversion from '
>>> On 17.06.19 at 14:23, wrote:
> On Thu, May 16, 2019 at 11:38 PM Tamas K Lengyel wrote:
>>
>> Calling _put_page_type while also holding the page_lock
>> for that page can cause a deadlock.
>>
>> The comment being dropped is incorrect since it's now out-of-date.
>>
>> Signed-off-by: Tamas K Len
>>> On 17.06.19 at 14:54, wrote:
> VMExit doesn't switch all state. The FS/GS/TS/LDTR/GSBASE segment
> information, and SYSCALL/SYSENTER MSRs may still be cached in hardware, rather
> than up-to-date in the VMCB.
>
> Export svm_sync_vmcb() via svmdebug.h so svm_vmcb_dump() can use it, and bring
On 17/06/2019 14:55, Jan Beulich wrote:
On 17.06.19 at 14:54, wrote:
>> VMExit doesn't switch all state. The FS/GS/TS/LDTR/GSBASE segment
>> information, and SYSCALL/SYSENTER MSRs may still be cached in hardware,
>> rather
>> than up-to-date in the VMCB.
>>
>> Export svm_sync_vmcb() via svm
>>> On 31.05.19 at 12:33, wrote:
> osstest service owner writes ("[xen-4.6-testing test] 137064: regressions -
> FAIL"):
>> flight 137064 xen-4.6-testing real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/137064/
>>
>> Regressions :-(
>
> This is all pretty bad but I think it is m
Jan Beulich writes ("Re: [xen-4.6-testing test] 137064: regressions - FAIL"):
> Fundamentally I don't care overly much about this old tree, but
> I can't figure how you came to the "mostly new tests in XTF"
> conclusion. In fact ...
Hmmm. I think you are right and I misread the report.
> ... the
flight 137849 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137849/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 132889
test-amd64-amd6
On 02/04/2019 14:04, Jan Beulich wrote:
> In x2APIC mode it is 32 bits wide.
>
> In __print_IO_APIC() drop logging of both physical and logical IDs:
> The latter covers a superset of the bits of the former in the RTE, and
> we write full 8-bit values anyway even in physical mode for all ordinary
>
>>> On 07.06.19 at 11:22, wrote:
> The new format specifier is '%pp', and prints a pci_sbdf_t using the
> seg:bus:dev.func format. Replace all SBDFs printed using
> '%04x:%02x:%02x.%u' to use the new format specifier.
Well, I continue to not be happy about the use of %p (rather than the
proposed
On 17/06/2019 16:10, Jan Beulich wrote:
On 07.06.19 at 11:22, wrote:
>> The new format specifier is '%pp', and prints a pci_sbdf_t using the
>> seg:bus:dev.func format. Replace all SBDFs printed using
>> '%04x:%02x:%02x.%u' to use the new format specifier.
> Well, I continue to not be happy a
>>> On 31.05.19 at 05:18, wrote:
> Thus, sizeof(struct cpupool) will save 8 bytes for 64-bit system.
>
> Signed-off-by: Baodong Chen
> ---
> xen/include/xen/sched-if.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
I've just noticed that this file isn't part of the SCHEDULING
maintain
On 17.06.19 17:19, Jan Beulich wrote:
On 31.05.19 at 05:18, wrote:
Thus, sizeof(struct cpupool) will save 8 bytes for 64-bit system.
Signed-off-by: Baodong Chen
---
xen/include/xen/sched-if.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
I've just noticed that this file isn't par
hmm, I forgot to CC lars. Sorry for that.
Cheers,
On 15/06/2019 19:39, Julien Grall wrote:
(+ Lars)
Hi,
On 6/11/19 7:46 PM, Volodymyr Babchuk wrote:
diff --git a/xen/include/asm-arm/tee/optee_msg.h
b/xen/include/asm-arm/tee/optee_msg.h
new file mode 100644
index 00..fe743dbde3
--- /
Hi Jan,
On 14/06/2019 16:38, Jan Beulich wrote:
this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
--- a/xen/common/rcupdate.c
+++ b/xen/common/rcupdate.c
@@ -225,7 +225,7 @@ void call_rcu(struct rc
Split out to make the functional changes stick out more.
v2: amdgpu gained DRIVER_SYNCOBJ_TIMELINE.
v3: amdgpu lost DRIVER_SYNCOBJ_TIMELINE.
v4: Don't add a space in i915_drv.c (Sam)
Cc: Sam Ravnborg
Reviewed-by: Eric Anholt
Signed-off-by: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc:
Avoid using a variable length array.
Signed-off-by: Anthony PERARD
---
Notes:
Was suggested by Peter here:
"should we try to stop using variable length arrays?"
hw/i386/xen/xen-hvm.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/hw/i386/xen/xen-hv
Following "xen: Fix build with public headers", import other Xen
public headers that are describing interfaces.
The headers are cleaned up a bit while importing them. The header
guard symbols are changed to match QEMU's coding style, some other
part of the files that QEMU doesn't use are removed.
Hi,
Fix the build in osstest and some cleanup
For reference:
Recent flight failure:
https://lists.xenproject.org/archives/html/xen-devel/2019-06/msg01022.html
Bisect result:
https://lists.xenproject.org/archives/html/xen-devel/2019-06/msg01029.html
Thanks.
Anthony PERARD (4):
xen: Fix build
Following 37677d7db3 "Clean up a few header guard symbols", QEMU start
to fail to build:
In file included from ~/xen/tools/../tools/include/xen/io/blkif.h:31:0,
from ~/xen/tools/qemu-xen-dir/hw/block/xen_blkif.h:5,
from ~/xen/tools/qemu-xen-dir/hw/block/xen-block.
Following "xen: Fix build with public headers", import other Xen
public headers that are describing interfaces.
Import fbif.h, kbdif.h, netif.h, console.h, xenbus.h, protocols.h.
While editing xenfb.c, remove the include of event_channel.h as it
isn't needed.
The headers are cleaned up a bit whi
On 14/06/2019 16:56, Jan Beulich wrote:
On 07.03.19 at 11:32, wrote:
>> generic.c: In function ‘print_mtrr_state’:
>> generic.c:210:11: error: ‘%0*lx’ directive output between 1 and 1073741823
>> bytes may cause result to exceed ‘INT_MAX’ [-Werror=format-overflow=]
>> 210 |printk("%s
>>> On 17.06.19 at 17:12, wrote:
> On 17/06/2019 16:10, Jan Beulich wrote:
> On 07.06.19 at 11:22, wrote:
>>> The new format specifier is '%pp', and prints a pci_sbdf_t using the
>>> seg:bus:dev.func format. Replace all SBDFs printed using
>>> '%04x:%02x:%02x.%u' to use the new format specifi
On Thu, May 16, 2019 at 11:38 PM Tamas K Lengyel wrote:
>
> Patch cf4b30dca0a "Add debug code to detect illegal page_lock and
> put_page_type
> ordering" added extra sanity checking to page_lock/page_unlock for debug
> builds
> with the assumption that no hypervisor path ever locks two pages at
On Thu, May 16, 2019 at 11:38 PM Tamas K Lengyel wrote:
>
> Improves performance for release builds.
>
> Signed-off-by: Tamas K Lengyel
Patch ping. Unclear whose Ack is strictly needed as this is only
touching mem_sharing code and nothing else.
Thanks,
Tamas
___
On 05/04/2019 15:26, Jan Beulich wrote:
> Commit 3157bb4e13 ("Add MSR support for various feature AMD processor
> families") converted certain checks for Fam11 to include families all
> the way up to Fam17. The commit having no description, it is hard to
> tell whether this was a mechanical dec->he
On 05/04/2019 15:27, Jan Beulich wrote:
> Just like for other family values of 0x17 (see "x86/AMD: correct certain
> Fam17 checks"), commit 3157bb4e13 ("Add MSR support for various feature
> AMD processor families") made the original check for Fam11 here include
> families all the way up to Fam17.
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 17 June 2019 16:41
> To: qemu-de...@nongnu.org
> Cc: xen-devel@lists.xenproject.org; Anthony Perard
> ; Stefano Stabellini
> ; Paul Durrant
> Subject: [PATCH 1/4] xen: Fix build with public headers
>
>
>>> On 17.06.19 at 17:47, wrote:
> On 14/06/2019 16:56, Jan Beulich wrote:
> On 07.03.19 at 11:32, wrote:
>>> generic.c: In function ‘print_mtrr_state’:
>>> generic.c:210:11: error: ‘%0*lx’ directive output between 1 and 1073741823
>>> bytes may cause result to exceed ‘INT_MAX’ [-Werror=form
On Tue, 11 Jun 2019, Volodymyr Babchuk wrote:
> This patch adds basic framework for TEE mediators. Guests can't talk
> to TEE directly, we need some entity that will intercept request
> and decide what to do with them. "TEE mediator" is a such entity.
>
> This is how it works: user can build XEN w
Update to the latest stable tag.
Signed-off-by: Anthony PERARD
---
Config.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Config.mk b/Config.mk
index 417039d7f6..0fa4591379 100644
--- a/Config.mk
+++ b/Config.mk
@@ -274,7 +274,7 @@ QEMU_TRADITIONAL_URL ?=
git://xenbits.xe
>>> On 17.06.19 at 18:00, wrote:
> On 05/04/2019 15:26, Jan Beulich wrote:
>> Commit 3157bb4e13 ("Add MSR support for various feature AMD processor
>> families") converted certain checks for Fam11 to include families all
>> the way up to Fam17. The commit having no description, it is hard to
>> te
On Mon, 17 Jun 2019, Arnd Bergmann wrote:
> On architectures that have a larger dma_addr_t than phys_addr_t,
> the swiotlb_tbl_map_single() function truncates its return code
> in the failure path, making it impossible to identify the error
> later, as we compare to the original value:
>
> kernel/
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 17 June 2019 16:41
> To: qemu-de...@nongnu.org
> Cc: xen-devel@lists.xenproject.org; Anthony Perard
> ; Stefano Stabellini
> ; Paul Durrant
> Subject: [PATCH 3/4] xen: Import Xen public headers used by
Looking at https://www.gnu.org/licenses/license-list.en.html and also
looking at the usage in the Linux kernel, I am pretty sure it is
compatible. However, given that the Xen hypervisor as a whole is GPLv2,
I think it would be more precise to say:
SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Cl
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 17 June 2019 16:41
> To: qemu-de...@nongnu.org
> Cc: xen-devel@lists.xenproject.org; Anthony Perard
> ; Stefano Stabellini
> ; Paul Durrant
> Subject: [PATCH 2/4] xen: Import other xen/io/*.h
>
> Follo
On 17/06/2019 17:28, Stefano Stabellini wrote:
Looking at https://www.gnu.org/licenses/license-list.en.html and also
looking at the usage in the Linux kernel, I am pretty sure it is
compatible. However, given that the Xen hypervisor as a whole is GPLv2,
I think it would be more precise to say:
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 17 June 2019 16:41
> To: qemu-de...@nongnu.org
> Cc: xen-devel@lists.xenproject.org; Anthony Perard
> ; Stefano Stabellini
> ; Paul Durrant
> Subject: [PATCH 4/4] xen: Avoid VLA
>
> Avoid using a varia
On Mon, Jun 17, 2019 at 05:15:51PM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> > Sent: 17 June 2019 16:41
> > To: qemu-de...@nongnu.org
> > Cc: xen-devel@lists.xenproject.org; Anthony Perard
> > ; Stefano Stabellini
> > ;
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 17 June 2019 17:46
> To: Paul Durrant
> Cc: qemu-de...@nongnu.org; xen-devel@lists.xenproject.org; Stefano Stabellini
>
> Subject: Re: [PATCH 3/4] xen: Import Xen public headers used by xen-hvm.c
>
>
On Mon, Jun 17, 2019 at 05:45:44PM +0100, Anthony PERARD wrote:
> On Mon, Jun 17, 2019 at 05:15:51PM +0100, Paul Durrant wrote:
> > AFAICT the only place (apart from legacy code in xen_common.h) that
> > params.h is necessary is in xen_suspend_notifier(). I wonder whether
> > that would be better m
On Mon, 17 Jun 2019, Julien Grall wrote:
> On 17/06/2019 17:28, Stefano Stabellini wrote:
> > Looking at https://www.gnu.org/licenses/license-list.en.html and also
> > looking at the usage in the Linux kernel, I am pretty sure it is
> > compatible. However, given that the Xen hypervisor as a whole
On Mon, Jun 17, 2019 at 05:39:09PM +0100, Paul Durrant wrote:
> > @@ -632,6 +633,8 @@ static void xen_sync_dirty_bitmap(XenIOState *state,
> > return;
> > }
> >
> > +bitmap = g_new0(unsigned long, bitmap_size);
> > +
>
> How hot is this function? It looks (unsurprisingly) like t
On 29/05/2019 11:17, Jan Beulich wrote:
> In particular with an enabled IOMMU (but not really limited to this
> case), trying to invoke fixup_irqs() after having already done
> disable_IO_APIC() -> clear_IO_APIC() is a rather bad idea:
>
> RIP:e008:[] amd_iommu_read_ioapic_from_ire+0xde/0x113
On 17/06/2019 18:39, Andrew Cooper wrote:
> On 29/05/2019 11:17, Jan Beulich wrote:
>> In particular with an enabled IOMMU (but not really limited to this
>> case), trying to invoke fixup_irqs() after having already done
>> disable_IO_APIC() -> clear_IO_APIC() is a rather bad idea:
>>
>> RIP:e
On 2019/06/14, Daniel Vetter wrote:
> Split out to make the functional changes stick out more.
>
Since this patch flew-by, as standalone one (intentionally or not) I'd
add, anything vaguely like:
"Core users of DRIVER_PRIME were removed from core with prior patches."
HTH
Emil
__
Hi all,
This is the list of external interfaces that we need to document for the
Xen FuSa work. I divided it into categories to make it easier to deal
with. The doc is also available in markdown format on github [1].
Cheers,
Stefano
[1] https://github.com/sstabellini/FuSa.git
---
# Intro
Thi
Patchew URL:
https://patchew.org/QEMU/20190617154105.32323-1-anthony.per...@citrix.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190617154105.32323-1-anthony.per...@citrix.com
Type: series
Subject: [Xen-devel] [PATCH 0/4] F
On Sat, 15 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 6/14/19 9:53 PM, Stefano Stabellini wrote:
> > On Wed, 12 Jun 2019, Julien Grall wrote:
> > > (Moving from xen-users to xen-devel).
> > >
> > > On 11/06/2019 23:18, Stefano Stabellini wrote:
> > > > I managed to reproduced the issue, a
On 17/06/2019 18:55, Andrew Cooper wrote:
> On 17/06/2019 18:39, Andrew Cooper wrote:
>> On 29/05/2019 11:17, Jan Beulich wrote:
>>> In particular with an enabled IOMMU (but not really limited to this
>>> case), trying to invoke fixup_irqs() after having already done
>>> disable_IO_APIC() -> clear_
Also change srat_region_mask to uint64_t as it is used to store the
return value of pdx_init_mask. uint64_t is always greater or equal to
u64.
Signed-off-by: Stefano Stabellini
CC: jbeul...@suse.com
CC: andrew.coop...@citrix.com
CC: julien.gr...@arm.com
---
xen/arch/arm/setup.c | 2 +-
xen/arch
The mask calculation in pdx_init_mask is wrong when the first bank
starts at address 0x0. The reason is that pdx_init_mask will do '0 - 1'
causing an underflow. As a result, the mask becomes 0x
which is the biggest possible mask and ends up causing a significant
memory waste in the
Hi all,
This is an update on v3 of "fix mask calculation in pdx_init_mask", plus
a cleanup patch.
The following changes since commit 2ac48fd52d846a8c3949373aa0d776c6cb5452db:
x86/x2APIC: tighten check in cluster mode IPI sending (2019-06-17 17:38:35
+0200)
are available in the Git repositor
On 17/06/2019 19:12, Stefano Stabellini wrote:
> On Sat, 15 Jun 2019, Julien Grall wrote:
>> On 6/14/19 9:53 PM, Stefano Stabellini wrote:
>>> On Wed, 12 Jun 2019, Julien Grall wrote:
>> Regardless that, I still think we have some issues when using the same
>> compressed kernel for Dom0 and DomU
On Thu, Jun 13, 2019 at 07:22:31AM -0600, Jan Beulich wrote:
> This also takes care of several of the shift values wrongly having been
> specified as hex rather than dec.
>
> Take the opportunity and add further fields.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/drivers/passthrough/amd/iommu_
flight 137904 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137904/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
This code was never updated when the 32bit build of Xen was dropped.
* Expand the now-redundant ptr_reg macro.
* The number of iterations in the loop can be halfed by using 64bit writes,
without consuming any extra execution resource in the pipeline. Adjust all
numbers/offsets appropriate
flight 137850 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137850/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-4 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 130965
build-amd64-pre
On 17/06/2019 20:49, Andrew Cooper wrote:
> This code was never updated when the 32bit build of Xen was dropped.
>
> * Expand the now-redundant ptr_reg macro.
> * The number of iterations in the loop can be halfed by using 64bit writes,
>without consuming any extra execution resource in the p
On 13/06/2019 14:22, Jan Beulich wrote:
> This also takes care of several of the shift values wrongly having been
> specified as hex rather than dec.
>
> Take the opportunity and add further fields.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/drivers/passthrough/amd/iommu_detect.c
> +++ b/xen/dri
On Wed, 1 May 2019, Julien Grall wrote:
> Hi,
>
> On 30/04/2019 22:02, Stefano Stabellini wrote:
> > Now that map_mmio_regions takes a p2mt parameter, there is no need to
> > keep "mmio" in the name. The p2mt parameter does a better job at
> > expressing what the mapping is about. Let's save the e
On Thu, 2 May 2019, Jan Beulich wrote:
> >>> On 30.04.19 at 23:02, wrote:
> > --- a/xen/include/public/domctl.h
> > +++ b/xen/include/public/domctl.h
> > @@ -571,12 +571,24 @@ struct xen_domctl_bind_pt_irq {
> > */
> > #define DPCI_ADD_MAPPING 1
> > #define DPCI_REMOVE_MAPPING 0
>
On Thu, May 30, 2019 at 10:08:12PM -0400, Rich Persaud wrote:
> [CAUTION: External Email]
> On Mar 28, 2019, at 11:04, Woods, Brian
> mailto:brian.wo...@amd.com>> wrote:
>
> This patch series add support and enablement for mwait on AMD Naples
> and Rome processors. Newer AMD processors support m
On Wed, 1 May 2019, Julien Grall wrote:
> Hi,
>
> On 30/04/2019 22:02, Stefano Stabellini wrote:
> > Add a new memory policy option for the iomem parameter.
> > Possible values are:
> > - arm_devmem, device nGRE, the default on ARM
> > - arm_memory, WB cachable memory
> > - x86_uc: uncachable memo
flight 137851 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137851/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 16 guest-start/debian.repeat fail REGR. vs. 137724
Tests which did no
On Tue, 7 May 2019, Julien Grall wrote:
> > +#define MEMORY_POLICY_ARM_DEV_nGRE 0
> > +/* Arm only. Outer Shareable, Outer/Inner Write-Back Cacheable memory */
> > +#define MEMORY_POLICY_ARM_MEM_WB 1
>
> I am wondering whether we should put Arm (resp. x86) defines under an ifdef
> ar
In my case, this PLX bridge must work with some special software which can't
run on domain-0。So I have no choice without passthrough it.
I'm not sure are there some other devices working similar with this bridge,
And not sure it is suitable for others.
Just deal with the one I faced.
At 201
flight 137852 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137852/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 129313
build-armhf-pvops
flight 137871 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137871/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 137600
build-i386-xsm
On 6/14/19 11:35 PM, Daniel Vetter wrote:
They're the default.
Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.
Signed-off-by: Daniel Vetter
Cc: Oleksandr Andrushchenko
Cc: xen-devel@lists.xenproject.org
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/d
flight 137854 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137854/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install
fail REGR. vs. 13
98 matches
Mail list logo
