Re: [Xen-devel] [PATCH] x86: vlapic: Clear vector's TMR bit upon acceptance of edge-triggered interrupt to IRR

>>> On 15.03.18 at 00:35, wrote: > According to Intel SDM 10.8.4 Interrupt Acceptance for Fixed Interrupts: > "The trigger mode register (TMR) indicates the trigger mode of the > interrupt (see Figure 10-20). Upon acceptance of an interrupt > into the IRR, the corresponding

Re: [Xen-devel] [PATCH v2 1/4] x86/PVHv2: Add memory map pointer to hvm_start_info struct

On Thu, Mar 15, 2018 at 01:22:24AM -0600, Jan Beulich wrote: > >>> On 14.03.18 at 21:07, wrote: > > OK, I think I'm following the specifics now. But just to make sure we > > all on the same page before sending out the next version... > > > > I'll be adding something

Re: [Xen-devel] [PATCH v5 16/16] xen: Convert page_to_mfn and mfn_to_page to use typesafe MFN

>>> On 14.03.18 at 19:20, wrote: > From: Julien Grall > > Most of the users of page_to_mfn and mfn_to_page are either overriding > the macros to make them work with mfn_t or use mfn_x/_mfn because the > rest of the function use mfn_t. > > So make

Re: [Xen-devel] X86 Community Call: Wed March 14, 15:00 - 16:00 UTC - Minutes

>>> On 14.03.18 at 19:06, wrote: > # General Items: RFCs > > Jan: Generally reviewers prioritize RFCs lower than other non-RFC patch > series. Just to clarify - this was not "reviewers" but "I". I can't speak for others. Jan

[Xen-devel] Ping: [PATCH] x86: ignore guest microcode loading attempts

>>> On 13.03.18 at 12:51, wrote: On 13.03.18 at 11:36, wrote: >> On 13/03/2018 10:13, Jan Beulich wrote: >>> The respective MSRs are write-only, and hence attempts by guests to >>> write to these are - as of 1f1d183d49 ("x86/HVM: don't give the

Re: [Xen-devel] Implementaiton of cc-option in Config.mk

>>> On 14.03.18 at 18:11, wrote: > The implementation of cc-option (grepping the option being tested in > output) in Config.mk now makes it not possible to detect if -Og is > supported because "-Og" doesn't appear in the output if it is not > supported. I suspect there will

Re: [Xen-devel] [PATCH v2 00/27] x86: PIE support and option to extend KASLR randomization

Hi! > These patches make the changes necessary to build the kernel as Position > Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below > the top 2G of the virtual address space. It allows to optionally extend the > KASLR randomization range from 1G to 3G. Would you explain

[Xen-devel] [PATCH v5 10/14] x86/HVM: do actual CMPXCHG in hvmemul_cmpxchg()

..., at least as far as currently possible, i.e. when a mapping can be obtained. Signed-off-by: Jan Beulich Reviewed-by: Paul Durrant --- v4: Add ASSERT_UNREACHABLE() to hvmemul_cmpxchg()'s switch(). v3: New. --- a/xen/arch/x86/hvm/emulate.c +++

[Xen-devel] [PATCH v5 09/14] x86emul: also handle shifts through ->rmw()

These don't allow LOCK, but still are read-modify-write operations, so are better handled that way too. Signed-off-by: Jan Beulich --- v5: New. --- a/tools/tests/x86_emulator/test_x86_emulator.c +++ b/tools/tests/x86_emulator/test_x86_emulator.c @@ -585,6 +585,37 @@ int

[Xen-devel] [PATCH v5 08/14] x86emul: add read-modify-write hook

In order to correctly emulate read-modify-write insns, especially LOCKed ones, we should not issue reads and writes separately. Use a new hook to combine both, and don't uniformly read the memory destination anymore. Instead, DstMem opcodes without Mov now need to have done so in their respective

[Xen-devel] [PATCH v5 11/14] x86/HVM: make use of new read-modify-write emulator hook

..., at least as far as currently possible, i.e. when a mapping can be obtained. Signed-off-by: Jan Beulich Reviewed-by: Paul Durrant Reviewed-by: Andrew Cooper --- v4: bool_t -> bool. v3: New. ---

Re: [Xen-devel] [PATCH 3/3] x86: reduce "visibility" of spec_ctrl_asm.h

On 14/03/18 08:30, Jan Beulich wrote: > Other than indirect_thunk_asm.h, spec_ctrl_asm.h is a header needed by > assembly source files only. Avoid having all C sources have a dependency > on that header. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper

Re: [Xen-devel] X86 Community Call: Wed March 14, 15:00 - 16:00 UTC - Minutes

On Wed, Mar 14, 2018 at 6:06 PM, Lars Kurth wrote: > ## Meeting format > > Andy: no suggestions to change > Lars: the only issue I noticed that we had people > Video conference: do this as needed (most conference services have reasonably > worming > html5) One thing I

Re: [Xen-devel] [PATCH v5 03/14] x86emul: abstract out XCRn accesses

On 15/03/18 13:44, Jan Beulich wrote: On 15.03.18 at 14:35, wrote: >> On 15/03/18 13:04, Jan Beulich wrote: >>> static inline void x86_emul_hw_exception( >>> --- a/xen/arch/x86/x86_emulate.c >>> +++ b/xen/arch/x86/x86_emulate.c >>> @@ -42,3 +42,50 @@ >>> }) >>>

