> -Original Message-
> From: Tian, Kevin
> Sent: Wednesday, June 17, 2020 9:35 AM
> To: Michał Leszczyński ; Andrew Cooper
>
> Cc: Xen-devel ; Jan Beulich
> ; Wei Liu ; Roger Pau Monné
> ; Nakajima, Jun ; George
> Dunlap ; Ian Jackson ;
> Julien Grall ; Stefano Stabellini ;
> Kang, Luwei
> -Original Message-
> From: Christopher Clark
> Sent: 16 June 2020 21:50
> To: Olaf Hering
> Cc: Tim Deegan ; xen-devel ;
> Ian Jackson
> ; Wei Liu ; p...@xen.org
> Subject: Re: [PATCH v1] kdd: remove zero-length arrays
>
> On Thu, Jun 11, 2020 at 12:12 PM Olaf Hering wrote:
> >
> > A
On Tue, Jun 16, 2020 at 12:31:06PM -0700, Tamas K Lengyel wrote:
> While forking VMs running a small RTOS systems (Zephyr) a Xen crash has been
> observed due to a mm-lock order violation while copying the HVM CPU context
> from the parent. This issue has been identified to be due to
> hap_update_p
On Tue, Jun 16, 2020 at 09:49:25PM +, Anchal Agarwal wrote:
> On Thu, Jun 04, 2020 at 09:05:48AM +0200, Roger Pau Monné wrote:
> > CAUTION: This email originated from outside of the organization. Do not
> > click links or open attachments unless you can confirm the sender and know
> > the con
On Tue, Jun 16, 2020 at 10:30:03PM +, Anchal Agarwal wrote:
> On Tue, Jun 16, 2020 at 09:49:25PM +, Anchal Agarwal wrote:
> > On Thu, Jun 04, 2020 at 09:05:48AM +0200, Roger Pau Monné wrote:
> > > On Wed, Jun 03, 2020 at 11:33:52PM +, Agarwal, Anchal wrote:
> > > > On Tue, May 19, 2
> -Original Message-
> From: Igor Druzhinin
> Sent: 17 June 2020 03:19
> To: xen-devel@lists.xenproject.org
> Cc: ian.jack...@eu.citrix.com; w...@xen.org; xadimg...@gmail.com; Igor
> Druzhinin
>
> Subject: [PATCH for-4.14 v3] tools/xen-ucode: return correct exit code on
> failed microco
flight 151161 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151161/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 150176
build-amd64-pr
On Tue, Jun 16, 2020 at 07:47:07PM +0200, Michał Leszczyński wrote:
> - 16 cze 2020 o 19:38, Roger Pau Monné roger@citrix.com napisał(a):
>
> > On Tue, Jun 16, 2020 at 05:24:11PM +0200, Michał Leszczyński wrote:
> >> Enable IPT when entering the VM and disable it on vmexit.
> >> Register s
On Wed, Jun 17, 2020 at 06:45:22AM +, Kang, Luwei wrote:
> > -Original Message-
> > From: Tian, Kevin
> > Sent: Wednesday, June 17, 2020 9:35 AM
> > To: Michał Leszczyński ; Andrew Cooper
> >
> > Cc: Xen-devel ; Jan Beulich
> > ; Wei Liu ; Roger Pau Monné
> > ; Nakajima, Jun ; George
flight 151162 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151162/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8927e286a43cddfaa328b0f4c41a09c629c9
baseline version:
ovmf b90beadfae8f1153697fb
flight 151186 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151186/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 3625b04991b4d6affadd99d377ab84bac48dfff4
baseline version:
xen b918
On 16.06.2020 21:31, Tamas K Lengyel wrote:
> While forking VMs running a small RTOS systems (Zephyr) a Xen crash has been
> observed due to a mm-lock order violation while copying the HVM CPU context
> from the parent. This issue has been identified to be due to
> hap_update_paging_modes getting a
flight 151164 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151164/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 150120
build-amd64-pre
On 16.06.2020 18:15, Andrew Cooper wrote:
> On 16/06/2020 10:33, Jan Beulich wrote:
>> On 15.06.2020 16:15, Andrew Cooper wrote:
>>> @@ -479,6 +497,18 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t
>>> domid, bool restore,
>>> goto out;
>>> }
>>>
>>> +/*
>>> + * A
On 16.06.2020 18:26, Andrew Cooper wrote:
> On 16/06/2020 11:00, Jan Beulich wrote:
>> On 15.06.2020 16:15, Andrew Cooper wrote:
>>> --- a/tools/libxc/xc_cpuid_x86.c
>>> +++ b/tools/libxc/xc_cpuid_x86.c
>>> @@ -503,6 +503,9 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t
>>> domid, bool r
On 17/06/2020 11:32, Jan Beulich wrote:
> On 16.06.2020 18:15, Andrew Cooper wrote:
>> On 16/06/2020 10:33, Jan Beulich wrote:
>>> On 15.06.2020 16:15, Andrew Cooper wrote:
@@ -479,6 +497,18 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t
domid, bool restore,
goto
On 17/06/2020 11:39, Jan Beulich wrote:
> On 16.06.2020 18:26, Andrew Cooper wrote:
>> On 16/06/2020 11:00, Jan Beulich wrote:
>>> On 15.06.2020 16:15, Andrew Cooper wrote:
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -503,6 +503,9 @@ int xc_cpuid_apply_policy
On 17.06.2020 13:16, Andrew Cooper wrote:
> On 17/06/2020 11:32, Jan Beulich wrote:
>> On 16.06.2020 18:15, Andrew Cooper wrote:
>>> On 16/06/2020 10:33, Jan Beulich wrote:
On 15.06.2020 16:15, Andrew Cooper wrote:
> @@ -479,6 +497,18 @@ int xc_cpuid_apply_policy(xc_interface *xch,
>
On 17/06/2020 12:24, Jan Beulich wrote:
> On 17.06.2020 13:16, Andrew Cooper wrote:
>> On 17/06/2020 11:32, Jan Beulich wrote:
>>> On 16.06.2020 18:15, Andrew Cooper wrote:
On 16/06/2020 10:33, Jan Beulich wrote:
> On 15.06.2020 16:15, Andrew Cooper wrote:
>> @@ -479,6 +497,18 @@ int x
On 16.06.2020 18:30, Roger Pau Monné wrote:
> On Tue, Jun 16, 2020 at 05:20:39PM +0200, Michał Leszczyński wrote:
>> Check if Intel Processor Trace feature is supported by current
>> processor. Define hvm_ipt_supported function.
>>
>> Signed-off-by: Michal Leszczynski
>> ---
>> xen/arch/x86/hvm/v
On 17.06.2020 13:28, Andrew Cooper wrote:
> We actually have AVX512 disabled by default in XenServer. The perf
> implications of letting 1 guest play with it is very severe.
>
> Now I think about it, I'm tempted to recommend it moves out of default
> generally.
Hmm, I'm tempted to ask whether yo
On 17/06/2020 12:41, Jan Beulich wrote:
> On 17.06.2020 13:28, Andrew Cooper wrote:
>> We actually have AVX512 disabled by default in XenServer. The perf
>> implications of letting 1 guest play with it is very severe.
>>
>> Now I think about it, I'm tempted to recommend it moves out of default
>>
- 17 cze 2020 o 11:09, Roger Pau Monné roger@citrix.com napisał(a):
> On Tue, Jun 16, 2020 at 07:47:07PM +0200, Michał Leszczyński wrote:
>> - 16 cze 2020 o 19:38, Roger Pau Monné roger@citrix.com napisał(a):
>>
>> > On Tue, Jun 16, 2020 at 05:24:11PM +0200, Michał Leszczyński wro
On Mon, Jun 08, 2020 at 03:25:07PM +0200, Gerd Hoffmann wrote:
> Ping. Anyone going to pick this up? MAINTAINERS lists Sergio+Paolo ...
> Or should I send a pull req myself?
Hmm, no reply. I guess that means "send a pull req" ...
take care,
Gerd
Looks like the logic was copied over from q35.
q35 does this for backward compatibility, there is no reason to do this
on microvm though. Also microvm doesn't need much mmio space, 1G is
more than enough. Using an mmio window smaller than 1G is bad for
gigabyte alignment and hugepages though. S
gs/microvm-20200617-pull-request
for you to fetch changes up to c8b473594b8fbba169a6ea950493a3015d15a18d:
microvm: move virtio base to 0xfeb0 (2020-06-17 14:24:28 +0200)
microvm: memory con
Not useful for microvm and allows users to shoot themself
into the foot (make ram + mmio overlap).
Signed-off-by: Gerd Hoffmann
Reviewed-by: Igor Mammedov
Acked-by: Paolo Bonzini
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Michael S. Tsirkin
Message-id: 20200529073957.8018-3-kra...@redha
Place virtio-mmio devices near the other mmio regions,
next ioapic is at @ 0xfec0.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Michael S. Tsirkin
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Igor Mammedov
Reviewed-by: Paul Durrant
Acked-by: Paolo Bonzini
Message-id: 20200529073957.8018
Move from X86MachineClass to PCMachineClass so it disappears
from microvm machine type property list.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Philippe Mathieu-Daudé
Acked-by: Paolo Bonzini
Reviewed-by: Michael S. Tsirkin
Reviewed-by: Igor Mammedov
Reviewed-by: Paul Durrant
Message-id: 2020
> > > -Original Message-
> > > From: Tian, Kevin
> > > Sent: Wednesday, June 17, 2020 9:35 AM
> > > To: Michał Leszczyński ; Andrew Cooper
> > >
> > > Cc: Xen-devel ; Jan Beulich
> > > ; Wei Liu ; Roger Pau Monné
> > > ; Nakajima, Jun ;
> > > George Dunlap ; Ian Jackson
> > > ; Julien Gra
On 06/17/20 05:16, Igor Druzhinin wrote:
> On 16/06/2020 19:42, Laszlo Ersek wrote
>> If I understand correctly, TimerInterruptHandler()
>> [OvmfPkg/8254TimerDxe/Timer.c] currently does the following:
>>
>> - RaiseTPL (TPL_HIGH_LEVEL) --> mask interrupts from being delivered
>>
>> - mLegacy8259->En
> -Original Message-
> From: Paul Durrant
> Sent: 15 June 2020 18:04
> To: 'Andrew Cooper' ; 'Xen-devel'
>
> Cc: 'Wei Liu' ; 'Jan Beulich' ; 'Ian
> Jackson' ;
> 'Roger Pau Monné'
> Subject: RE: [PATCH for-4.14 0/9] XSA-320 follow for IvyBridge
>
> > -Original Message-
> > From
On Wed, Jun 17, 2020 at 2:25 AM Roger Pau Monné wrote:
>
> On Tue, Jun 16, 2020 at 12:31:06PM -0700, Tamas K Lengyel wrote:
> > While forking VMs running a small RTOS systems (Zephyr) a Xen crash has been
> > observed due to a mm-lock order violation while copying the HVM CPU context
> > from the
Patchew URL: https://patchew.org/QEMU/20200617122901.13327-1-kra...@redhat.com/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
export
On Wed, Jun 17, 2020 at 01:54:45PM +0200, Michał Leszczyński wrote:
> - 17 cze 2020 o 11:09, Roger Pau Monné roger@citrix.com napisał(a):
>
> > On Tue, Jun 16, 2020 at 07:47:07PM +0200, Michał Leszczyński wrote:
> >> - 16 cze 2020 o 19:38, Roger Pau Monné roger@citrix.com napisał(a
On Wed, Jun 17, 2020 at 12:37:13PM +, Kang, Luwei wrote:
> > How does KVM deal with this, do they insert/modify trace packets on trapped
> > and emulated instructions by the VMM?
>
> The KVM includes instruction decoder and emulator(arch/x86/kvm/emulate.c),
> and the guest's memory can be set
On Wed, Jun 17, 2020 at 3:59 AM Jan Beulich wrote:
>
> On 16.06.2020 21:31, Tamas K Lengyel wrote:
> > While forking VMs running a small RTOS systems (Zephyr) a Xen crash has been
> > observed due to a mm-lock order violation while copying the HVM CPU context
> > from the parent. This issue has be
On 17.06.2020 15:00, Tamas K Lengyel wrote:
> On Wed, Jun 17, 2020 at 3:59 AM Jan Beulich wrote:
>> If there are code paths of both kinds, which approach to use in
>> vmx_load_pdptrs() may need to be chosen based on what
>> paging_locked_by_me() returns. Or perhaps an unlocked query is
>> fine in
On Wed, Jun 17, 2020 at 7:04 AM Jan Beulich wrote:
>
> On 17.06.2020 15:00, Tamas K Lengyel wrote:
> > On Wed, Jun 17, 2020 at 3:59 AM Jan Beulich wrote:
> >> If there are code paths of both kinds, which approach to use in
> >> vmx_load_pdptrs() may need to be chosen based on what
> >> paging_loc
On 17.06.2020 15:21, Tamas K Lengyel wrote:
> On Wed, Jun 17, 2020 at 7:04 AM Jan Beulich wrote:
>>
>> On 17.06.2020 15:00, Tamas K Lengyel wrote:
>>> On Wed, Jun 17, 2020 at 3:59 AM Jan Beulich wrote:
If there are code paths of both kinds, which approach to use in
vmx_load_pdptrs() may
On Wed, Jun 17, 2020 at 2:16 AM Olaf Hering wrote:
>
> Remove complicated code which deals with a simple boolean, to make gcc10
> happy.
>
> ld:
> /home/abuild/rpmbuild/BUILD/xen-4.14.20200616T103126.3625b04991/non-dbg/stubdom/vtpmmgr/vtpmmgr.a(vtpm_cmd_handler.o):(.bss+0x0):
> multiple definit
On Wed, Jun 17, 2020 at 7:28 AM Jan Beulich wrote:
>
> On 17.06.2020 15:21, Tamas K Lengyel wrote:
> > On Wed, Jun 17, 2020 at 7:04 AM Jan Beulich wrote:
> >>
> >> On 17.06.2020 15:00, Tamas K Lengyel wrote:
> >>> On Wed, Jun 17, 2020 at 3:59 AM Jan Beulich wrote:
> If there are code paths
On Wed, Jun 17, 2020 at 2:10 AM Olaf Hering wrote:
>
> Code compiled with gcc10 will not link properly due to multiple definition of
> the same function.
>
> Signed-off-by: Olaf Hering
Reviewed-by: Jason Andryuk
On 17.06.2020 15:31, Tamas K Lengyel wrote:
> On Wed, Jun 17, 2020 at 7:28 AM Jan Beulich wrote:
>>
>> On 17.06.2020 15:21, Tamas K Lengyel wrote:
>>> On Wed, Jun 17, 2020 at 7:04 AM Jan Beulich wrote:
On 17.06.2020 15:00, Tamas K Lengyel wrote:
> On Wed, Jun 17, 2020 at 3:59 AM Jan
Jason Andryuk, le mer. 17 juin 2020 09:35:52 -0400, a ecrit:
> On Wed, Jun 17, 2020 at 2:10 AM Olaf Hering wrote:
> >
> > Code compiled with gcc10 will not link properly due to multiple definition
> > of the same function.
> >
> > Signed-off-by: Olaf Hering
>
> Reviewed-by: Jason Andryuk
Acke
Olaf Hering, le mer. 17 juin 2020 08:13:49 +0200, a ecrit:
> int hw_is_tpm2(void)
> {
> -return (hardware_version.hw_version == TPM2_HARDWARE) ? 1 : 0;
> +return hardware_version == 2 ? 1 : 0;
> }
Or even
return hardware_version == 2;
?
Either case,
Acked-by: Samuel Thibault
Thank
On Wed, Jun 17, 2020 at 7:36 AM Jan Beulich wrote:
>
> On 17.06.2020 15:31, Tamas K Lengyel wrote:
> > On Wed, Jun 17, 2020 at 7:28 AM Jan Beulich wrote:
> >>
> >> On 17.06.2020 15:21, Tamas K Lengyel wrote:
> >>> On Wed, Jun 17, 2020 at 7:04 AM Jan Beulich wrote:
>
> On 17.06.2020 15:
On 17.06.2020 15:43, Tamas K Lengyel wrote:
> On Wed, Jun 17, 2020 at 7:36 AM Jan Beulich wrote:
>>
>> On 17.06.2020 15:31, Tamas K Lengyel wrote:
>>> On Wed, Jun 17, 2020 at 7:28 AM Jan Beulich wrote:
On 17.06.2020 15:21, Tamas K Lengyel wrote:
> On Wed, Jun 17, 2020 at 7:04 AM Jan
flight 151163 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151163/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 150039
test-amd64-amd
flight 151165 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151165/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 151091
test-armhf-armhf-libvirt-raw 13 saveresto
On Wed, Jun 17, 2020 at 06:49:16AM -0600, Tamas K Lengyel wrote:
> On Wed, Jun 17, 2020 at 2:25 AM Roger Pau Monné wrote:
> >
> > On Tue, Jun 16, 2020 at 12:31:06PM -0700, Tamas K Lengyel wrote:
> > > While forking VMs running a small RTOS systems (Zephyr) a Xen crash has
> > > been
> > > observe
On Tue, Jun 16, 2020 at 2:23 PM Marc Zyngier wrote:
>
> On 2020-06-16 19:13, CodeWiz2280 wrote:
> > On Tue, Jun 16, 2020 at 4:11 AM Marc Zyngier wrote:
> >>
> >> On 2020-06-15 20:14, CodeWiz2280 wrote:
> >>
> >> [...]
> >>
> >> > Also, the latest linux kernel still has the X-Gene storm distributo
On Wed, Jun 17, 2020 at 8:29 AM Roger Pau Monné wrote:
>
> On Wed, Jun 17, 2020 at 06:49:16AM -0600, Tamas K Lengyel wrote:
> > On Wed, Jun 17, 2020 at 2:25 AM Roger Pau Monné
> > wrote:
> > >
> > > On Tue, Jun 16, 2020 at 12:31:06PM -0700, Tamas K Lengyel wrote:
> > > > While forking VMs runnin
On Wed, Jun 17, 2020 at 8:24 AM Jan Beulich wrote:
>
> On 17.06.2020 15:43, Tamas K Lengyel wrote:
> > On Wed, Jun 17, 2020 at 7:36 AM Jan Beulich wrote:
> >>
> >> On 17.06.2020 15:31, Tamas K Lengyel wrote:
> >>> On Wed, Jun 17, 2020 at 7:28 AM Jan Beulich wrote:
>
> On 17.06.2020 15:
On 17/06/2020 13:51, Roger Pau Monné wrote:
> On Wed, Jun 17, 2020 at 01:54:45PM +0200, Michał Leszczyński wrote:
>> - 17 cze 2020 o 11:09, Roger Pau Monné roger@citrix.com napisał(a):
>>
>>> 24 Virtual Machine Control Structures -> 24.8 VM-entry Control Fields ->
>>> 24.8.1 VM-Entry Contr
On 2020-06-17 15:45, CodeWiz2280 wrote:
On Tue, Jun 16, 2020 at 2:23 PM Marc Zyngier wrote:
On 2020-06-16 19:13, CodeWiz2280 wrote:
> On Tue, Jun 16, 2020 at 4:11 AM Marc Zyngier wrote:
>>
>> On 2020-06-15 20:14, CodeWiz2280 wrote:
>>
>> [...]
>>
>> > Also, the latest linux kernel still has t
On 17.06.2020 16:49, Tamas K Lengyel wrote:
> On Wed, Jun 17, 2020 at 8:24 AM Jan Beulich wrote:
>>
>> On 17.06.2020 15:43, Tamas K Lengyel wrote:
>>> On Wed, Jun 17, 2020 at 7:36 AM Jan Beulich wrote:
On 17.06.2020 15:31, Tamas K Lengyel wrote:
> On Wed, Jun 17, 2020 at 7:28 AM Jan
On Wed, Jun 17, 2020 at 9:46 AM Jan Beulich wrote:
>
> On 17.06.2020 16:49, Tamas K Lengyel wrote:
> > On Wed, Jun 17, 2020 at 8:24 AM Jan Beulich wrote:
> >>
> >> On 17.06.2020 15:43, Tamas K Lengyel wrote:
> >>> On Wed, Jun 17, 2020 at 7:36 AM Jan Beulich wrote:
>
> On 17.06.2020 15:
On Wed, Jun 17, 2020 at 9:54 AM Tamas K Lengyel
wrote:
>
> On Wed, Jun 17, 2020 at 9:46 AM Jan Beulich wrote:
> >
> > On 17.06.2020 16:49, Tamas K Lengyel wrote:
> > > On Wed, Jun 17, 2020 at 8:24 AM Jan Beulich wrote:
> > >>
> > >> On 17.06.2020 15:43, Tamas K Lengyel wrote:
> > >>> On Wed, Jun
On 17/06/2020 04:02, Tamas K Lengyel wrote:
> On Tue, Jun 16, 2020 at 2:17 PM Andrew Cooper
> wrote:
>> On 16/06/2020 19:47, Michał Leszczyński wrote:
>>> - 16 cze 2020 o 20:17, Andrew Cooper andrew.coop...@citrix.com
>>> napisał(a):
>>>
Are there any restrictions on EPT being enabled i
While forking VMs running a small RTOS system (Zephyr) a Xen crash has been
observed due to a mm-lock order violation while copying the HVM CPU context
from the parent. This issue has been identified to be due to
hap_update_paging_modes first getting a lock on the gfn using get_gfn. This
call also
Hi,
On 16/06/2020 22:24, Stefano Stabellini wrote:
On Tue, 16 Jun 2020, Julien Grall wrote:
From: Julien Grall
Some CPUs can speculate past a RET instruction and potentially perform
speculative accesses to memory before processing the return.
There is no known gadget available after the RET
On Wed, Jun 17, 2020 at 10:19 AM Andrew Cooper
wrote:
>
> On 17/06/2020 04:02, Tamas K Lengyel wrote:
> > On Tue, Jun 16, 2020 at 2:17 PM Andrew Cooper
> > wrote:
> >> On 16/06/2020 19:47, Michał Leszczyński wrote:
> >>> - 16 cze 2020 o 20:17, Andrew Cooper andrew.coop...@citrix.com
> >>> n
flight 151194 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151194/
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
On 17/06/2020 17:27, Tamas K Lengyel wrote:
>> What semantics do you want for the buffer becoming full? Given that
>> debugging/tracing is the goal, I presume "pause vcpu on full" is the
>> preferred behaviour, rather than drop packets on full?
>>
> Right now this is a ring-sty
On 6/16/20 11:14 PM, Souptick Joarder wrote:
> In 2019, we introduced pin_user_pages*() and now we are converting
> get_user_pages*() to the new API as appropriate. [1] & [2] could
> be referred for more information.
>
> [1] Documentation/core-api/pin_user_pages.rst
>
> [2] "Explicit pinning of use
On Wed, 17 Jun 2020, CodeWiz2280 wrote:
> On Tue, Jun 16, 2020 at 2:23 PM Marc Zyngier wrote:
> >
> > On 2020-06-16 19:13, CodeWiz2280 wrote:
> > > On Tue, Jun 16, 2020 at 4:11 AM Marc Zyngier wrote:
> > >>
> > >> On 2020-06-15 20:14, CodeWiz2280 wrote:
> > >>
> > >> [...]
> > >>
> > >> > Also, t
- 17 cze 2020 o 17:14, Andrew Cooper andrew.coop...@citrix.com napisał(a):
> On 17/06/2020 13:51, Roger Pau Monné wrote:
>> On Wed, Jun 17, 2020 at 01:54:45PM +0200, Michał Leszczyński wrote:
>>> - 17 cze 2020 o 11:09, Roger Pau Monné roger@citrix.com napisał(a):
>>>
24 Virtual Ma
- 16 cze 2020 o 19:23, Roger Pau Monné roger@citrix.com napisał(a):
> On Tue, Jun 16, 2020 at 05:22:06PM +0200, Michał Leszczyński wrote:
>> Provide an interface for privileged domains to manage
>> external IPT monitoring.
>>
>> Signed-off-by: Michal Leszczynski
>
> Thanks for the patch
flight 151166 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151166/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-buildfail REGR. vs. 150040
build-i386-pre
On Wed, Jun 17, 2020 at 11:23 AM Andrew Cooper
wrote:
>
> On 17/06/2020 17:27, Tamas K Lengyel wrote:
> >> What semantics do you want for the buffer becoming full? Given that
> >> debugging/tracing is the goal, I presume "pause vcpu on full" is the
> >> preferred behaviour, rather tha
- 17 cze 2020 o 18:27, Tamas K Lengyel tamas.k.leng...@gmail.com napisał(a):
> On Wed, Jun 17, 2020 at 10:19 AM Andrew Cooper
> wrote:
>>
>> On 17/06/2020 04:02, Tamas K Lengyel wrote:
>> > On Tue, Jun 16, 2020 at 2:17 PM Andrew Cooper
>> > wrote:
>> >> On 16/06/2020 19:47, Michał Leszczyńs
- 17 cze 2020 o 18:19, Andrew Cooper andrew.coop...@citrix.com napisał(a):
> On 17/06/2020 04:02, Tamas K Lengyel wrote:
>> On Tue, Jun 16, 2020 at 2:17 PM Andrew Cooper
>> wrote:
>>> On 16/06/2020 19:47, Michał Leszczyński wrote:
- 16 cze 2020 o 20:17, Andrew Cooper andrew.coop...@
Hello Julien,
I have just tried 4.14-rc2 and it seems to work fine.
I think that the most useful page regarding the board is the one for the
Ibox3399 since this refers to the RK3399 chip which the RockPro64 uses
(shouldn't the page actually be called RK3399 to make it more generic).
Perhaps
> > > How does KVM deal with this, do they insert/modify trace packets on
> > > trapped and emulated instructions by the VMM?
> >
> > The KVM includes instruction decoder and
> emulator(arch/x86/kvm/emulate.c), and the guest's memory can be set to
> write-protect as well. But it doesn't support Int
> > On Wed, Jun 17, 2020 at 01:54:45PM +0200, Michał Leszczyński wrote:
> >> - 17 cze 2020 o 11:09, Roger Pau Monné roger@citrix.com napisał(a):
> >>
> >>> 24 Virtual Machine Control Structures -> 24.8 VM-entry Control
> >>> Fields -> 24.8.1 VM-Entry Controls Software should consult the VMX
On Wed, Jun 17, 2020 at 2:46 PM Stefano Stabellini
wrote:
>
> On Wed, 17 Jun 2020, CodeWiz2280 wrote:
> > On Tue, Jun 16, 2020 at 2:23 PM Marc Zyngier wrote:
> > >
> > > On 2020-06-16 19:13, CodeWiz2280 wrote:
> > > > On Tue, Jun 16, 2020 at 4:11 AM Marc Zyngier wrote:
> > > >>
> > > >> On 2020-
- 18 cze 2020 o 1:29, Kang, Luwei luwei.k...@intel.com napisał(a):
>> > > How does KVM deal with this, do they insert/modify trace packets on
>> > > trapped and emulated instructions by the VMM?
>> >
>> > The KVM includes instruction decoder and
>> emulator(arch/x86/kvm/emulate.c), and the gue
From: Boris Ostrovsky
[ Upstream commit c54b071c192dfe8061336f650ceaf358e6386e0b ]
Commit a926f81d2f6c ("xen/cpuhotplug: Replace cpu_up/down() with
device_online/offline()") replaced cpu_down() with device_offline()
call which requires that the CPU has been registered before. This
registration,
On Tue, 16 Jun 2020, Julien Grall wrote:
> On Tue, 16 Jun 2020 at 21:57, Stefano Stabellini
> wrote:
> >
> > On Tue, 16 Jun 2020, Julien Grall wrote:
> > > On 16/06/2020 02:00, Stefano Stabellini wrote:
> > > > On Sat, 13 Jun 2020, Julien Grall wrote:
> > > > > From: Julien Grall
> > > > >
> > >
flight 151170 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151170/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 151016
test-amd64-amd64-xl-qemuu-win7-amd64
Hi Jan,
Jan Beulich writes:
> On 12.06.2020 02:22, Volodymyr Babchuk wrote:
>> In most cases hypervisor code performs guest-related jobs. Tasks like
>> hypercall handling or MMIO access emulation are done for calling vCPU
>> so it is okay to charge time spent in hypervisor to the current vCPU.
Hi Jürgen,
Jürgen Groß writes:
> On 13.06.20 00:27, Volodymyr Babchuk wrote:
>> On Fri, 2020-06-12 at 17:29 +0200, Dario Faggioli wrote:
>>> On Fri, 2020-06-12 at 14:41 +0200, Jürgen Groß wrote:
On 12.06.20 14:29, Julien Grall wrote:
> On 12/06/2020 05:57, Jürgen Groß wrote:
>> On 1
> >> +
> >> +a.mfn = v->arch.hvm.vmx.ipt_state->output_base >> PAGE_SHIFT;
> >
> > This will not work for translated domains, ie: a PVH or HVM domain
> > won't be able to use this interface since it has no way to request the
> > mapping of a specific mfn into it's physmap. I think we need t
On 6/4/20 6:31 PM, Stefano Stabellini wrote:
> On Thu, 4 Jun 2020, Oleksandr Andrushchenko wrote:
>> On 6/4/20 4:57 AM, Peng Fan wrote:
>>> Grall ;
Nataliya Korovkina
Subject: UEFI support in ARM DomUs
>>> We have made U-Boot run inside XEN DomU, but just only PV console part,
>>> not i
On 17.06.2020 18:19, Tamas K Lengyel wrote:
> While forking VMs running a small RTOS system (Zephyr) a Xen crash has been
> observed due to a mm-lock order violation while copying the HVM CPU context
> from the parent. This issue has been identified to be due to
> hap_update_paging_modes first gett
On 18.06.2020 04:50, Volodymyr Babchuk wrote:
> Anyways, are you okay with the general approach? We will work out the
> details, but I want to be sure that I'm moving in the right direction.
I'm certainly okay with the goal; I didn't look closely enough to say
I'm okay with the approach - I trust
* Guests outside of long mode can't have PCID enabled. Drop the
respective check to make more obvious that there's no security issue
(from potentially accessing past the mapped page's boundary).
* Only the low 32 bits of CR3 are relevant outside of long mode, even
if they remained unchanged
88 matches
Mail list logo
