On 23/11/17 12:00, George Dunlap wrote:
> On 11/23/2017 11:55 AM, Olaf Hering wrote:
>> On Thu, Nov 23, Olaf Hering wrote:
>>
>>> On Thu, Nov 23, Jan Beulich wrote:
Olaf, are you still playing with it every now and then?
>>> No, I have not tried it since I last touched it.
>> I just tried it,
On 23/11/17 12:45, Olaf Hering wrote:
> On Thu, Nov 23, Andrew Cooper wrote:
>
>> Its not that. This failure comes from the ring living inside the p2m,
>> and has already been found with introspection.
> In my case it was just a wrong domid. Now I use 'xl domid
lly. %rip in the failure message
points after the `rep outsb`, rather than at it.
If anyone has any ideas, I'm all ears. If not, I will try to find some
time to look deeper into the issue.
~Andrew
>From 9141a36374f52434a291e3be41bd259cfb9bda72 Mon Sep 17 00:00:00 2001
From: Andrew Coope
On 23/11/17 18:32, Julien Grall wrote:
> This new function will be used in a follow-up patch to copy data to the guest
> using the IPA (aka guest physical address) and then clean the cache.
>
> Signed-off-by: Julien Grall
> ---
> xen/arch/arm/guestcopy.c | 10 ++
> xen/include/a
. This avoids
duplicating or opencoding the feature check and value logic, as well as
abstracting away the internal value representation. One small adjustment to
guest_wrmsr() is required to cope with being called in toolstack context.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC
On 27/11/17 09:53, Jan Beulich wrote:
On 25.11.17 at 19:15, wrote:
>> --- a/xen/arch/x86/domctl.c
>> +++ b/xen/arch/x86/domctl.c
>> @@ -1286,7 +1286,7 @@ long arch_do_domctl(
>> struct xen_domctl_vcpu_msrs *vmsrs = &domctl->u.vcpu_msrs;
>> struct xen_domctl_vcpu_msr msr;
>>
On 27/11/17 09:11, Jan Beulich wrote:
> There are no locks being held, i.e. it is possible to be triggered by
> racy hypercall invocations. Subsequent code doesn't really depend on the
> checked values, so this is not a security issue.
>
> Signed-off-by: Jan Beulich
Ack
On 27/11/17 09:12, Jan Beulich wrote:
> There's no point in deferring this until after some initial processing,
> and it's actively wrong for the XENMAPSPACE_gmfn_foreign handling to not
> have such a check at all.
>
> Signed-off-by: Jan Beulich
suitably crafted input arguments. This isn't a security
> issue in this case because of the limited width of struct
> xen_add_to_physmap_batch's size field: It being 16-bits wide, only the
> r/o M2P area can be accessed. Still we can and should do better.
>
> Signe
ic enough a place to also cover
> VMX real mode emulation.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
Tested-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
. This avoids
duplicating or opencoding the feature check and value logic, as well as
abstracting away the internal value representation. One small adjustment to
guest_wrmsr() is required to cope with being called in toolstack context.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC
On 27/11/17 15:41, Daniel Kiper wrote:
> If it is possible we would like to have the Xen image higher than the
> booloader put it and certainly do not overwrite the Xen code and data
> during copy/relocation. Otherwise the Xen may crash silently at boot.
>
> Signed-off-by: Daniel Kiper
Actually,
On 27/11/17 17:01, Jan Beulich wrote:
On 26.10.17 at 19:03, wrote:
>> --- a/xen/arch/x86/hvm/vmx/vvmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
>> @@ -361,6 +361,40 @@ static void reg_write(struct cpu_user_regs *regs,
>> *pval = value;
>> }
>>
>> +static int operand_read(void *buf, struc
allows it.
>
> Signed-off-by: Tamas K Lengyel
> ---
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Jan Beulich
> Cc: Konrad Rzeszutek Wilk
> Cc: Stefano Stabellini
> Cc: Tim Deegan
> Cc: Wei Liu
> Cc: Daniel De Graaf
> Cc: ope...@g
On 28/11/17 19:34, Maran Wilson wrote:
> For certain applications it is desirable to rapidly boot a KVM virtual
> machine. In cases where legacy hardware and software support within the
> guest is not needed, Qemu should be able to boot directly into the
> uncompressed Linux kernel binary without t
:
...
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/traps.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 86506f3..c9a849c 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -650,11 +650,7
These are reads of registers which have already been set up, so are safe to do
at any point. However, TLB flushes (e.g. from bootstrap_map()) don't function
until get_cpu_info()->cr4 is populated.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/setup.c | 6 +++---
On 29/11/17 14:23, Jann Horn wrote:
> gnttab_setup_table() has the following code:
>
> =
> static long
> gnttab_setup_table(
> XEN_GUEST_HANDLE_PARAM(gnttab_setup_table_t) uop, unsigned int count)
> {
> struct gnttab_setup_table op;
> struct d
On 29/11/17 14:34, Jann Horn wrote:
> On Wed, Nov 29, 2017 at 3:32 PM, Andrew Cooper
> wrote:
>> On 29/11/17 14:23, Jann Horn wrote:
>>> gnttab_setup_table() has the following code:
>>>
>>> =
On 29/11/17 14:47, Juergen Gross wrote:
> On 29/11/17 15:44, Paolo Bonzini wrote:
>> On 29/11/2017 15:25, Boris Ostrovsky wrote:
>> zeropage is x86/Linux-specific so we'd need some sort of firmware (like
>> grub) between a hypervisor and Linux to convert hvm_start_info to
>> bootparams.
On 30/11/17 09:10, Jan Beulich wrote:
> Olaf has observed this assertion to trigger after an aborted migration
> of a PV guest (it remains to be determined why there is a page fault in
> the first place here:
>
> (XEN) Xen call trace:
> (XEN)[] do_page_fault+0x39f/0x55c
> (XEN)[] x86_64/ent
mall adjustment to
>> guest_wrmsr() is required to cope with being called in toolstack context.
>>
>> Signed-off-by: Andrew Cooper
> With the further intentions mentioned in the description (as a
> justification for some of the earlier requested changes to not
> be done)
k
>>>> up. Hence it bogus to request such completion when mmio_retry is set,
>>>> since this can only happen if the underlying I/O emulation has returned
>>>> X86EMUL_OKAY (meaning the I/O has completed successfully).
>>>>
>>>> Reported-by: An
On 28/11/17 08:32, Jan Beulich wrote:
On 26.10.17 at 19:03, wrote:
>> * invvpid has a 128-bit memory operand but we only require the VPID value
>> which lies in the lower 64 bits.
> The memory operand (wrongly) isn't being read at all - I don't
> understand the above bullet point for that r
On 01/12/17 22:58, Stefano Stabellini wrote:
>
> = Xen command forwarding =
>
> In the code below, it looks like Xen is forwarding everything to OP-TEE.
> Are there some commands Xen should avoid forwarding? Should we have a
> whitelist or a blacklist?
Whitelist everything.
At the very minimum, i
On 04/12/17 10:15, Jan Beulich wrote:
On 03.07.17 at 16:56, wrote:
> On 31.05.17 at 13:54, wrote:
>> On 31.05.17 at 13:08, wrote:
On 31/05/17 08:15, Jan Beulich wrote:
> The flag is really only meant for those, both HVM and 32-bit PV tell
> kernel from user mode based o
On 04/12/17 10:44, Jan Beulich wrote:
> Almost all users of it want it, and it calculates it anyway.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenpr
if ( unlikely(rc == -EINVAL) && get_l2_linear_pagetable(l2e, pfn, d) )
> +rc = 0;
Newline here. Otherwise, Reviewed-by: Andrew Cooper
> +return rc;
> }
>
>
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
, x, preemptible, ptpg);
> -ptpg = NULL;
> if ( x & PGT_partial )
> put_page(page);
> -break;
Newline here. Otherwise, Reviewed-by: Andrew Cooper
> +return rc;
> }
>
>
ue, Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 04/12/17 10:46, Jan Beulich wrote:
> @@ -2709,7 +2710,7 @@ int put_page_type_preemptible(struct pag
> int get_page_type_preemptible(struct page_info *page, unsigned long type)
> {
> ASSERT(!current->arch.old_guest_table);
Newline. Otherwise, Reviewed-by: Andrew Cooper
On 04/12/17 11:06, Jan Beulich wrote:
> p2m_pod_decrease_reservation() returning just (not) all-done is not
This would be easier to parse as "returning only all-done is not"
> sufficient for the caller: If some pages were processed,
> guest_remove_page() returning an error for those pages is the
On 04/12/17 11:06, Jan Beulich wrote:
> The function can be called for PV domains only, which commit 5a0b9fba92
> ("x86/mm: drop further relics of translated PV domains") sort of
> realized, but not fully.
>
> Signed-off-by: Jan Beulich
R
On 04/12/17 11:07, Jan Beulich wrote:
> As XSAs 246 and 247 have shown, not doing so is rather dangerous.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenpr
On 04/12/17 10:32, Jan Beulich wrote:
> Permissions that had been granted before should not be revoked when
> handling unrelated errors.
>
> Reported-by: HW42
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -1918,6 +1918,7 @@ int map_domain_pirq(
> s
On 04/12/17 10:33, Jan Beulich wrote:
> ... instead of using redundant calculations.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Now that pci_sbdf_t has been introduced, I should dust off my patch for %pP
~Andrew
___
Xen-deve
t;>
>>> Signed-off-by: Jan Beulich
>> How does dom0 boot with this change in place? You appear to have
>> prohibited mapping MMIO frames.
> The page in question is a page table one, which can't be MMIO.
> Dom0 is booting fine.
Acked-by: Andrew Cooper
the individual case blocks.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 04/12/17 10:16, Jan Beulich wrote:
On 25.08.17 at 16:59, wrote:
> On 10.08.17 at 09:19, wrote:
>> On 10.07.17 at 12:39, wrote:
Real hardware wraps silently in most cases, so we should behave the
same. Also split real and VM86 mode handling, as the latter really
oug
On 05/12/2017 09:30, Jan Beulich wrote:
On 05.12.17 at 09:49, wrote:
>> flight 116832 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/116832/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>
On 05/12/2017 10:03, Andrew Cooper wrote:
> On 05/12/2017 09:30, Jan Beulich wrote:
>>>>> On 05.12.17 at 09:49, wrote:
>>> flight 116832 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/116832/
>>>
>>> Regre
On 05/12/17 11:16, Jan Beulich wrote:
On 05.12.17 at 11:03, wrote:
>> On 05/12/2017 09:30, Jan Beulich wrote:
>> On 05.12.17 at 09:49, wrote:
flight 116832 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116832/
Regressions :-(
Tes
On 05/12/17 15:31, Jan Beulich wrote:
On 05.12.17 at 16:05, wrote:
>> Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 116832: regressions
>> -
>> FAIL"):
>>> This is a blue screen, recurring, and has first been reported in flight
>>> 116779, i.e. was likely introduced in the batch
r issue, as far as we
>> can tell.
>
> I understand. I have seen you pushed the fixes in master today. Let
> see how it perform and decide tomorrow what to do.
XenServer testing has identified this bug, and shown the bug to be fixed
with this patch in place.
Therefore, a retroactive Tes
arer. Reviewed-by: Andrew Cooper
> ---
> Changes since RFC: Comment added.
> ---
> Obviously other domctl-s could benefit from similar adjustments, so
> this is meant to be just a start.
>
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -615,13 +615,21 @@ i
On 06/12/17 16:19, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 06/12/17 16:20, Jan Beulich wrote:
> It goes all silent, leaving open what has actually caused the crash.
> Use domain_crash() instead, which leaves a log message before calling
> domain_shutdown(..., SHUTDOWN_crash).
>
> Signed-off-by: Jan Beulich
Acked-by
no point in going through "idx" when capturing the MFN.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
This looks to be based on some of your other mm cleanup, which isn't yet
in staging.
___
Xen-devel mai
On 06/12/17 16:21, Jan Beulich wrote:
> There's no need for
> - advancing the handles and at the same time using
> __copy_{from,to}_guest_offset(),
> - an "out" label,
> - local variables "done" and (function scope) "rc".
>
> Signed-off-by: Jan Beulich
These changes do mean that start is no lon
Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
/*
> + * Ignore any input requests and accept only printable characters,
> + * newline, and horizontal tab.
> + */
> +if ( dir != IOREQ_WRITE ||
> + (!isprint(c) && (c != '\n') && (c != '\t')) )
> return X86EMUL_OKAY;
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/cpu/intel.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
index ac932e5..d3145c0 100644
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -15,8 +15,6
On 06/12/17 16:37, Jan Beulich wrote:
> --- a/xen/include/asm-x86/msr.h
> +++ b/xen/include/asm-x86/msr.h
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -172,6 +173,24 @@ static inline unsigned long rdgsbase(voi
> return base;
> }
>
On 06/12/17 16:38, Jan Beulich wrote:
> As of commit 91f85280b9 ("x86: fix GS-base-dirty determination") the
> USER part of it isn't really appropriate anymore.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
njection, which combines to #DF.
While fixing this up, rename uncanonical_address to the more common gp_fault,
and drop the HVM_DBG_LOG() line which is redundant given the two adjacent
lines.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Jun Nakajima
CC: Kevin Tian
This wants backporting to 4.
They are straight aliases of the more common X86EMUL_* constants. While
adjusting these, fix the case indentation where appropriate.
No functional change, confirmed by diff'ing the compiled binary.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Jun Nakajima
CC: Kevin Tian
---
On 07/12/17 13:58, Jan Beulich wrote:
> Quite a few casts can be dropped this way, and type-safeness is being
> increased by not using void * (same goes for decode_vex_gpr()). Drop
> casts and no longer needed intermediate variables where possible. Take
> the opportunity and also switch the last pa
test.
>
> Signed-off-by: Jan Beulich
> Reviewed-by: George Dunlap
>
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 11/12/17 09:14, Jan Beulich wrote:
On 08.12.17 at 13:42, wrote:
>> On 12/08/2017 02:18 PM, Jan Beulich wrote:
>> On 24.10.17 at 12:19, wrote:
HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to
a
DOMCTL) for consistency with its HVMOP_altp2m_set_
On 11/12/17 10:06, Jan Beulich wrote:
On 08.12.17 at 15:38, wrote:
>> On 08/12/17 08:03, Tim Deegan wrote:
>>> It should be possible to do something like the misconfigured-entry bit
>>> trick by _allocating_ the memory up-front and building the p2m entries
>>> but only making them usable by t
On 12/12/17 11:10, Jan Beulich wrote:
> The bounds check needs to be done after the increment, not before, or
> else it needs to use a one lower immediate. Also use word operations
> rather than byte ones for both the increment and the compare (allowing
> E820_BIOS_MAX to be more easily bumped, sho
d-off-by: Jan Beulich
Reviewed-by: Andrew Cooper , altbeit it
preferably with space in the first hunk.
Any chance we can drop redundant size suffixes as we go?
>
> --- a/xen/arch/x86/boot/mem.S
> +++ b/xen/arch/x86/boot/mem.S
> @@ -29,8 +29,8 @@ get_memory_map:
> movw
On 12/12/17 13:25, Jan Beulich wrote:
On 28.11.17 at 16:08, wrote:
>> @@ -1905,7 +1906,8 @@ static int mod_l1_entry(l1_pgentry_t *pl1e,
>> l1_pgentry_t nl1e,
>> }
>>
>> /* Translate foreign guest address. */
>> -if ( paging_mode_translate(pg_dom) )
>> +if
[EC=0002 CR2=88003d405220], but that's
>>> not something the hypervisor needs to be concerned about.) Release
>>> builds work fine, which is a first indication that the assertion isn't
>>> really needed.
> Yep, this assert
There is no need for the overhead of a call to a separate translation unit.
While moving the implementation, update them to use uint64_t over u64
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/traps.c | 13 +
xen/include/asm-x86/msr.h | 14 +++---
2
They are straight aliases of the more common X86EMUL_* constants. While
adjusting these, fix the case indentation where appropriate.
No functional change, confirmed by diff'ing the compiled binary.
Signed-off-by: Andrew Cooper
Acked-by: Kevin Tian
---
CC: Jan Beulich
v2:
* Rebase
which combines to #DF.
Signed-off-by: Andrew Cooper
Acked-by: Kevin Tian
---
CC: Jan Beulich
v2:
* Drop uncanonical_address and return HNDL_exception_raised directly
This wants backporting to 4.9
---
xen/arch/x86/hvm/vmx/vmx.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-
Zero the msr structure once at initialisation time, and avoid re-zeroing the
reserved field every time the structure is used.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/domctl.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/xen/arch/x86/domctl.c
On 13/12/17 12:02, Ian Jackson wrote:
> The 4.10 release preparation was significantly more hairy than ideal.
> (We seem to have a good overall outcome despite, rather than because
> of, our approach.)
>
> This is the second time (at least) that we have come close to failure
> by committing to a re
Petkov
Signed-off-by: Ingo Molnar
[Linux commit f4e9b7af0cd58dd039a0fb2cd67d57cea4889abf]
Ported to Xen.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/microcode_amd.c | 4
1 file changed, 4 insertions(+)
diff --git a/xen/arch/x86/microcode_amd.c b/xen/arch/x86
The clang-5.0 build is reliably failing with:
Error: size of boot.o:.text is 0x01
which is because efi_arch_flush_dcache_area() exists as a single ret
instruction. Mark it as __init like everything else in the files.
Spotted by Travis.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC
to unsigned int.
>
> Signed-off-by: Jan Beulich
> Reviewed-by: Roger Pau Monné
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 30/08/2019 14:33, Jan Beulich wrote:
> When disabling SMT at runtime, secondary threads should no longer be
> candidates for bringing back up in response to _PUD ACPI events. Purge
> them from the tracking array.
I think I agree in principle, but what are _PUD events? I can't find
any referenc
at one case.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
> ---
> I'm wondering actually whether the user having to explicitly request the
> mode restoration is a good model: Why would we _not_ want to restore the
> mode we've set during boot? In the worst ca
little earlier
> instead) and add two alignment directives.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 30/08/2019 14:42, Jan Beulich wrote:
> We really don't need them to be any wider.
>
> Also remove the C level declaration (and hence also the GLOBAL) of
> video_mode altogether; it's used in assembly code only.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Ja
sleep_states[] is a write-only array, and despite the loop logic, the printed
message is consistently "ACPI sleep modes: S3". Drop it all.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/acpi/power.c | 15 ---
1 file c
Perform parsing in a custom_param, rather than stashing the content in a
string and parsing in an initcall. Adjust the parsing to conform to current
standards.
No practical change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
The reason that flags is
Perform parsing in a custom_param, rather than stashing the content in a
string and parsing in an initcall. Adjust the parsing to conform to current
standards.
No practical change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
The reason that flags is
On 29/08/2019 13:56, Jan Beulich wrote:
> On 19.08.2019 20:26, Andrew Cooper wrote:
>> AMD Pre-Fam17h CPUs "optimise" {F,}X{SAVE,RSTOR} by not saving/restoring
>> FOP/FIP/FDP if an x87 exception isn't pending. This causes an information
>> leak, CVE-2006-105
In the case the while loop gets interrupted, the target musn't appear as
up-to-date. The mov $X.tmp $X must be the last action of the rule.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Jan Beulich
CC: Roger Pau Monné
CC: George Dunlap
CC: Sander Eikelenboom
---
e the linkfarm logic to not regenerate itself when build artefacts
appear. This isn't a comprehensive fix but is the best which can be done
easily. Any further effort would be better spent making out-of-tree builds
work for Xen.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei
This logic is all terrible. This series should resolve the reported build
failure, but definitely isn't a "proper" fix.
Andrew Cooper (2):
tools/shim: Fix race condition creating linkfarm.stamp
tools/shim: Apply more duct tape to the linkfarm logic
tools/firmware/xen-di
the insn). Therefore in the HVM case for now it'll be
> backed by the same ->wbinvd_intercept() handlers.
>
> Use this occasion and also add the two missing table entries for
> CLDEMOTE, which doesn't require any further changes to make work.
>
> Signed-off-by: Jan B
On 03/09/2019 10:37, Jan Beulich wrote:
> The only place we'd expect the insn to be sensibly used is in
> (virtualization unaware) firmware.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Jan Beulich
> ---
> v3: New.
>
> --- a/xen/arch/x86/hvm/emulate.c
&g
On 03/09/2019 10:39, Jan Beulich wrote:
> Note that SDM revision 070 doesn't specify exception behavior for
> ModRM.mod != 0b11; assuming #UD here.
>
> Signed-off-by: Jan Beulich
What are we going to do about the ->write() hook atomicity? I'm happy
to put it on the TODO list, but we can't simply
On 03/09/2019 10:41, Jan Beulich wrote:
> While the PM doesn't say so, this assumes that the MPERF value read this
> way gets scaled similarly to its reading through RDMSR.
>
> Signed-off-by: Jan Beulich
This wants the following hunks merged, to at least keep the
intercept/exit codes up to date.
On 03/09/2019 17:14, Roger Pau Monne wrote:
> diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
> index 692b710b02..69652e1080 100644
> --- a/xen/arch/x86/hvm/ioreq.c
> +++ b/xen/arch/x86/hvm/ioreq.c
> @@ -1015,6 +1015,12 @@ int hvm_map_io_range_to_ioreq_server(struct domain *d,
> i
On 02/09/2019 15:50, Jan Beulich wrote:
>>> I'm also not sure why you
>>> call them "unpredictable": If all (or most) cases match, the branch
>>> there could be pretty well predicted (subject of course to capacity).
>> Data-dependent branches which have no correlation to pattern history, of
>> whi
On 04/09/2019 09:36, Jan Beulich wrote:
> On 03.09.2019 22:00, osstest service owner wrote:
>> flight 140960 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/140960/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could
On 04/09/2019 09:40, Jan Beulich wrote:
> On 04.09.2019 10:25, Juergen Gross wrote:
>> On 03.09.19 17:09, Jan Beulich wrote:
>>> On 03.09.2019 17:03, Juergen Gross wrote:
On 03.09.19 16:53, Jan Beulich wrote:
> On 29.08.2019 12:18, Juergen Gross wrote:
>> In order to have unique names
On 04/09/2019 10:11, Juergen Gross wrote:
> On 04.09.19 10:58, Andrew Cooper wrote:
>> On 04/09/2019 09:40, Jan Beulich wrote:
>>> On 04.09.2019 10:25, Juergen Gross wrote:
>>>> On 03.09.19 17:09, Jan Beulich wrote:
>>>>> On 03.09.2019 17:03, Juerg
On 04/09/2019 10:14, Olaf Hering wrote:
> A plain crashkernel=size is apparently not supported by the code
> anymore. In case kdump ever worked like that, the code which removed
> support for this notation did not update the documentation.
>
> Signed-off-by: Olaf Hering
That sounds like an accide
On 04/09/2019 10:26, Jan Beulich wrote:
> On 03.09.2019 14:34, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/cpuid.c
>>> +++ b/xen/arch/x86/cpuid.c
>>> @@ -545,6 +545,11 @@ void recalculate_cpuid_policy(struct dom
>>>
>>> p->extd.maxli
On 03/09/2019 13:25, Jan Beulich wrote:
> On 03.09.2019 12:28, Andrew Cooper wrote:
>> On 03/09/2019 10:39, Jan Beulich wrote:
>>> Note that SDM revision 070 doesn't specify exception behavior for
>>> ModRM.mod != 0b11; assuming #UD here.
>>>
>>> S
On 04/09/2019 08:55, Jan Beulich wrote:
> Commit 2634b997af ("x86/shadow: don't enable shadow mode with too small
> a shadow allocation") was incomplete: The adjustment done there to
> shadow_enable() is also needed in shadow_one_bit_enable(). The (new)
> problem report was (apparently) a failed PV
On 04/09/2019 12:45, Masami Hiramatsu wrote:
> Hi,
>
> These patches allow x86 instruction decoder to decode
> xen-cpuid which has XEN_EMULATE_PREFIX, and prohibit
> kprobes to probe on it.
>
> Josh reported that the objtool can not decode such special
> prefixed instructions, and I found that we a
On 04/09/2019 14:27, Jan Beulich wrote:
> --- a/xen/drivers/passthrough/vtd/iommu.h
> +++ b/xen/drivers/passthrough/vtd/iommu.h
> @@ -530,6 +530,7 @@ struct intel_iommu {
> struct ir_ctrl ir_ctrl;
> struct iommu_flush flush;
> struct acpi_drhd_unit *drhd;
> +nodeid_t node;
> };
n AMD hardware where RSTR_FP_ERR_PTRS is not advertised. Optimise the
conditions for the workaround paths.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
v3:
* Rename to X86_BUG_FPU_PTRS
* Reinstate, contrary to personal opinion, the fsw/fcw checks.
v2:
* Use the
: Christopher Clark
Reported-by: Dario Faggioli as well.
> Signed-off-by: Jan Beulich
I see you managed to create a smaller synthetic example. That is just
bizzare, but oh well.
Acked-by: Andrew Cooper
>
> --- a/tools/tests/cpu-policy/test-cpu-policy.c
> +++ b/tools/t
1 - 100 of 11857 matches
Mail list logo