Re: [Xen-devel] [PATCH v9 07/11] vpci/bars: add handlers to map the BARs

On Thu, Mar 15, 2018 at 06:41:00AM -0600, Jan Beulich wrote: > >>> On 15.03.18 at 12:33, wrote: > > On Wed, Mar 14, 2018 at 10:13:16AM -0600, Jan Beulich wrote: > >> >>> On 14.03.18 at 15:04, wrote: > >> > +static int maybe_defer_map(struct domain *d,

Re: [Xen-devel] [PATCH v5 01/14] x86emul: support 3DNow! insns

On 15/03/18 13:02, Jan Beulich wrote: > Yes, recent AMD CPUs don't support them anymore, but I think we should > nevertheless cope. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper ___ Xen-devel

Re: [Xen-devel] X86 Community Call: Wed March 14, 15:00 - 16:00 UTC - Minutes

On 15/03/18 14:48, George Dunlap wrote: > On Wed, Mar 14, 2018 at 6:06 PM, Lars Kurth wrote: >> ## Meeting format >> >> Andy: no suggestions to change >> Lars: the only issue I noticed that we had people >> Video conference: do this as needed (most conference services have

[Xen-devel] [PATCH v3] xen/acpi: upload _PSD info for non Dom0 CPUs too

All uploaded PM data from non-dom0 CPUs takes the info from vCPU 0 and changing only the acpi_id. For processors which P-state coordination type is HW_ALL (0xFD) it is OK to upload bogus P-state dependency information (_PSD), because Xen will ignore any cpufreq domains created for past CPUs.

[Xen-devel] [PATCH v5 12/14] x86/HVM: use x86emul_write_xcr()

... instead of directly calling handle_xsetbv(), to make use of the additional checking there. Also don't call hvm_monitor_crX(XCR0, ...) for indexes other than zero anymore. Signed-off-by: Jan Beulich --- v5: New. --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c

[Xen-devel] [PATCH v5 13/14] x86/shadow: fully move unmap-dest into common code

By adding guest PTE size to shadow emulation context, the work begun by commit 2c80710a78 ("x86/shadow: compile most write emulation code just once") can be completed, paving the road for further movement into common code. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper

Re: [Xen-devel] [PATCH v5 03/14] x86emul: abstract out XCRn accesses

On 15/03/18 13:04, Jan Beulich wrote: > static inline void x86_emul_hw_exception( > --- a/xen/arch/x86/x86_emulate.c > +++ b/xen/arch/x86/x86_emulate.c > @@ -42,3 +42,50 @@ > }) > > #include "x86_emulate/x86_emulate.c" > + > +int x86emul_read_xcr(unsigned int reg, uint64_t *val, > +

Re: [Xen-devel] [PATCH 1/7] iommu: introduce the concept of BFN...

>>> On 12.02.18 at 11:47, wrote: > @@ -367,9 +367,9 @@ void amd_iommu_flush_all_pages(struct domain *d) > } > > void amd_iommu_flush_pages(struct domain *d, > - unsigned long gfn, unsigned int order) > + unsigned

Re: [Xen-devel] [PATCH v5 03/14] x86emul: abstract out XCRn accesses

>>> On 15.03.18 at 14:35, wrote: > On 15/03/18 13:04, Jan Beulich wrote: >> static inline void x86_emul_hw_exception( >> --- a/xen/arch/x86/x86_emulate.c >> +++ b/xen/arch/x86/x86_emulate.c >> @@ -42,3 +42,50 @@ >> }) >> >> #include "x86_emulate/x86_emulate.c" >> +

