Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/amd/iommu_intr.c
+++ b/xen/drivers/passthrough/amd/iommu_intr.c
@@ -503,7 +503,7 @@ static struct amd_iommu *_find_iommu_for
{
struct amd_iommu *iommu;
-list_for_each_entry ( iommu, &amd_iommu_head, list )
+for_each_amd_iomm
Initially I had just noticed the unnecessary indirection in the call
from pi_update_irte(). The generic wrapper having an iommu_intremap
conditional made me look at the setup code though. So first of all
enforce the necessary dependency.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/v
>>> On 04.04.19 at 16:54, wrote:
>> On Apr 4, 2019, at 3:36 PM, Jan Beulich wrote:
> On 04.04.19 at 15:09, wrote:
>>> I agree that it is confusing. It would be fine to UNSHARE here as well
>>> to keep things consistent but otherwise it's not really an issue as
>>> the entry type is checked l
>>> On 04.04.19 at 18:39, wrote:
> On 2019/4/4 22:07, Andrew Cooper wrote:
>> This needs the following hunk folding in
>>
>> diff --git a/tools/tests/cpu-policy/test-cpu-policy.c
>> b/tools/tests/cpu-policy/test-cpu-policy.c
>> index beced5e..88f5121 100644
>> --- a/tools/tests/cpu-policy/test-cp
>>> On 28.03.19 at 15:43, wrote:
> This is a first preparatory step for enabling x2APIC support also
> for AMD (plus some misc cleanup).
>
> 1: entry: drop unused header inclusions
> 2: APIC: suppress redundant "Switched to ..." messages
> 3: ACPI: also parse AMD IOMMU tables early
> 4: IOMMU: in
>>> On 19.03.19 at 18:01, wrote:
> On 3/11/19 4:37 PM, Jan Beulich wrote:
>> The flag is really only meant for those, both HVM and 32-bit PV tell
>> kernel from user mode based on CPL/RPL. Remove the all-question-marks
>> comment and let's be on the safe side here and also suppress clearing
>> for
On 4/3/19 7:57 AM, Diego Alejandro Parra Guzman wrote:
Hello Julien Grall
Hi Diego,
thank you for your replied, you have clarified many of my doubts.
I have been implementing some basic functionality for the PMU :
Here small description:
* getpmuinfo_attr :
flight 134346 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134346/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7ed72121b753a7493a8c5bf3711b5efbc5e80491
baseline version:
ovmf b02873340b2de5c2fe832
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-debianhvm-amd64
testid guest-saverestore
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: q
>>> On 04.04.19 at 22:26, wrote:
> These helpers each fill in a single cpu_devs[] pointer, and since c/s
> 00b4f4d0f "x86/cpuid: Drop get_cpu_vendor() completely", this array is read
> exactly once on boot.
>
> Delete the hooks and cpu_devs[], and have early_cpu_detect() pick the
> appropriate cp
>>> On 04.04.19 at 22:26, wrote:
> cpu_dev.c_vendor[] is a char[8] array which is printed using %s in two
> locations. This leads to subtle lack-of-NUL bugs when using an 8 character
> vendor name.
>
> Introduce x86_cpuid_vendor_to_str() to turn an x86_vendor into a printable
> string, use it in
>>> On 04.04.19 at 22:26, wrote:
> --- a/xen/include/asm-x86/x86-vendors.h
> +++ b/xen/include/asm-x86/x86-vendors.h
> @@ -4,28 +4,29 @@
> /*
> * CPU vendor IDs
> *
> - * - X86_VENDOR_* are Xen-internal identifiers. Values and order are
> - * arbitrary.
> + * - X86_VENDOR_* are Xen-interna
flight 83874 distros-debian-jessie real [real]
http://osstest.xensource.com/osstest/logs/83874/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
>>> On 04.04.19 at 22:26, wrote:
> +static void init_hygon(struct cpuinfo_x86 *c)
> +{
> + unsigned long long value;
> +
> + /*
> + * Attempt to set lfence to be Dispatch Serialising. This MSR almost
> + * certainly isn't virtualised (and Xen at least will leak the real
> +
>>> On 04.04.19 at 22:26, wrote:
> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -135,6 +135,27 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr,
> uint64_t *val)
> /* Not offered to guests. */
> goto gp_fault;
>
> +case MSR_AMD_PATCHLEVEL:
> +BUILD
On 05/04/2019 09:57, Jan Beulich wrote:
On 04.04.19 at 22:26, wrote:
>> These helpers each fill in a single cpu_devs[] pointer, and since c/s
>> 00b4f4d0f "x86/cpuid: Drop get_cpu_vendor() completely", this array is read
>> exactly once on boot.
>>
>> Delete the hooks and cpu_devs[], and have
On 05/04/2019 10:03, Jan Beulich wrote:
On 04.04.19 at 22:26, wrote:
>> --- a/xen/include/asm-x86/x86-vendors.h
>> +++ b/xen/include/asm-x86/x86-vendors.h
>> @@ -4,28 +4,29 @@
>> /*
>> * CPU vendor IDs
>> *
>> - * - X86_VENDOR_* are Xen-internal identifiers. Values and order are
>> - *
Make XEN_VM_EVENT_RESUME return 0 in case of success, instead of
-EINVAL.
Remove vm_event_resume form vm_event.h header and set the function's
visibility to static as is used only in vm_event.c.
Move the vm_event_check_ring test inside vm_event_resume in order to
simplify the code.
Signed-off-by:
On 4/5/19 12:33 PM, Petre Pircalabu wrote:
Make XEN_VM_EVENT_RESUME return 0 in case of success, instead of
-EINVAL.
Remove vm_event_resume form vm_event.h header and set the function's
visibility to static as is used only in vm_event.c.
Move the vm_event_check_ring test inside vm_event_resume in
>>> On 02.04.19 at 18:42, wrote:
> @@ -345,15 +345,15 @@ void console_giveback(int id)
> serial_steal_fn = NULL;
> }
>
> -static void sercon_puts(const char *s)
> +static void sercon_puts(const char *s, unsigned int nr)
> {
> if ( serial_steal_fn != NULL )
> -(*serial_ste
>>> On 05.04.19 at 11:33, wrote:
> @@ -529,30 +534,21 @@ int __vm_event_claim_slot(struct domain *d, struct
> vm_event_domain *ved,
> /* Registered with Xen-bound event channel for incoming notifications. */
> static void mem_paging_notification(struct vcpu *v, unsigned int port)
> {
> -st
flight 134334 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134334/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-pvops
This run is configured for baseline tests only.
flight 83876 ovmf real [real]
http://osstest.xensource.com/osstest/logs/83876/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
Hi,
On 05/04/2019 11:00, Jan Beulich wrote:
On 02.04.19 at 18:42, wrote:
@@ -345,15 +345,15 @@ void console_giveback(int id)
serial_steal_fn = NULL;
}
-static void sercon_puts(const char *s)
+static void sercon_puts(const char *s, unsigned int nr)
{
if ( serial_steal_fn
Hi Julien,
Julien Grall writes:
> Hi,
>
> On 20/03/2019 17:01, Volodymyr Babchuk wrote:
>>
>> Julien Grall writes:
>>
>>> On 20/03/2019 15:27, Volodymyr Babchuk wrote:
Hello Julien,
Julien Grall writes:
> On 07/03/2019 21:04, Volodymyr Babchuk wrote:
>> From: Vol
>>> On 05.04.19 at 12:21, wrote:
> On 05/04/2019 11:00, Jan Beulich wrote:
>> In any event, if you mean to treat hwdom and DomU differently,
>> then I think title and/or description should actually say so, and why.
>
> I don't see how this is treated differently. This code does exactly what
> co
On 3/13/19 12:38 PM, Jan Beulich wrote:
> In a few cases only a query is intended, i.e. without populating a
> possible PoD or paged out entry, when the intention is to replace the
> current entry anyway. Use get_gfn_query() there instead.
>
> Signed-off-by: Jan Beulich
The first one should be f
On 3/13/19 12:38 PM, Jan Beulich wrote:
> Instead of the separate iommu_ret, the general rc can be used even for
> the IOMMU operations.
>
> Signed-off-by: Jan Beulich
Reviewed-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproject.o
>>> On 05.04.19 at 12:30, wrote:
> On 3/13/19 12:38 PM, Jan Beulich wrote:
>> In a few cases only a query is intended, i.e. without populating a
>> possible PoD or paged out entry, when the intention is to replace the
>> current entry anyway. Use get_gfn_query() there instead.
>>
>> Signed-off-by
>>> On 14.03.19 at 14:51, wrote:
> Saving and restoring the value of this MSR is currently handled by
> implementation-specific code despite it being architectural. This patch
> moves handling of accesses to this MSR from hvm.c into the msr.c, thus
> allowing the common MSR save/restore code to ha
This hunk modifies the cpuid= documentation, which is unrelated to the
spec-ctrl= section.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Norbert Manthey
---
docs/misc/xen-command-line.pandoc | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/docs/misc/xen-command-
>>> On 05.04.19 at 14:34, wrote:
> This hunk modifies the cpuid= documentation, which is unrelated to the
> spec-ctrl= section.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
I'm sorry for not having noticed this during review.
Jan
___
X
Make XEN_VM_EVENT_RESUME return 0 in case of success, instead of
-EINVAL.
Remove vm_event_resume form vm_event.h header and set the function's
visibility to static as is used only in vm_event.c.
Move the vm_event_check_ring test inside vm_event_resume in order to
simplify the code.
Signed-off-by:
On 05/04/2019 09:12, Jan Beulich wrote:
On 19.03.19 at 18:01, wrote:
>> On 3/11/19 4:37 PM, Jan Beulich wrote:
>>> The flag is really only meant for those, both HVM and 32-bit PV tell
>>> kernel from user mode based on CPL/RPL. Remove the all-question-marks
>>> comment and let's be on the saf
flight 134416 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134416/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
This patch moves common code from p2m_set_altp2m_mem_access() and
p2m_change_altp2m_gfn() into one function
Signed-off-by: Alexandru Isaila
---
xen/arch/x86/mm/mem_access.c | 7 ++-
xen/arch/x86/mm/p2m.c| 12 ++--
xen/include/asm-x86/p2m.h| 11 +++
3 files change
This patch moves common code from p2m_set_altp2m_mem_access() and
p2m_change_altp2m_gfn() into one function
Signed-off-by: Alexandru Isaila
---
xen/arch/x86/mm/mem_access.c | 30 +++--
xen/arch/x86/mm/p2m.c| 37 ++--
xen/include/asm
On a new altp2m view the p2m_set_suppress_ve() func will fail with invalid mfn
from p2m->get_entry() if p2m->set_entry() was not called before.
This patch solves the problem by getting the mfn from hostp2m.
Signed-off-by: Alexandru Isaila
---
xen/arch/x86/mm/p2m.c | 3 ++-
1 file changed, 2 ins
Dom0 vGIC will use the same number of interrupt lines as the hardware GIC.
While the hardware GIC can support up to 1020 interrupt lines,
the vGIC is only supporting up to 992 interrupt lines.
This means that Xen will not be able to boot on platforms where the hardware
GIC supports more than 992 in
On 4/1/19 1:24 PM, Julien Grall wrote:
Hi Lukas,
Hi,
You sent this patch twice. Is there any difference between the two?
No, they are the same. I accidentally send it twice.
On 3/27/19 7:19 AM, Lukas Juenger wrote:
Xen's vGIC implementation supports a maximum number of 992 IRQ lines.
NIT
1: correct certain Fam17 checks
2: limit C1E disable family range
v2: Follow Andrew's suggestion for NB_CFG in patch 1. New patch 2.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Fri, Apr 5, 2019 at 1:36 AM Jan Beulich wrote:
>
> >>> On 04.04.19 at 16:54, wrote:
> >> On Apr 4, 2019, at 3:36 PM, Jan Beulich wrote:
> > On 04.04.19 at 15:09, wrote:
> >>> I agree that it is confusing. It would be fine to UNSHARE here as well
> >>> to keep things consistent but otherw
On 04/04/2019 15:33, Andrew Cooper wrote:
On 04/04/2019 15:20, Julien Grall wrote:
Hi,
On 04/04/2019 15:19, Jan Beulich wrote:
On 04.04.19 at 16:04, wrote:
At the moment, xen/lib/x86 is covered by the "REST". However, this is
x86-only, so this can fall under the x86 maintainership.
Signed
On 28.01.19 17:59, Julien Grall wrote:
While SPIs are shared between CPU, it is not possible to receive the
same interrupts on a different CPU while the interrupt is in active
state. The deactivation of the interrupt is done at the end of the
handling.
This means the _IRQ_PENDING logic is unec
Greetings,
0day kernel testing robot got the below dmesg and the first bad commit is
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/stackguards
commit bfcf4bd96c127fa67275b54554bea089424601f8
Author: Andy Lutomirski
AuthorDate: Fri Jul 13 17:27:40 2018 -0700
Commit:
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow
testid xen-boot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qe
On 3/28/19 10:48 AM, Jan Beulich wrote:
> I'm in particular after getting rid of asm/apicdef.h, but there are more
> no longer (or perhaps never having been) used ones.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Boris Ostrovsky
___
Xen-devel maili
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->hex conversion mistake, or
indeed intended. In any
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. The involved MSR (0xC0010055),
however, is fully
On 3/28/19 9:49 AM, Jan Beulich wrote:
> In order to be able to initialize x2APIC mode we need to parse
> respective ACPI tables early. Split amd_iov_detect() into two parts for
> this purpose, and call the initial part earlier on.
>
> Signed-off-by: Jan Beulich
>
Acked-by: Brian Woods
On 3/28/19 9:51 AM, Jan Beulich wrote:
> Do away with the CPU vendor dependency, and set the init ops pointer
> based on what ACPI tables have been found.
>
> Also take the opportunity and add __read_mostly to iommu_ops.
>
> Signed-off-by: Jan Beulich
Acked-by: Brian Woods
On 3/28/19 9:54 AM, Jan Beulich wrote:
> Move this into iommu_hardware_setup() and make that function non-
> inline. Move its declaration into common code.
>
> Signed-off-by: Jan Beulich
>
Acked-by: Brian Woods
___
Xen-devel mailing list
Xen-devel@li
On 05/04/2019 15:16, Andrii Anisov wrote:
On 28.01.19 17:59, Julien Grall wrote:
While SPIs are shared between CPU, it is not possible to receive the
same interrupts on a different CPU while the interrupt is in active
state. The deactivation of the interrupt is done at the end of the
handling.
Hello Julien,
On 05.04.19 17:34, Julien Grall wrote:
It is in common header and used by x86. It is preferable to keep all IRQ flags
at the same place hence why this was not moved in arch-specific header.
Ah, yes, sure.
Reviewed-by: Andrii Anisov
--
Sincerely,
Andrii Anisov.
___
>>> On 22.03.19 at 20:28, wrote:
> Limitations:
> - Custom runtime parameters (OPT_CUSTOM) are not supported yet.
> - For integer parameters (OPT_UINT), only unsigned parameters are printed
> correctly.
For this latter case I wonder whether it wouldn't be better to
return back the raw binary valu
On Fri, Apr 5, 2019 at 7:25 AM Alexandru Stefan ISAILA
wrote:
>
> This patch moves common code from p2m_set_altp2m_mem_access() and
> p2m_change_altp2m_gfn() into one function
>
> Signed-off-by: Alexandru Isaila
> ---
> xen/arch/x86/mm/mem_access.c | 30 +++--
> xen/arch/
flight 134338 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134338/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-xsm
On 14/03/2019 12:50, Norbert Manthey wrote:
> When checking for being an hvm domain, or PV domain, we have to make
> sure that speculation cannot bypass that check, and eventually access
> data that should not end up in cache for the current domain type.
>
> This is part of the speculative hardenin
On 2019/4/5 17:38, Jan Beulich wrote:
On 04.04.19 at 22:26, wrote:
+ else
+ /* Successfully enabled! */
+ __set_bit(X86_FEATURE_LFENCE_DISPATCH,
+ c->x86_capability);
Down the road we may want to make this another helper function
share
>>> On 05.04.19 at 17:30, wrote:
> On 2019/4/5 17:38, Jan Beulich wrote:
>> On 04.04.19 at 22:26, wrote:
>>> + /*
>>> +* If the user has explicitly chosen to disable Memory Disambiguation
>>> +* to mitigiate Speculative Store Bypass, poke the appropriate MSR.
>>> +*/
>>> + if (opt
OSSTests upgrade to Jessie has identified that with a sufficiently large grant
table, a watchdog timeout can occur.
http://logs.test-lab.xenproject.org/osstest/logs/134399/test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow/serial-chardonnay0.log
Reported-by: Ian Jackson
Signed-off-by: Andrew Coope
Hi Andrew,
On 05/04/2019 17:33, Andrew Cooper wrote:
OSSTests upgrade to Jessie has identified that with a sufficiently large grant
table, a watchdog timeout can occur.
http://logs.test-lab.xenproject.org/osstest/logs/134399/test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow/serial-chardonnay0.lo
On 05/04/2019 17:35, Julien Grall wrote:
> Hi Andrew,
>
> On 05/04/2019 17:33, Andrew Cooper wrote:
>> OSSTests upgrade to Jessie has identified that with a sufficiently
>> large grant
>> table, a watchdog timeout can occur.
>>
>> http://logs.test-lab.xenproject.org/osstest/logs/134399/test-amd64-a
On 01/04/2019 19:48, Martin Cerveny wrote:
> Hello.
>
> On Mon, 1 Apr 2019, Jan Beulich wrote:
> On 31.03.19 at 10:11, wrote:
>>> There is problem in PCI device allocation algorithm (pci_setup()).
>>> Algorithm allocates PCI BAR sorted by size and this allows
>>> mixed allocation of prefetcha
Rework release-technician-checklist.txt to be more accessible, while
still being focused on someone familiar with the process:
1. Have the "Quick cheat-sheet" at the top, with the very first
suggestion to run `release help`.
2. Include a slightly more verbose description of the checklist after
th
With this script, once the main checks are out of the way, doing a
release (either an RC or the final release) should mostly be a matter
of executing a sequence of 4 commands given by the `help` function in
this script.
Signed-off-by: George Dunlap
---
There's one hard-coded "default" path in her
flight 134439 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134439/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_disk.c | 4 ++--
tools/libxl/libxl_internal.h | 2 +-
tools/libxl/libxl_nic.c | 4 ++--
tools/libxl/libxl_pci.c | 4 ++--
tools/libxl/libxl_usb.c | 8
tools/libxl/libxl_vdispl.c | 4 ++--
tools/libxl/libxl_vsnd.c
Commit 03e1a56d81c16eece735e4d0ef74bfb10eaaba07 replaced DEVICE_ADD()
calls by device_add_domain_config() calls but also removed the comment
of DEVICE_ADD(). Copy the useful part of that comment to
device_add_domain_config().
Also, rename the parameter `type` to `dev`, because that parameter isn't
Documentation of device_add_domain_config and constify `src'.
Anthony PERARD (3):
libxl: Constify libxl_device_*_compare functions
libxl: Constify src of device_compare_fn_t
libxl: Document device_add_domain_config
tools/libxl/libxl_device.c | 6 +++---
tools/libxl/libxl_disk.c | 4
All functions libxl_device_*_copy which implements device_compare_fn_t
already have the `src' parameter defined with const.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_internal.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_internal.h b/tools/libx
On 4/5/19 17:34, Andrew Cooper wrote:
> On 14/03/2019 12:50, Norbert Manthey wrote:
>> When checking for being an hvm domain, or PV domain, we have to make
>> sure that speculation cannot bypass that check, and eventually access
>> data that should not end up in cache for the current domain type.
>
On 05/04/2019 19:29, Norbert Manthey wrote:
> On 4/5/19 17:34, Andrew Cooper wrote:
>> On 14/03/2019 12:50, Norbert Manthey wrote:
>>> When checking for being an hvm domain, or PV domain, we have to make
>>> sure that speculation cannot bypass that check, and eventually access
>>> data that should
During development of the XTF pagewalk tests, I reliably encountered this
message exactly once per run. It occurs when the first action to touch
TSS.RSP0 is an interrupt/exception taken in userspace, and the processor tries
to push the IRET frame.
Subsequently, OSSTest has demonstrated that it tr
From: Ross Lagerwall
The binary diffing algorithm used by xen-livepatch depends on having unique
symbols.
Signed-off-by: Ross Lagerwall
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC: Ross Lagerwall
CC: Konrad R
flight 134455 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134455/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xsm 4 hos
Parsing the config seems to be an overkill for this particular task
and the config might simply be absent. Type returned should be either
LIBXL_DOMAIN_TYPE_HVM or LIBXL_DOMAIN_TYPE_PV but in that context
distinction between PVH and HVM should be irrelevant.
Signed-off-by: Igor Druzhinin
---
tool
On Fri, Apr 05, 2019 at 08:26:04PM +0100, Andrew Cooper wrote:
> From: Ross Lagerwall
>
> The binary diffing algorithm used by xen-livepatch depends on having unique
> symbols.
>
> Signed-off-by: Ross Lagerwall
> Signed-off-by: Andrew Cooper
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> CC: Ja
flight 134308 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134308/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64
Greetings:
I've encountered a problem running gdb + gdbsx on Xen 4.11.1, running Linux
kernel 4.18.0-15 on Ubuntu 18.04. Pertinent info is below.
I've observed this behavior with gdb 8.0, 8.1.1 and 8.2. I've also seen it
on Xen 4.9.2. In short, something is broken with my system, but I don't
know
flight 134459 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134459/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xsm 4 hos
flight 134329 qemu-upstream-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134329/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-
flight 134463 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134463/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xsm 4 hos
flight 134362 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134362/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-pvops
flight 134337 qemu-upstream-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134337/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-
flight 134467 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134467/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
Hello.
On Fri, 5 Apr 2019, Igor Druzhinin wrote:
On 01/04/2019 19:48, Martin Cerveny wrote:
On Mon, 1 Apr 2019, Jan Beulich wrote:
On 31.03.19 at 10:11, wrote:
There is problem in PCI device allocation algorithm (pci_setup()).
Algorithm allocates PCI BAR sorted by size and this allows
mixed
flight 134374 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134374/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-xsm
88 matches
Mail list logo
