>>> On 14.03.18 at 18:02, wrote:
> On 03/02/2018 04:08 PM, Jan Beulich wrote:
> On 21.02.18 at 15:02, wrote:
>>> --- a/xen/arch/x86/pv/emul-priv-op.c
>>> +++ b/xen/arch/x86/pv/emul-priv-op.c
>>> @@ -43,16 +43,6 @@
>>> #include "emulate.h"
>>> #include "mm.h"
>>>
>>> -/* Override macros
flight 120666 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120666/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 120496
test-armhf-armhf-libvirt 14 saveresto
>>> On 14.03.18 at 18:28, wrote:
> On 03/14/2018 03:55 AM, Jan Beulich wrote:
> On 14.03.18 at 00:31, wrote:
>>> + * For x86 implementations at least, the values used in the type field will
>>> + * match the Address Range Types as defined in section 15 (System Address
>>> + * Map Interfaces)
Hi Julien,
> At the same time move the remaining M2P define just above just above
> set_gpfn_from_mfn to keep all the dummy helpers for M2P together.
At the same time move the remaining M2P define just above
set_gpfn_from_mfn to keep all the dummy helpers for M2P together.
can't really evalu
>>> 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 like the following to the header file:
>
> ...
> /*
> * For x86 implementations at least, the val
flight 120672 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120672/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which are failing
>>> 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
Reviewed-by: Jan Beulich
(You should have Cc-ed Andrew and me.)
Jan
___
>>> On 14.03.18 at 19:31, wrote:
> On 14/03/18 18:19, julien.gr...@arm.com 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
>
> Remind me what the purpose of this patc
>>> 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 copy_mfn_to_guest(hnd, off, mfn)\
> +({
>>> On 14.03.18 at 19:20, wrote:
> From: Julien Grall
>
> At the same time replace _mfn(0) by INVALID_MFN or drop the initializer
> when it is not necessary. This will make clearer that the MFN
> initialized is not valid.
>
> Other than _mfn(0) -> INVALID_MFN, no functional change intended.
Th
>>> On 14.03.18 at 19:20, wrote:
> From: Julien Grall
>
> Other than _mfn(0) -> INVALID_MFN, no functional change intendend.
Similar remark here as just given for patch 14.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists
>>> 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 page_to_mfn and mfn_to_page return mfn_t by defa
>>> On 14.03.18 at 23:47, wrote:
> On 03/13/2018 05:06 PM, Arnd Bergmann wrote:
>> The legacy hypercall handlers were originally added with
>> a comment explaining that "copying the argument structures in
>> HYPERVISOR_event_channel_op() and HYPERVISOR_physdev_op() into the local
>> variable is su
>>> 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 mailing l
>>> 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 wrong
>>> impression of WRMSR succeeding") no l
>>> 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 TMR bit is cleared for
>>> 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 be other options that c
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 w
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 like the following to the hea
On Thu, 2018-03-15 at 02:37 -0600, Jan Beulich wrote:
> > > > 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 1f1
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 +12,6 @@ source "drivers/pci/Kconfig"
> >
> > source "drivers/video/Kconfig"
> >
> > +source "drivers/vpci/Kconfig"
>
> Are
On 13/03/18 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 wrong
> impression of WRMSR succeeding") no longer ignored. Restore original
> behavior for the two affected MSRs.
>
> Signed
flight 120670 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120670/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 120260
test-amd64-i386-xl-qemut-win7-amd64 17
On 14/03/2018 16:54, Christopher Lameter wrote:
>>> + pushq %rax/* Support Position Independent Code */
>>> + leaq1f(%rip), %rax /* RIP */
>>> + xchgq %rax, (%rsp)/* Restore RAX, put 1f */
>>> iretq /* continues at repeat_nmi below */
>>> UNW
>>> 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 +12,6 @@ source "drivers/pci/Kconfig"
>> >
>> > source "drivers/video/Kconfig"
>> >
On 15/03/18 03:43, Simon Gaiser wrote:
> Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple
> concurrent xenstore accesses") made a subtle change to the semantic of
> xenbus_dev_request_and_reply() and xenbus_transaction_end().
>
> Before on an error response to XS_TRANSACTION_END
> xe
On 15/03/18 03:43, Simon Gaiser wrote:
> Users of the xenbus functions should never close a non existent
> transaction (for example by trying to closing the same transaction
> twice) but better catch it in xs_request_exit() than to corrupt the
> reference counter.
>
> Signed-off-by: Simon Gaiser
On 15/03/18 03:43, Simon Gaiser wrote:
> By guaranteeing that the argument of XS_TRANSACTION_END is valid we can
> assume that the transaction has been closed when we get an XS_ERROR
> response from xenstore (Note that we already verify that it's a valid
> transaction id).
>
> Signed-off-by: Simon
Adding Pasi, as he often has an interest in this sort of question.
On Wed, Mar 14, 2018 at 2:29 PM, Anthony PERARD
wrote:
> Hi,
>
> In an xl guest config, we have the "usbdevice" option. It is just
> passthrough to QEMU "-usbdevice" without parsing. The QEMU option is now
> deprecated. v2.11 (to
>>> On 15.03.18 at 10:59, wrote:
> On 13/03/18 10:13, Jan Beulich wrote:
>> --- a/xen/arch/x86/msr.c
>> +++ b/xen/arch/x86/msr.c
>> @@ -147,6 +147,8 @@ int guest_rdmsr(const struct vcpu *v, ui
>>
>> switch ( msr )
>> {
>> +case MSR_AMD_PATCHLOADER:
>> +case MSR_IA32_UCODE_WRITE
On 15/03/18 10:40, Jan Beulich wrote:
>
>>> @@ -200,6 +202,16 @@ int guest_wrmsr(struct vcpu *v, uint32_t
>>> /* Read-only */
>>> goto gp_fault;
>>>
>>> +case MSR_AMD_PATCHLOADER:
>>> +if ( d->arch.cpuid->x86_vendor != X86_VENDOR_AMD )
>>> +goto gp_fault;
On Wed, Mar 14, 2018 at 06:20:01PM +, julien.gr...@arm.com wrote:
> From: Julien Grall
>
> The function populate_pt_range is used to populate in advance the
> page-table but it will not do the actual mapping. So passing the MFN in
> parameter is pointless. Note that the only caller pass 0...
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 wrong
impression of WRMSR succeeding") no longer ignored. Restore original
behavior for the two affected MSRs.
Signed-off-by: Jan Beulich
---
v2: Add comments.
---
W
On Wed, Mar 14, 2018 at 06:20:03PM +, julien.gr...@arm.com wrote:
> From: Julien Grall
>
> The current prototype is slightly confusing because it takes a virtual
> address and a physical frame (not address!). Switching to MFN will improve
> safety and reduce the chance to mistakenly invert th
On Wed, Mar 14, 2018 at 06:20:07PM +, julien.gr...@arm.com wrote:
> From: Julien Grall
>
> At the same time replace _mfn(0) by INVALID_MFN or drop the initializer
> when it is not necessary. This will make clearer that the MFN
> initialized is not valid.
>
> Other than _mfn(0) -> INVALID_MFN
>>> On 15.03.18 at 12:03, wrote:
> On 15/03/18 10:40, Jan Beulich wrote:
>>
@@ -200,6 +202,16 @@ int guest_wrmsr(struct vcpu *v, uint32_t
/* Read-only */
goto gp_fault;
+case MSR_AMD_PATCHLOADER:
+if ( d->arch.cpuid->x86_vendor != X86_V
On 15/03/18 11:09, 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 wrong
> impression of WRMSR succeeding") no longer ignored. Restore original
> behavior for the two affected MSRs.
>
> Signed
> On Mar 15, 2018, at 8:31 AM, Jan Beulich wrote:
>
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.
Well t
On Thu, Mar 15, 2018 at 02:45:15AM -0600, Jan Beulich wrote:
> >>> 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 i
On 15/03/18 11:13, Jan Beulich wrote:
On 15.03.18 at 12:03, wrote:
>> On 15/03/18 10:40, Jan Beulich wrote:
> @@ -200,6 +202,16 @@ int guest_wrmsr(struct vcpu *v, uint32_t
> /* Read-only */
> goto gp_fault;
>
> +case MSR_AMD_PATCHLOADER:
> +
On 15/03/18 06:10, Manish Jaggi wrote:
Hi Julien,
On 03/13/2018 05:45 PM, Julien Grall wrote:
Hi,
On 12/03/18 12:42, mja...@caviumnetworks.com wrote:
From: Manish Jaggi
Rename the menu text to Errata Workarounds. Subsequent patches will
add config options for SoC specific erratas.
Well
>>> On 15.03.18 at 12:15, wrote:
> Obviously any 41-patch series is going to take some time to get your head
> around, and so it makes sense to schedule that for a time when you have a few
> hours to set aside and nothing urgent. But in any case you don’t need to do
> a detailed review, just g
>>> On 15.03.18 at 12:21, wrote:
> On 15/03/18 11:13, Jan Beulich wrote:
> On 15.03.18 at 12:03, wrote:
>>> On 15/03/18 10:40, Jan Beulich wrote:
>> @@ -200,6 +202,16 @@ int guest_wrmsr(struct vcpu *v, uint32_t
>> /* Read-only */
>> goto gp_fault;
>>
>>
>>> On 15.03.18 at 12:22, wrote:
> On Thu, Mar 15, 2018 at 02:45:15AM -0600, Jan Beulich wrote:
>> >>> 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 beca
On Wed, Mar 14, 2018 at 10:13:16AM -0600, Jan Beulich wrote:
> >>> On 14.03.18 at 15:04, wrote:
> > +static void modify_decoding(const struct pci_dev *pdev, bool map, bool
> > rom_only)
> > +{
> > +struct vpci_header *header = &pdev->vpci->header;
> > +uint8_t slot = PCI_SLOT(pdev->devfn)
>>> On 15.03.18 at 12:14, wrote:
> On 15/03/18 11:09, 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 wrong
>> impression of WRMSR succeeding") no longer ignored. Restore original
>> behavi
On 15/03/18 11:36, Jan Beulich wrote:
On 15.03.18 at 12:14, wrote:
>> On 15/03/18 11:09, 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 wrong
>>> impression of WRMSR succeeding") no
On Thu, Mar 15, 2018 at 05:29:39AM -0600, Jan Beulich wrote:
> >>> On 15.03.18 at 12:22, wrote:
> > On Thu, Mar 15, 2018 at 02:45:15AM -0600, Jan Beulich wrote:
> >> >>> On 14.03.18 at 18:11, wrote:
> >> > The implementation of cc-option (grepping the option being tested in
> >> > output) in Conf
On Wed, Mar 14, 2018 at 10:51:07AM -0600, Jan Beulich wrote:
> >>> On 14.03.18 at 15:04, wrote:
> > --- a/xen/drivers/vpci/vpci.c
> > +++ b/xen/drivers/vpci/vpci.c
> > @@ -47,6 +47,10 @@ void vpci_remove_device(struct pci_dev *pdev)
> > xfree(r);
> > }
> > spin_unlock(&pdev->vpc
Libraries have no buisness using stdout directly, and these have no real
value. Dropping them removes the following output when building a PVH guest:
[root@fusebot ~]# xl create shim.cfg
Parsing config from shim.cfg
S3 disabled
S4 disabled
CONV disabled
[root@fusebot ~]#
Signed-off-b
Andrew Cooper (3):
x86/pv: Avoid locked bit manipulation in register_guest_callback()
x86/pv: Fold {compat_}unregister_guest_callback() into its non-compat
counterpart
x86/pv: Minor tweaks to {,compat_}register_guest_callback()
xen/arch/x86/pv/callback.c | 103 +++--
These functions are almost identical. They differ only in the error emitted
for the use of CALLBACKTYPE_syscall (which is inconsequential to guests), and
the type of their argument.
Have the callers pass the unreg.type parameter directly, avoiding the need for
differently typed parameters.
Signe
Changes to arch.vgc_flags are made to current in syncrhonous context only, and
don't need to be locked. (The only other changes are via
arch_set_info_guest(), which operates on descheduled vcpus only).
Replace the {set,clear}_bit() calls with compiler-visible bitwise operations.
Signed-off-by: A
* Being internal functions, use int rather than long for the return value
* Factor out pv_vcpu into a local variable. Reduces code volume, and removes
some split lines.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/pv/callback.c | 48 +
On Wed, Mar 14, 2018 at 11:04:00AM -0600, Jan Beulich wrote:
> >>> On 14.03.18 at 15:04, wrote:
> > --- a/xen/arch/x86/hvm/dom0_build.c
> > +++ b/xen/arch/x86/hvm/dom0_build.c
> > @@ -1117,7 +1117,7 @@ int __init dom0_construct_pvh(struct domain *d, const
> > module_t *image,
> >
> > pvh_s
This reduces code volume, and has a minor improvement on compiled size,
probably due to the removal of several temporary variables.
add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-50 (-50)
function old new delta
vmx_vmexit_handler
On Thu, Mar 15, 2018 at 11:56:53AM +, Andrew Cooper wrote:
> Libraries have no buisness using stdout directly, and these have no real
> value. Dropping them removes the following output when building a PVH guest:
>
> [root@fusebot ~]# xl create shim.cfg
> Parsing config from shim.cfg
>
On 15/03/18 07:52, Jan Beulich wrote:
On 14.03.18 at 19:31, wrote:
>> On 14/03/18 18:19, julien.gr...@arm.com 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
>>> On 15.03.18 at 12:56, wrote:
> Libraries have no buisness using stdout directly, and these have no real
> value. Dropping them removes the following output when building a PVH
> guest:
>
> [root@fusebot ~]# xl create shim.cfg
> Parsing config from shim.cfg
> S3 disabled
> S4 disable
On 06/03/18 16:53, Jan Beulich wrote:
> From: David E. Box
>
> Gemini Lake uses the same C-states as Broxton and also uses the
> IRTL MSR's to determine maximum C-state latency.
>
> Signed-off-by: David E. Box
> Acked-by: Len Brown
> Signed-off-by: Rafael J. Wysocki
> [Linux commit 1b2e87687d3f
>>> 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 void modify_decoding(const struct pci_dev *pdev, bool map, bool
>> > rom_only)
>> > +{
>> > +struct vpci_header *header = &pdev->vpci->header;
>> >
On 14/03/18 08:29, Jan Beulich wrote:
> As of commit 4008c71d7a ("x86/alt: Support for automatic padding
> calculations") there's no point having explict ASM_NOPn instances in
> alternatives anymore - drop them. As a result also drop the asm/nops.h
> inclusion from alternative.h, adding explicit in
>>> On 15.03.18 at 12:48, wrote:
> On Wed, Mar 14, 2018 at 10:51:07AM -0600, Jan Beulich wrote:
>> >>> On 14.03.18 at 15:04, wrote:
>> > --- a/xen/drivers/vpci/vpci.c
>> > +++ b/xen/drivers/vpci/vpci.c
>> > @@ -47,6 +47,10 @@ void vpci_remove_device(struct pci_dev *pdev)
>> > xfree(r);
>
>>> On 15.03.18 at 13:01, wrote:
> On Wed, Mar 14, 2018 at 11:04:00AM -0600, Jan Beulich wrote:
>> >>> On 14.03.18 at 15:04, wrote:
>> > --- a/xen/arch/x86/hvm/dom0_build.c
>> > +++ b/xen/arch/x86/hvm/dom0_build.c
>> > @@ -1117,7 +1117,7 @@ int __init dom0_construct_pvh(struct domain *d,
>> > co
Option like -Og produces something like
cc1: error: argument to '-O' should be a non-negative integer
with a compiler that doesn't support it.
Grepping for the exact option wouldn't work. Extend cc-option to take
into account the exit status of the test.
Signed-off-by: Jan Beulich
Signed-off
On 03/15/2018 04:39 AM, Jan Beulich wrote:
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 th
flight 120676 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120676/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail REGR. vs. 120095
test-amd64-amd64-
>>> On 15.03.18 at 13:46, wrote:
> Option like -Og produces something like
>
> cc1: error: argument to '-O' should be a non-negative integer
>
> with a compiler that doesn't support it.
>
> Grepping for the exact option wouldn't work. Extend cc-option to take
> into account the exit status of
01: support 3DNow! insns
02: place test blobs in executable section
03: abstract out XCRn accesses
04: adjust_bnd() should check XCR0
05: eliminate custom #MF/#XM handling
06: tell cmpxchg hook whether LOCK is in effect
07: correctly handle CMPXCHG* comparison failures
08: add read-modify-write hoo
Yes, recent AMD CPUs don't support them anymore, but I think we should
nevertheless cope.
Signed-off-by: Jan Beulich
---
v5: Correct pfpnacc table entry. Correct pfcmpgt and pswapd comments.
Check base table before extensions one.
v4: Fix PI2FW table entry. Add comment to _3dnow{,_ext}_table[
This allows the section contents to be disassembled without going
through any extra hoops, simplifying the analysis of problems in test
and/or emulation code.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v5: Use Andrew's section attributes trick (and drop respective part of
the des
Use hooks, just like done for other special purpose registers.
This includes moving XCR0 checks from hvmemul_get_fpu() to the emulator
itself as well as adding support for XGETBV emulation.
For now fuzzer reads will obtain the real values (minus the fuzzing of
the hook pointer itself).
Signed-of
Experimentally MPX instructions have been confirmed to behave as NOPs
unless both related XCR0 bits are set to 1. By implication branches
then also don't clear BNDn.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
v4: Re-base over XSTATE_* renaming.
--- a/xen/arch/x86/x86_emulate/x86_
Use the generic stub exception handling instead.
Signed-off-by: Jan Beulich
Reviewed-by: Paul Durrant
Acked-by: Andrew Cooper
---
v4: Re-base.
v3: Re-base.
v2: Re-base.
--- a/tools/tests/x86_emulator/x86-emulate.c
+++ b/tools/tests/x86_emulator/x86-emulate.c
@@ -193,8 +193,6 @@ int emul_test_r
This is necessary for the hook to correctly perform the operation.
Signed-off-by: Jan Beulich
Reviewed-by: Paul Durrant
Reviewed-by: Andrew Cooper
Acked-by: Tim Deegan
---
v5: Re-base.
v3: New.
--- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
+++ b/tools/fuzz/x86_instruction_emulator/fuz
If the ->cmpxchg() hook finds a mismatch, we should deal with this the
same way as when the "manual" comparison reports a mismatch.
This involves reverting bfce0e62c3 ("x86/emul: Drop
X86EMUL_CMPXCHG_FAILED"), albeit with X86EMUL_CMPXCHG_FAILED now
becoming a value distinct from X86EMUL_RETRY.
Si
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 main(int argc, char **arg
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 c
..., 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
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1297,8 +1297,86
..., 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.
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1188,6 +1188,61 @@ static int
... 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
@@ -1961,10 +1961,11
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
Acked-by: Tim Deega
The functions have a single caller only and are now guest paging type
independent (except for the tracing part), so have no need to exist as
standalone ones, let alone multiple times. Replace the two prior hooks
with just a single one for dealing with tracing.
Signed-off-by: Jan Beulich
Reviewed-
On 14/03/18 08:29, Jan Beulich wrote:
> Both consumers want them quoted, so quote them right away instead of
> using __stringify() upon use. In the spirit of other recent additions
> also make the assembly forms assembler macros, allowing the helper
> #define-s to be #undef-ed subsequently.
>
> Sig
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
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 mailing list
Xen-devel@lists.xenproject.org
https:
>>> 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 long bfn, unsigned int order)
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,
> +
>>> 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"
>> +
>> +int x86emul_read_xcr(un
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 want to toss out there -- w
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 @@
>>> })
>>>
>>> #include "x86_emulate/
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, struct pci_dev *pdev,
> >> > +
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
>> reasonably worming
>
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.
Albei
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 l
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
___
Xen-devel mailing list
Xen-devel@lists.xenproj
>>> 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, wrote:
>> >> > +static int maybe_defer_map(struct domain *d, struc
>>> 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 x86_emulate_state *state,
>> +struct
>>> 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 quickly
> - "Anythin
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,
>>> +uint32_t *eflags,
>>> +
1 - 100 of 246 matches
Mail list logo