Re: [Xen-devel] [PATCH v5 08/14] x86emul: add read-modify-write hook

On 15/03/18 13:08, Jan Beulich wrote: > @@ -8517,6 +8690,142 @@ x86_emulate( > #undef vex > #undef ea > > +int x86_emul_rmw( > +void *ptr, > +unsigned int bytes, > +uint32_t *eflags, > +struct x86_emulate_state *state, > +struct x86_emulate_ctxt *ctxt) > +{ > +unsigned

Re: [Xen-devel] [PATCH v5 08/14] x86emul: add read-modify-write hook

>>> On 15.03.18 at 15:19, wrote: > On 15/03/18 13:08, Jan Beulich wrote: >> @@ -8517,6 +8690,142 @@ x86_emulate( >> #undef vex >> #undef ea >> >> +int x86_emul_rmw( >> +void *ptr, >> +unsigned int bytes, >> +uint32_t *eflags, >> +struct

Re: [Xen-devel] X86 Community Call: Wed March 14, 15:00 - 16:00 UTC - Minutes

>>> On 15.03.18 at 14:48, wrote: > Advantages of IRC: > - No "talking over" each other: two people can type at the same time, > and it's naturally separated into different chunks > - Easier to understand different accensts > > Disadvantages of IRC: > - Have to type reasonably

Re: [Xen-devel] [PATCH v5 08/14] x86emul: add read-modify-write hook

On 15/03/18 14:46, Jan Beulich wrote: On 15.03.18 at 15:19, wrote: >> On 15/03/18 13:08, Jan Beulich wrote: >>> @@ -8517,6 +8690,142 @@ x86_emulate( >>> #undef vex >>> #undef ea >>> >>> +int x86_emul_rmw( >>> +void *ptr, >>> +unsigned int bytes, >>> +

Re: [Xen-devel] [PATCH v5 12/16] xen/mm: Switch common/memory.c to use typesafe MFN

Hi Jan, On 15/03/18 08:06, Jan Beulich wrote: On 14.03.18 at 19:20, wrote: @@ -95,11 +101,17 @@ static unsigned int max_order(const struct domain *d) return min(order, MAX_ORDER + 0U); } +/* Helper to copy a typesafe MFN to guest */ +#define

Re: [Xen-devel] [PATCH v5 09/14] x86emul: also handle shifts through ->rmw()

On 15/03/18 13:09, Jan Beulich wrote: > These don't allow LOCK, but still are read-modify-write operations, so > are better handled that way too. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper ___

Re: [Xen-devel] [PATCH v9 07/11] vpci/bars: add handlers to map the BARs

>>> On 15.03.18 at 14:59, wrote: > On Thu, Mar 15, 2018 at 06:41:00AM -0600, Jan Beulich wrote: >> >>> On 15.03.18 at 12:33, wrote: >> > On Wed, Mar 14, 2018 at 10:13:16AM -0600, Jan Beulich wrote: >> >> >>> On 14.03.18 at 15:04,

Re: [Xen-devel] X86 Community Call: Wed March 14, 15:00 - 16:00 UTC - Minutes

On 15/03/2018, 15:04, "Juergen Gross" wrote: On 15/03/18 14:48, George Dunlap wrote: > On Wed, Mar 14, 2018 at 6:06 PM, Lars Kurth wrote: >> ## Meeting format >> >> Andy: no suggestions to change >> Lars: the only issue I

Re: [Xen-devel] [PATCH v5 01/16] x86/mm: skip incrementing mfn if it is not a valid mfn

On 15/03/18 07:49, Jan Beulich wrote: On 14.03.18 at 19:19, wrote: From: Wei Liu The function is called to fill in page table entries in populate_pt_range. Skip incrementing mfn if it is invalid. Signed-off-by: Wei Liu

Re: [Xen-devel] [PATCH v9 01/11] vpci: introduce basic handlers to trap accesses to the PCI config space

On 3/15/18 5:23 AM, Jan Beulich wrote: On 15.03.18 at 10:50, wrote: >> On Wed, Mar 14, 2018 at 08:31:03AM -0600, Jan Beulich wrote: >> On 14.03.18 at 15:03, wrote: --- a/xen/drivers/Kconfig +++ b/xen/drivers/Kconfig @@ -12,4

[Xen-devel] [xen-unstable-smoke test] 120794: tolerable all pass - PUSHED

flight 120794 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/120794/ 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   2   3