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
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
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 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
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
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
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
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
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:
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
---
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
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
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
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
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.
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 |
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
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
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
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
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
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
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
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.
>>
>>
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.
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
>>> 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
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
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
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 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 +++--
>
>>> 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
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 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
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
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: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
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
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
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
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
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:
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
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.
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
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
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.
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
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 ++--
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
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
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
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
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.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
___
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
>>> 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
>>> 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.
>>
>>
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
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
>>> 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
>
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:
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 (
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
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
>>> 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)
> {
> -
>>> 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 )
> -
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
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 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
>> - *
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
>>> 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:
> +
>>> 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
> +
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:
> --- 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
>>> 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
>>> 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
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:
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
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 :
>>> 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
>>
>>> 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:
>>> 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
>> ---
>>> 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
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
---
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, _iommu_head, list )
+for_each_amd_iommu (
On 03/04/2019 07:26, Andrea Righi wrote:
> struct privcmd_buf_vma_private has a zero-sized array at the end
> (pages), use the new struct_size() helper to determine the proper
> allocation size and avoid potential type mistakes.
>
> Signed-off-by: Andrea Righi
Pushed to xen/tip.git
On 04/04/2019 17:12, Dan Carpenter wrote:
> The "call" variable comes from the user in privcmd_ioctl_hypercall().
> It's an offset into the hypercall_page[] which has (PAGE_SIZE / 32)
> elements. We need to put an upper bound on it to prevent an out of
> bounds access.
>
> Fixes: 1246ae0bb992
88 matches
Mail list logo
