On 05/03/2018 07:06 AM, Kang, Luwei wrote:
Another thing is Xen's vmevent allows intercepting several other traced states.
It seems that a more generic framework is needed to
make PT work with vmevent subsystem? What is your thought on that?
Hi Wei,
I am not fully clear what is the "vmeve
> > +int pt_do_wrmsr(unsigned int msr, uint64_t msr_content) {
> > +struct pt_desc *pt_desc = ¤t->arch.hvm_vmx.pt_desc;
> > +
> > +if ( !opt_intel_pt )
> > +return 1;
> > +
> > +switch ( msr ) {
> > +case MSR_IA32_RTIT_CTL:
> > +pt_set_rtit_ctl(pt_desc, msr_content);
flight 122566 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122566/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3ff82ee5fc52c8e8764b407ec45cafab8452e2b9
baseline version:
ovmf 19f21ed91652d2a516042
From: DavidWang
Zhaoxin is a x86 IC designer. Its SOC products support both CPU
virtualization and I/O virtualization, which are compatible with Intel
VMX and VT-d respectively. Zhaoxin has 'Shanghai' CPU vendor ID.
Signed-off-by: DavidWang
---
xen/arch/x86/cpu/Makefile | 1 +
xen/ar
On 03/05/18 01:45, Marek Marczykowski wrote:
> On Wed, May 02, 2018 at 01:20:09AM -0600, Jan Beulich wrote:
> On 30.04.18 at 23:54, wrote:
>>> Using RING_GET_RESPONSE() on a shared ring is easy to use incorrectly
>>> (i.e., by not considering that the other end may alter the data in the
>>> sh
> > Here is a patch-series which adding Processor Trace enabling in XEN guest.
> > You can get It's software developer manuals from:
> > https://software.intel.com/sites/default/files/managed/c5/15/architect
> > ure-instruction-set-extensions-programming-reference.pdf
> > In Chapter 5 INTEL PROCES
On Wed, May 02, 2018 at 01:20:09AM -0600, Jan Beulich wrote:
> >>> On 30.04.18 at 23:54, wrote:
> > Using RING_GET_RESPONSE() on a shared ring is easy to use incorrectly
> > (i.e., by not considering that the other end may alter the data in the
> > shared ring while it is being inspected). Safe u
This run is configured for baseline tests only.
flight 74662 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74662/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 19f21ed91652d2a5160426ad8ca9219728d85aec
baseline v
On 4/18/2018 1:11 AM, Linus Walleij wrote:
I wonder why I am starting to get CCed on Xen patches all of a sudden.
I happened to run into Jürgen at a conference only last weekend, but
I still don't know anything whatsoever about Xen or how it works.
If get_maintainer.pl has started to return my
flight 122563 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122563/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 19f21ed91652d2a5160426ad8ca9219728d85aec
baseline version:
ovmf 1df5fb2d83d9eca2d3b4b
flight 122561 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122561/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 122554
test-armhf-armhf-libvirt-xsm 14 saveresto
flight 122562 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122562/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf c603b6b3b13f3e3eca7c62d447994402c25cdc9d
baseline version:
xtf c3a84a8f7cedd97b34139c
On Mon, 23 Apr 2018, Lars Kurth wrote:
> Hi all,
>
> On 06/04/2018, 15:13, "Lars Kurth" wrote:
>
> > 1) Requirements to the code, a subset of MISRA for ASIL B
> > Next step: get more information about requirements and publish it to
> > xen-devel.
>
> I see a few proble
Wei,
On 2/21/18 3:46 PM, Wei Liu wrote:
Move and rename update_paging_mode. Create a local header file for
this and other functions that need exporting.
Signed-off-by: Wei Liu
---
Cc: Suravee Suthikulpanit
---
xen/drivers/passthrough/x86/amd/Makefile| 1 +
xen/drivers/passthrough/x86/a
On 05/02/2018 11:41 AM, Jan Beulich wrote:
On 02.05.18 at 17:22, wrote:
>> On 05/02/2018 11:01 AM, Jan Beulich wrote:
>> On 02.05.18 at 17:00, wrote:
On 05/02/2018 04:16 AM, Jan Beulich wrote:
On 30.04.18 at 18:23, wrote:
>> --- a/arch/x86/xen/xen-pvh.S
>> +++ b/ar
Wei,
On 2/21/18 3:46 PM, Wei Liu wrote:
It is never used and it is getting in the way of cleaning up.
The only callsite of guest_iommu_add_ppr_log has no effect because
guest iommu is not initialised.
Signed-off-by: Wei Liu
---
Cc: Suravee Suthikulpanit
---
xen/drivers/passthrough/x86/amd/Ma
On 02/05/18 17:15, Wei Liu wrote:
> On Wed, May 02, 2018 at 09:43:33AM -0600, Jan Beulich wrote:
> On 02.05.18 at 17:19, wrote:
>>> On Fri, Apr 27, 2018 at 08:53:30AM +, Kang, Luwei wrote:
>> Load/Store Intel processor trace register in context switch.
>> MSR IA32_RTIT_CTL is loade
This run is configured for baseline tests only.
flight 74659 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74659/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1df5fb2d83d9eca2d3b4b87fab7a0ec9f288cb6f
baseline v
On 04/28/2018 11:09 AM, Arnd Bergmann wrote:
> On Sat, Apr 28, 2018 at 12:21 AM, Joao Martins
> wrote:
>> On 04/27/2018 09:13 PM, Arnd Bergmann wrote:
>>> diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c
>>> index 761f6af6efa5..637982efecd8 100644
>>> --- a/arch/x86/kernel/pvcloc
On Wed, May 02, 2018 at 09:43:33AM -0600, Jan Beulich wrote:
> >>> On 02.05.18 at 17:19, wrote:
> > On Fri, Apr 27, 2018 at 08:53:30AM +, Kang, Luwei wrote:
> >> > > Load/Store Intel processor trace register in context switch.
> >> > > MSR IA32_RTIT_CTL is loaded/stored automatically from VMCS
> On Apr 24, 2018, at 05:19, Lars Kurth wrote:
>
> Hi all,
> as agreed please find attached the meeting invite
> Regards
> Lars
>
> ## Agenda (provisional)
> I copied what was discussed on this thread so far
> https://docs.google.com/document/d/1RWylmNmBXOrgGLARj6_ynK50P7SZPl4LpnmhGaPglJw/edit?
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 02 May 2018 16:58
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; qemu-bl...@nongnu.org; qemu-
> de...@nongnu.org; Stefano Stabellini ; Kevin Wolf
> ; Max Reitz
> Subject: Re: [PATCH 0/4] block
On Mon, Apr 30, 2018 at 01:01:35PM +0100, Paul Durrant wrote:
> The grant copy operation was added to libxengnttab in Xen 4.8.0 (released
> nearly 18 months ago) but the xen_disk PV backend QEMU is still carrying
> a significant amount of code purely to remain compatible with older
> versions of Xe
On Wed, Apr 25, 2018 at 02:46:47PM +0100, Igor Druzhinin wrote:
> When global_log_dirty is enabled VRAM modification tracking never
> worked correctly. The address that is passed to xen_hvm_modified_memory()
> is not the effective PFN but RAM block address which is not the same
> for VRAM.
>
> We
>>> On 02.05.18 at 17:19, wrote:
> On Fri, Apr 27, 2018 at 08:53:30AM +, Kang, Luwei wrote:
>> > > Load/Store Intel processor trace register in context switch.
>> > > MSR IA32_RTIT_CTL is loaded/stored automatically from VMCS.
>> > > When Intel PT is supported in guest, we need load/restore PT
>>> On 02.05.18 at 17:22, wrote:
> On 05/02/2018 11:01 AM, Jan Beulich wrote:
> On 02.05.18 at 17:00, wrote:
>>> On 05/02/2018 04:16 AM, Jan Beulich wrote:
>>> On 30.04.18 at 18:23, wrote:
> --- a/arch/x86/xen/xen-pvh.S
> +++ b/arch/x86/xen/xen-pvh.S
> @@ -54,6 +54,9 @@
>
On Wed, May 02, 2018 at 11:23:12AM +0200, Juergen Gross wrote:
> On 02/05/18 00:33, gre...@linuxfoundation.org wrote:
> >
> > This is a note to let you know that I've just added the patch titled
> >
> > x86/xen: Add pvh specific rsdp address retrieval function
> >
> > to the 4.16-stable tree
On 02/05/18 16:09, Jan Beulich wrote:
On 02.05.18 at 17:08, wrote:
>> On 05/02/2018 11:00 AM, Jan Beulich wrote:
>> On 02.05.18 at 16:57, wrote:
On 05/02/2018 04:05 AM, Jan Beulich wrote:
On 30.04.18 at 18:23, wrote:
>> Signed-off-by: Boris Ostrovsky
> Reviewed-by
On 05/02/2018 11:01 AM, Jan Beulich wrote:
On 02.05.18 at 17:00, wrote:
>> On 05/02/2018 04:16 AM, Jan Beulich wrote:
>> On 30.04.18 at 18:23, wrote:
--- a/arch/x86/xen/xen-pvh.S
+++ b/arch/x86/xen/xen-pvh.S
@@ -54,6 +54,9 @@
* charge of setting up it's own stack, G
On Fri, Apr 27, 2018 at 08:53:30AM +, Kang, Luwei wrote:
> > > Load/Store Intel processor trace register in context switch.
> > > MSR IA32_RTIT_CTL is loaded/stored automatically from VMCS.
> > > When Intel PT is supported in guest, we need load/restore PT MSRs only
> > > when PT is enabled in
>>> On 02.05.18 at 17:08, wrote:
> On 05/02/2018 11:00 AM, Jan Beulich wrote:
> On 02.05.18 at 16:57, wrote:
>>> On 05/02/2018 04:05 AM, Jan Beulich wrote:
>>> On 30.04.18 at 18:23, wrote:
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Jan Beulich
But to understand wh
>>> On 02.05.18 at 17:06, wrote:
> On 05/02/2018 04:26 AM, Jan Beulich wrote:
> On 01.05.18 at 14:34, wrote:
>>> On 05/01/2018 04:00 AM, Roger Pau Monné wrote:
On Mon, Apr 30, 2018 at 12:23:39PM -0400, Boris Ostrovsky wrote:
> And without it we can't use _BOOT_XX macros any longer so
On 05/02/2018 11:00 AM, Jan Beulich wrote:
On 02.05.18 at 16:57, wrote:
>> On 05/02/2018 04:05 AM, Jan Beulich wrote:
>> On 30.04.18 at 18:23, wrote:
Signed-off-by: Boris Ostrovsky
>>> Reviewed-by: Jan Beulich
>>>
>>> But to understand why things have been working nevertheless it
On 05/02/2018 04:26 AM, Jan Beulich wrote:
On 01.05.18 at 14:34, wrote:
>> On 05/01/2018 04:00 AM, Roger Pau Monné wrote:
>>> On Mon, Apr 30, 2018 at 12:23:39PM -0400, Boris Ostrovsky wrote:
And without it we can't use _BOOT_XX macros any longer so define new ones.
>>> Not being that fam
>>> On 02.05.18 at 17:00, wrote:
> On 05/02/2018 04:16 AM, Jan Beulich wrote:
> On 30.04.18 at 18:23, wrote:
>>> --- a/arch/x86/xen/xen-pvh.S
>>> +++ b/arch/x86/xen/xen-pvh.S
>>> @@ -54,6 +54,9 @@
>>> * charge of setting up it's own stack, GDT and IDT.
>>> */
>>>
>>> +#define PVH_GDT_EN
>>> On 02.05.18 at 16:57, wrote:
> On 05/02/2018 04:05 AM, Jan Beulich wrote:
> On 30.04.18 at 18:23, wrote:
>>> Signed-off-by: Boris Ostrovsky
>> Reviewed-by: Jan Beulich
>>
>> But to understand why things have been working nevertheless it would
>> have been nice if the commit message wasn
On 05/02/2018 04:16 AM, Jan Beulich wrote:
On 30.04.18 at 18:23, wrote:
>> --- a/arch/x86/xen/xen-pvh.S
>> +++ b/arch/x86/xen/xen-pvh.S
>> @@ -54,6 +54,9 @@
>> * charge of setting up it's own stack, GDT and IDT.
>> */
>>
>> +#define PVH_GDT_ENTRY_CANARY4
>> +#define PVH_CANARY_SEL
On 05/02/2018 04:05 AM, Jan Beulich wrote:
On 30.04.18 at 18:23, wrote:
>> Signed-off-by: Boris Ostrovsky
> Reviewed-by: Jan Beulich
>
> But to understand why things have been working nevertheless it would
> have been nice if the commit message wasn't empty, but instead said
> something lik
On 05/02/2018 04:00 AM, Jan Beulich wrote:
On 30.04.18 at 18:23, wrote:
>> Latest binutils release (2.29.1) will no longer allow proper computation
>> of GDT entries on 32-bits, with warning:
>>
>> arch/x86/xen/xen-pvh.S: Assembler messages:
>> arch/x86/xen/xen-pvh.S:150: Warning: shift count
From: Oleksandr Andrushchenko
It is now not fully possible to control if and which virtual devices
are created by the frontend, e.g. keyboard and pointer devices
are always created and multi-touch device is created if the
backend advertises multi-touch support. In some cases this
behavior is not
From: Oleksandr Andrushchenko
Add missing string constants for {feature|request}-raw-pointer
to align with the rest of the interface file.
Fixes 7868654ff7fe ("kbdif: Define "feature-raw-pointer" and
"request-raw-pointer")
Signed-off-by: Oleksandr Andrushchenko
---
xen/include/public/io/kbdi
On 05/02/2018 03:11 AM, Jan Beulich wrote:
On 30.04.18 at 19:50, wrote:
>> On 04/30/2018 01:07 PM, Andrew Cooper wrote:
>>> On 30/04/18 12:37, Jan Beulich wrote:
While the main problem to be addressed here is the issue of what so far
was named "vmcb_in_sync" starting out with the wr
flight 122557 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122557/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1df5fb2d83d9eca2d3b4b87fab7a0ec9f288cb6f
baseline version:
ovmf f9dff90289507191f2993
On 05/02/2018 04:58 PM, Konrad Rzeszutek Wilk wrote:
On Wed, May 02, 2018 at 10:16:08AM +0300, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
It is now not fully possible to control if and which virtual devices
are created by the frontend, e.g. keyboard and pointer devices
are al
On Wed, May 02, 2018 at 10:16:08AM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> It is now not fully possible to control if and which virtual devices
> are created by the frontend, e.g. keyboard and pointer devices
> are always created and multi-touch device is created
On 02/05/2018, 12:45, "Ian Jackson" wrote:
Lars Kurth writes ("Re: [PATCH for-4.11 v2 2/2] Add new add_maintainers.pl
script to optimise the workflow when using git format-patch with
get_maintainer.pl"):
> On 02/05/2018, 11:50, "Ian Jackson" wrote:
> If the address is a mail
PSEC 2018 brings together security researchers and developers from the
open-source ecosystems of OpenEmbedded, Xen Project and OpenXT.
Presentation topics will include Xen security, LinuxBoot, TPM 2.0, Intel TXT
SMI Transfer Monitor (STM), de-privileged QEMU, UEFI, trusted boot (SRTM and
DRTM
Lars Kurth writes ("Re: [PATCH for-4.11 v2 2/2] Add new add_maintainers.pl
script to optimise the workflow when using git format-patch with
get_maintainer.pl"):
> On 02/05/2018, 11:50, "Ian Jackson" wrote:
> If the address is a mailing list for some other stanza in MAINTAINERS,
> ie for
On 05/02/2018 09:17 AM, Razvan Cojocaru wrote:
> On 04/23/2018 02:47 PM, George Dunlap wrote:
>> On 04/18/2018 02:12 PM, Razvan Cojocaru wrote:
>>> p2m_change_type_range() handles end > max_mapped_pfn, but not
>>> start > max_mapped_pfn. Check the latter just after grabbing the
>>> lock and bail if
On 02/05/2018, 11:50, "Ian Jackson" wrote:
Lars Kurth writes ("Re: [PATCH for-4.11 v2 2/2] Add new add_maintainers.pl
script to optimise the workflow when using git format-patch with
get_maintainer.pl"):
> On 30/04/2018, 15:36, "Ian Jackson" wrote:
>
> +
On Wed, May 02, 2018 at 08:03:52PM +1000, Alexey G wrote:
> - Emulating (a simplest) upstream PCIe hierarchy for passed through PCIe
> devices. The issue was described in details here:
> http://lists.gnu.org/archive/html/qemu-devel/2018-03/msg03593.html
>
> Latter problem must be resolved properly
Lars Kurth writes ("Re: [PATCH for-4.11 v2 2/2] Add new add_maintainers.pl
script to optimise the workflow when using git format-patch with
get_maintainer.pl"):
> On 30/04/2018, 15:36, "Ian Jackson" wrote:
>
> +# Get the list of patches
> +my $pattern = $patch_dir.'/'.$patch_pr
On 01/05/18 11:28, Andrew Cooper wrote:
> On 26/04/18 12:33, Juergen Gross wrote:
>> This patch series aims at reducing the overhead of the XPTI Meltdown
>> mitigation.
>
> With just the first 3 patches of this series (in a bisection attempt),
> on a XenServer build based off staging, XenRT finds
On Wed, May 02, 2018 at 11:16:40AM +0100, George Dunlap wrote:
> Delete tabs and trailing whitespace.
>
> No functional change.
>
> Signed-off-by: George Dunlap
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://list
On 01/05/18 14:34, Lars Kurth wrote:
> Requested by Ian Jackson, see
> https://lists.xenproject.org/archives/html/xen-devel/2018-04/msg02286.html
>
> The patch also fixes the location of linux-2.6.18-xen.hg (it is currently
> pointing to an alias)
>
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc:
Jan Beulich writes ("Re: [PATCH for-4.11 2/2] Replace http: with https: in
MAINTAINERs file"):
> On 01.05.18 at 14:34, wrote:
> > @@ -404,7 +404,7 @@ F: unmodified_drivers/linux-2.6/
> > USB PV DRIVERS
> > M: Noboru Iwamatsu
> > S: Supported
> > -T: hg http://xenbits.xenproject.org/linux
On 02/05/18 12:16, George Dunlap wrote:
> Delete tabs and trailing whitespace.
>
> No functional change.
>
> Signed-off-by: George Dunlap
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lis
On 02/05/18 11:02, Jan Beulich wrote:
> Commit 0142064421 ("x86/traps: move set_guest_{machine,nmi}_trapbounce")
> converted the functions' return types from int to bool without also
> correcting the checks in assembly code: The ABI does not guarantee sub-
> 32-bit return values to be promoted to 3
There are a lot of places which release a lock before calling
vcpu_sleep_nosync(), which then just grabs the lock again. This is
not only a waste of time, but leads to more code duplication (since
you have to copy-and-paste recipes rather than calling a unified
function), which in turn leads to an
Delete tabs and trailing whitespace.
No functional change.
Signed-off-by: George Dunlap
---
Changes since RFC: Introduced
CC: Dario Faggioli
CC: Ian Jackson
CC: Wei Liu
CC: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
CC: Konrad Wilk
CC: Stefano Stabellini
CC: Julien Grall
CC: Juergen
The current sequence to initiate vcpu migration is inefficent and error-prone:
- The initiator sets VPF_migraging with the lock held, then drops the
lock and calls vcpu_sleep_nosync(), which immediately grabs the lock
again
- A number of places unnecessarily check for v->pause_flags in betwee
flight 122558 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122558/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 0306a1311d02ea52b4a9a9bc339f8bab9354c5e3
baseline version:
xen eff2
flight 122554 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122554/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 122527
test-armhf-armhf-libvirt-xsm 14 saveresto
I’ll try to summarize current issues/difficulties in extending the PCIe
passthrough support and possible ways to resolve these problems which
were discussed in the mailing list so far.
Possible options to extend PCI passthrough/emulation capabilities
---
Signed-off-by: Jan Beulich
--- /dev/null
+++ b/tests/xsa-242/Makefile
@@ -0,0 +1,11 @@
+include $(ROOT)/build/common.mk
+
+NAME := xsa-242
+CATEGORY := xsa
+TEST-ENVS := pv64
+
+TEST-EXTRA-CFG := extra.cfg.in
+
+obj-perenv += main.o
+
+include $(ROOT)/build/gen.mk
--- /dev/null
+++ b/tests/
Derived and extended from Jann Horn's original Linux PoC.
Signed-off-by: Jan Beulich
--- /dev/null
+++ b/tests/xsa-240/Makefile
@@ -0,0 +1,9 @@
+include $(ROOT)/build/common.mk
+
+NAME := xsa-240
+CATEGORY := xsa
+TEST-ENVS := $(PV_ENVIRONMENTS)
+
+obj-perenv += main.o
+
+include $(ROOT)/b
On 02/05/18 10:02, Jan Beulich wrote:
> Commit 0142064421 ("x86/traps: move set_guest_{machine,nmi}_trapbounce")
> converted the functions' return types from int to bool without also
> correcting the checks in assembly code: The ABI does not guarantee sub-
> 32-bit return values to be promoted to 3
On 02/05/18 00:33, gre...@linuxfoundation.org wrote:
>
> This is a note to let you know that I've just added the patch titled
>
> x86/xen: Add pvh specific rsdp address retrieval function
>
> to the 4.16-stable tree which can be found at:
>
> http://www.kernel.org/git/?p=linux/kernel/gi
> >> >>> On 28.04.18 at 03:07, wrote:
> >> >> > @@ -383,13 +388,28 @@ static int vmx_init_vmcs_config(void)
> >> >> > _vmx_secondary_exec_control &=
> >> >> > ~SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS;
> >> >> >
> >> >> > min = 0;
> >> >> > -opt = VM_ENTRY_LOAD_GUEST_PAT | VM_ENTRY_
>>> On 02.05.18 at 09:22, wrote:
>> >>> On 28.04.18 at 03:07, wrote:
>> >> > @@ -383,13 +388,28 @@ static int vmx_init_vmcs_config(void)
>> >> > _vmx_secondary_exec_control &=
>> >> > ~SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS;
>> >> >
>> >> > min = 0;
>> >> > -opt = VM_ENTRY_LOAD_G
>>> On 02.05.18 at 09:47, wrote:
> 发件人: Jan Beulich
> 发送时间: 2018年4月30日 22:15
On 25.04.18 at 11:51, wrote:
>> --- a/xen/include/asm-x86/iommu.h
>> +++ b/xen/include/asm-x86/iommu.h
>> @@ -54,6 +54,7 @@ static inline const struct iommu_ops *iommu_get_ops(void)
>> switch ( boot_cpu_data.x
Commit 0142064421 ("x86/traps: move set_guest_{machine,nmi}_trapbounce")
converted the functions' return types from int to bool without also
correcting the checks in assembly code: The ABI does not guarantee sub-
32-bit return values to be promoted to 32 bits.
Take the liberty and also adjust the
Ian,
I addressed most of these locally, but have not dealt with the more functional
changes such as options, etc. However there are a few areas I was not planning
to address or have questions.
On 30/04/2018, 15:36, "Ian Jackson" wrote:
+# Get the list of patches
+my $pattern
On Tue, May 1, 2018 at 1:54 PM, Minjun Hong wrote:
> On Mon, Apr 30, 2018 at 10:13 PM, Andrew Cooper
> wrote:
>>
>> On 29/04/18 11:11, Minjun Hong wrote:
>> > Hi.
>> > I'm looking for a point where address translation (guest virtual
>> > address to machine address) occurs in Xen.
>> > Of course,
flight 74658 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74658/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-i386-squeeze-netboot-pygrub 10 debian-di-install fail like
74641
test-amd64-i386-i386
>>> On 01.05.18 at 14:34, wrote:
> On 05/01/2018 04:00 AM, Roger Pau Monné wrote:
>> On Mon, Apr 30, 2018 at 12:23:39PM -0400, Boris Ostrovsky wrote:
>>> And without it we can't use _BOOT_XX macros any longer so define new ones.
>>
>> Not being that familiar with Linux internals I'm not sure I se
>>> On 30.04.18 at 18:23, wrote:
> And without it we can't use _BOOT_XX macros any longer so define new ones.
Ah, here we go. Perhaps this should be moved earlier in the series?
Assuming you really want to go this route in the first place, taking
Roger's comment into consideration.
Jan
__
On 04/23/2018 02:47 PM, George Dunlap wrote:
> On 04/18/2018 02:12 PM, Razvan Cojocaru wrote:
>> p2m_change_type_range() handles end > max_mapped_pfn, but not
>> start > max_mapped_pfn. Check the latter just after grabbing the
>> lock and bail if true.
>>
>> Signed-off-by: Razvan Cojocaru
>> Sugge
flight 74656 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74656/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-i386-daily-netboot-pvgrub 10 debian-di-install fail like 74637
test-amd64-amd64-i386-d
>>> On 30.04.18 at 18:23, wrote:
> --- a/arch/x86/xen/xen-pvh.S
> +++ b/arch/x86/xen/xen-pvh.S
> @@ -54,6 +54,9 @@
> * charge of setting up it's own stack, GDT and IDT.
> */
>
> +#define PVH_GDT_ENTRY_CANARY4
> +#define PVH_CANARY_SEL (PVH_GDT_ENTRY_CANARY * 8)
I can only advis
>>> On 30.04.18 at 18:23, wrote:
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Jan Beulich
But to understand why things have been working nevertheless it would
have been nice if the commit message wasn't empty, but instead said
something like "The two happen to be identical on 64-bit."
Jan
Gentle reminder...
I think that Xen side comments are already there and still I miss
some input from ALSA community on patch #5.
Thank you,
Oleksandr
On 04/16/2018 09:24 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Please note: this patch series depends on [3].
This p
>>> On 30.04.18 at 18:23, wrote:
> Latest binutils release (2.29.1) will no longer allow proper computation
> of GDT entries on 32-bits, with warning:
>
> arch/x86/xen/xen-pvh.S: Assembler messages:
> arch/x86/xen/xen-pvh.S:150: Warning: shift count out of range (32 is not
> between 0 and 31)
>
Hi Jan,
Thanks for your reply. Answer as following.
发件人: Jan Beulich
发送时间: 2018年4月30日 22:15
收件人: David Wang
抄送: xen-devel; Fiona Li(BJ-RD)
主题: Re: [PATCH v2] x86/cpu: Add supports for zhaoxin x86 platform
>>> On 25.04.18 at 11:51, wrote:
> --- a/xen/a
On 05/02/2018 10:19 AM, Jan Beulich wrote:
On 02.05.18 at 07:29, wrote:
On 05/01/2018 12:54 AM, Marek Marczykowski-Górecki wrote:
Using RING_GET_RESPONSE() on a shared ring is easy to use incorrectly
(i.e., by not considering that the other end may alter the data in the
shared ring while it is
This run is configured for baseline tests only.
flight 74657 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74657/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f9dff90289507191f299331e44601c5ef83c1948
baseline v
>>> On 01.05.18 at 14:34, wrote:
> @@ -404,7 +404,7 @@ F:unmodified_drivers/linux-2.6/
> USB PV DRIVERS
> M: Noboru Iwamatsu
> S: Supported
> -T: hg http://xenbits.xenproject.org/linux-2.6.18-xen.hg
> +T: hg https://xenbits.xenproject.org/hg/linux-2.6.18-xen.hg
> F: driver
> > This patch add Intel processor trace support for cpuid handling.
>
> The 0x14 usage screams of wanting an #define.
Get it. Will define leaf 0x14 as a macro in next version. Thanks for the review.
Luwei Kang
___
Xen-devel mailing list
Xen-devel@lis
> On Tue, Jan 16, 2018 at 02:12:26AM +0800, Luwei Kang wrote:
> > Hi All,
> >
> > Here is a patch-series which adding Processor Trace enabling in XEN guest.
> > You can get It's software developer manuals from:
> > https://software.intel.com/sites/default/files/managed/c5/15/architect
> > ure-inst
> >>> On 28.04.18 at 03:07, wrote:
> >> > @@ -383,13 +388,28 @@ static int vmx_init_vmcs_config(void)
> >> > _vmx_secondary_exec_control &=
> >> > ~SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS;
> >> >
> >> > min = 0;
> >> > -opt = VM_ENTRY_LOAD_GUEST_PAT | VM_ENTRY_LOAD_BNDCFGS;
> >> >
>>> On 30.04.18 at 23:54, wrote:
> Using RING_GET_RESPONSE() on a shared ring is easy to use incorrectly
> (i.e., by not considering that the other end may alter the data in the
> shared ring while it is being inspected). Safe usage of a response
> generally requires taking a local copy.
>
> Pro
>>> On 02.05.18 at 07:29, wrote:
> On 05/01/2018 12:54 AM, Marek Marczykowski-Górecki wrote:
>> Using RING_GET_RESPONSE() on a shared ring is easy to use incorrectly
>> (i.e., by not considering that the other end may alter the data in the
>> shared ring while it is being inspected). Safe usage o
From: Oleksandr Andrushchenko
It is now not fully possible to control if and which virtual devices
are created by the frontend, e.g. keyboard and pointer devices
are always created and multi-touch device is created if the
backend advertises multi-touch support. In some cases this
behavior is not
>>> On 30.04.18 at 19:50, wrote:
> On 04/30/2018 01:07 PM, Andrew Cooper wrote:
>> On 30/04/18 12:37, Jan Beulich wrote:
>>> While the main problem to be addressed here is the issue of what so far
>>> was named "vmcb_in_sync" starting out with the wrong value (should have
>>> been true instead of
94 matches
Mail list logo
