On Wed, 2020-01-22 at 14:57 +, Andrew Cooper wrote:
> On 22/01/2020 01:58, Bobby Eshleman wrote:
> > Hey everybody,
> >
> > This is an RFC patchset for the very beginnings of adding RISC-V
> > support
> > to Xen. This RFC is really just to start a dialogue about
> > supporting
> > RISC-V and
Hi
Am 21.01.20 um 10:36 schrieb Gerd Hoffmann:
> On Mon, Jan 20, 2020 at 01:20:47PM +0100, Thomas Zimmermann wrote:
>> Instead of faking VBLANK events by themselves, drivers without VBLANK
>> support can enable drm_crtc_vblank.no_vblank and let DRM do the rest.
>> The patchset makes this official
Currently the memory for each run-queue of the credit2 scheduler is
allocated at the scheduler's init function: for each cpu in the system
a struct csched2_runqueue_data is being allocated, even if the
current scheduler only handles one physical cpu or is configured to
work with a single run-queue.
There are still several instances of cpumask_t on the stack in
scheduling code. Avoid them as far as possible.
Signed-off-by: Juergen Gross
---
xen/common/sched/core.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/xen/common/sched/core.c b/xen/common/sched/co
Hi,
On Fri, Jan 17, 2020 at 02:13:04PM -0500, Rich Persaud wrote:
>On Aug 26, 2019, at 17:08, Pasi Kärkkäinen wrote:
>
> Hi,
> On Mon, Oct 08, 2018 at 10:32:45AM -0400, Boris Ostrovsky wrote:
>
>On 10/3/18 11:51 AM, Pasi Kärkkäinen wrote:
>
> On Wed, Sep 19, 2018
The atomic helpers automatically send out fake VBLANK events if no
vblanking has been initialized. Remove the sending code from the
driver.
v4:
* separate commit from core vblank changes
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/cirrus/cirrus.c | 8 --
The atomic helpers automatically send out fake VBLANK events if no
vblanking has been initialized. Remove the sending code from the
driver.
v4:
* separate commit from core vblank changes
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/vboxvideo/vbox_mode.c
The atomic helpers automatically send out fake VBLANK events if no
vblanking has been initialized. Remove the sending code from the
driver.
v4:
* separate commit from core vblank changes
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 14
The atomic helpers automatically send out fake VBLANK events if no
vblanking has been initialized. Remove the sending code from the
driver.
v4:
* separate commit from core vblank changes
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/tiny/gm12u320.c | 9 --
As ast does not initialize vblanking, atomic helpers initialize the
value of struct drm_crtc_state.no_vblank to be true. No need to set
it from within the driver.
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/ast/ast_mode.c | 2 --
1 file changed, 2 deletions(-)
The atomic helpers automatically send out fake VBLANK events if no
vblanking has been initialized. Remove the sending code from the
driver.
v4:
* separate commit from core vblank changes
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/drm_mipi_dbi.c | 9 ---
At the end of a commit, atomic helpers can generate a VBLANK event
automatically. Originally implemented for writeback connectors, the
functionality can be used by any driver and/or hardware without proper
VBLANK interrupt.
The patch updates the documentation to make this behaviour official:
setti
The atomic helpers automatically send out fake VBLANK events if no
vblanking has been initialized. Remove the sending code from the
driver.
v4:
* separate commit from core vblank changes
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs_kms.c | 9
Instead of faking VBLANK events by themselves, drivers without VBLANK
support can enable drm_crtc_vblank.no_vblank and let DRM do the rest.
The patchset makes this official and converts over drivers.
The current implementation looks at state of a device wrt vblanking. If
vblanking has been initial
As udl does not initialize vblanking, atomic helpers initialize the
value of struct drm_crtc_state.no_vblank to be true. No need to set
it from within the driver.
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/udl/udl_modeset.c | 11 ---
1 file changed, 11
The atomic helpers automatically send out fake VBLANK events if no
vblanking has been initialized. Remove the sending code from the
driver.
v4:
* separate commit from core vblank changes
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_display
The atomic helpers automatically send out fake VBLANK events if no
vblanking has been initialized. Remove the sending code from the
driver.
v4:
* separate commit from core vblank changes
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/tiny/ili9225.c | 9 ---
The atomic helpers automatically send out fake VBLANK events if no
vblanking has been initialized. Remove the sending code from the
driver.
v4:
* separate commit from core vblank changes
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/arc/arcpgu_crtc.c | 16
The atomic helpers automatically send out fake VBLANK events if no
vblanking has been initialized. Remove the sending code from the
driver.
v4:
* separate commit from core vblank changes
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/tiny/st7586.c | 9
The atomic helpers automatically send out fake VBLANK events if no
vblanking has been initialized. This would apply to xen, but xen has
its own vblank logic. To avoid interfering with the atomic helpers,
disable automatic vblank events explictly.
v4:
* separate commit from core vblank chan
The atomic helpers automatically send out fake VBLANK events if no
vblanking has been initialized. Remove the sending code from the
driver.
v4:
* separate commit from core vblank changes
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/tiny/repaper.c | 9 ---
> -Original Message-
>
> People allowed to vote on behalf of the Hypervisor project are:
> Julien Grall, Andy Cooper, George Dunlap, Ian Jackson, Jan Beulich, Konrad
> R
> Wilk, Stefano Stabellini, Wei Liu and Paul Durrant (as Release Manager).
+1
>
> People allowed to vote on behalf of
On 22.01.2020 22:31, Andrew Cooper wrote:
> On 22/01/2020 20:23, Wei Liu wrote:
>> --- a/xen/arch/x86/e820.c
>> +++ b/xen/arch/x86/e820.c
>> + */
>> +unsigned int phys_bits = find_phys_addr_bits();
>> +unsigned long hcall_pfn =
>> + ((1ull << phys_bits) - 1) >> PAGE_SHI
On 22.01.2020 22:57, Andrew Cooper wrote:
> On 22/01/2020 20:23, Wei Liu wrote:
>> These functions will be used later to make hypercalls to Hyper-V.
>>
>> Signed-off-by: Wei Liu
>
> After some experimentation,
>
> diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> index cbc5701214..3
On 22.01.2020 23:30, Eslam Elnikety wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -2134,7 +2134,12 @@ logic applies:
> ### ucode (x86)
> > `= List of [ | scan=, nmi= ]`
>
> -Specify how and where to find CPU microcode update blob.
> +Applic
On 22.01.2020 23:30, Eslam Elnikety wrote:
> Decouple the microcode indexing mechanism when using GRUB to that
> when using EFI. This allows us to avoid the "unspecified effect" of
> using `` when booting via EFI.
Personally I'd prefer us to continue call this unspecified. It
simply shouldn't be u
On 22.01.2020 23:30, Eslam Elnikety wrote:
> When using `ucode=scan` and if a matching module is found, the microcode
> payload is maintained in an xmalloc()'d region. This is unnecessary since
> the bootmap would just do. Remove the xmalloc and xfree on the microcode
> module scan path.
>
> This
Hi Boqun Feng,
sorry for the late reply.
On 16/12/2019 00:19, Boqun Feng wrote:
> Hi,
>
> This is the RFC patchset for vDSO support in ARM64 Hyper-V guest. To
> test it, Michael's ARM64 support patchset:
>
>
> https://lore.kernel.org/linux-arm-kernel/1570129355-16005-1-git-send-email-mik
On 22.01.2020 21:23, Wei Liu wrote:
> This allows us to set aside some address space for executable mapping.
> This fixed map range starts from XEN_VIRT_END so that it is within reach
> of the .text section.
>
> Shift the percpu stub range and livepatch range accordingly.
Hmm, the livepatch range
On 22.01.2020 21:23, Wei Liu wrote:
> --- a/xen/arch/x86/e820.c
> +++ b/xen/arch/x86/e820.c
> @@ -36,6 +36,22 @@ boolean_param("e820-verbose", e820_verbose);
> struct e820map e820;
> struct e820map __initdata e820_raw;
>
> +static unsigned int find_phys_addr_bits(void)
> +{
> +uint32_t eax;
On 22.01.2020 21:23, Wei Liu wrote:
> --- /dev/null
> +++ b/xen/include/asm-x86/guest/hyperv-hcall.h
> @@ -0,0 +1,98 @@
> +/**
> + * asm-x86/guest/hyperv-hcall.h
> + *
> + * This program is free software; you can redistribu
On 22/01/2020 11:25, Julien Grall wrote:
>
>
> On 22/01/2020 11:19, Sergey Dyasli wrote:
>> On 22/01/2020 10:14, Julien Grall wrote:
>>>
>>>
>>> On 22/01/2020 10:01, Sergey Dyasli wrote:
On 20/01/2020 10:01, Jan Beulich wrote:
> On 17.01.2020 17:44, Sergey Dyasli wrote:
>> v2 --> v3:
>
flight 146415 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146415/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
With non-empty CONFIG_DOM0_MEM clang5 produces
dom0_build.c:344:24: error: use of logical '&&' with constant operand
[-Werror,-Wconstant-logical-operand]
if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] )
^ ~~
dom0_build.c:344:24: note: use '&' for a bitwise op
In order to avoid permanently having to ask that no new command line
options using underscores be introduced (albeit I'm likely to still make
remarks), and in order to also allow extending the use of hyphens to
pre-existing ones, introduce custom comparison functions treating both
characters as mat
1: fix PoD accounting in guest_physmap_add_entry()
2: adjust non-PoD accounting in p2m_pod_decrease_reservation()
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Throughout the function the equation
pod + nonpod == (1UL << order)
should hold. This has been violated by the final loop of the function:
* changing a range from a type other than p2m_populate_on_demand to
p2m_invalid doesn't alter the amount of non-PoD pages in the region,
* changing
The initial observation was that the mfn_valid() check comes too late:
Neither mfn_add() nor mfn_to_page() (let alone de-referencing the
result of the latter) are valid for MFNs failing this check. Move it up
and - noticing that there's no caller doing so - also add an assertion
that this should ne
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 23 January 2020 11:43
> To: xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Julien Grall
> ; Wei Liu ; Konrad Wilk
> ; George Dunlap ;
> Andrew Cooper ; Ian Jackson
>
> Subject: [Xen-devel] [PATCH v2] cmdl
flight 146412 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146412/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
test-amd64-amd64-xl-qemuu
Paul Durrant (3):
x86 / vmx: make apic_access_mfn type-safe
x86 / hvm: add domain_relinquish_resources() method
x86 / vmx: use a 'normal' domheap page for APIC_DEFAULT_PHYS_BASE
xen/arch/x86/hvm/hvm.c | 7 +-
xen/arch/x86/hvm/mtrr.c| 2 +-
xen/arch/x86/hvm/svm/
Use mfn_t rather than unsigned long and change previous tests against 0 to
tests against INVALID_MFN (also introducing initialization to that value).
Signed-off-by: Paul Durrant
Acked-by: Kevin Tian
Reviewed-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
Cc: Jun Naka
There are two functions in hvm.c to deal with tear-down and a domain:
hvm_domain_relinquish_resources() and hvm_domain_destroy(). However, only
the latter has an associated method in 'hvm_funcs'. This patch adds
a method for the former.
A subsequent patch will define a VMX implementation.
Signed-
vmx_alloc_vlapic_mapping() currently contains some very odd looking code
that allocates a MEMF_no_owner domheap page and then shares with the guest
as if it were a xenheap page. This then requires vmx_free_vlapic_mapping()
to call a special function in the mm code: free_shared_domheap_page().
By u
On 1/17/20 1:31 PM, Alexandru Stefan ISAILA wrote:
> This patch aims to sanitize indexes, potentially guest provided
> values, for altp2m_eptp[] and altp2m_p2m[] arrays.
>
> Requested-by: Jan Beulich
> Signed-off-by: Alexandru Isaila
> Acked-by: Tamas K Lengyel
Acked-by: George Dunlap
__
Hi,
On 17/01/2020 21:24, Jeff Kubascik wrote:
On 12/18/2019 9:20 AM, Julien Grall wrote:
Hi Jeff,
On 11/12/2019 21:13, Jeff Kubascik wrote:
The physical timer traps apply an offset so that time starts at 0 for
the guest. However, this offset is not currently applied to the physical
counter. P
Hi,
On 21/01/2020 15:07, Jeff Kubascik wrote:
Xen will only store the CompareValue as it can be derived from the
TimerValue (ARM DDI 0487E.a section D11.2.4):
CompareValue = (Counter[63:0] + SignExtend(TimerValue))[63:0]
While the TimerValue is a 32-bit signed value, our implementation
assu
On Tue, Jan 21, 2020 at 03:34:13AM +, Tian, Kevin wrote:
> > From: Roger Pau Monné
> > Sent: Monday, January 20, 2020 6:19 PM
> >
> > On Sun, Jan 19, 2020 at 04:15:04AM +, Tian, Kevin wrote:
> > > > From: Roger Pau Monne
> > > > Sent: Wednesday, January 8, 2020 6:39 PM
> > > >
> > > > Wh
Hi,
On 21/01/2020 15:07, Jeff Kubascik wrote:
The physical timer traps apply an offset so that time starts at 0 for
the guest. However, this offset is not currently applied to the physical
counter. Per the ARMv8 Reference Manual (ARM DDI 0487E.a), section
D11.2.4 Timers, the "Offset" between the
On 1/17/20 1:31 PM, Alexandru Stefan ISAILA wrote:
> By default the sve bits are not set.
> This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
> to set a range of sve bits.
> The core function, p2m_set_suppress_ve_multi(), does not break in case
> of a error and it is doing a best e
On 1/17/20 1:31 PM, Alexandru Stefan ISAILA wrote:
> No functional changes.
>
> Requested-by: Jan Beulich
> Signed-off-by: Alexandru Isaila
> Reviewed-by: Jan Beulich
Acked-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 23.01.2020 13:21, Paul Durrant wrote:
> Use mfn_t rather than unsigned long and change previous tests against 0 to
> tests against INVALID_MFN (also introducing initialization to that value).
>
> Signed-off-by: Paul Durrant
> Acked-by: Kevin Tian
> Reviewed-by: Jan Beulich
No, this isn't wh
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 23 January 2020 12:45
> To: Durrant, Paul
> Cc: Kevin Tian ; Wei Liu ; Andrew Cooper
> ; Jun Nakajima ; xen-
> de...@lists.xenproject.org; Roger Pau Monné
> Subject: Re: [Xen-devel] [PATCH v2 1/3] x86 / vmx: make a
On 23.01.2020 13:11, Durrant, Paul wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 23 January 2020 11:43
>> To: xen-devel@lists.xenproject.org
>> Cc: Stefano Stabellini ; Julien Grall
>> ; Wei Liu ; Konrad Wilk
>> ; George Dunlap ;
>> Andrew Cooper ; Ia
On 23.01.2020 14:09, Durrant, Paul wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 23 January 2020 12:45
>> To: Durrant, Paul
>> Cc: Kevin Tian ; Wei Liu ; Andrew Cooper
>> ; Jun Nakajima ; xen-
>> de...@lists.xenproject.org; Roger Pau Monné
>> Subjec
flight 146416 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146416/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
> -Original Message-
> From: Jan Beulich
> Sent: 23 January 2020 13:30
> To: Durrant, Paul
> Cc: Kevin Tian ; Wei Liu ; Andrew Cooper
> ; Jun Nakajima ; xen-
> de...@lists.xenproject.org; Roger Pau Monné
> Subject: Re: [PATCH v2 1/3] x86 / vmx: make apic_access_mfn type-safe
>
> On 23.0
flight 146408 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146408/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install
fail REGR. vs. 146058
Paul Durrant (3):
x86 / vmx: make apic_access_mfn type-safe
x86 / hvm: add domain_relinquish_resources() method
x86 / vmx: use a 'normal' domheap page for APIC_DEFAULT_PHYS_BASE
xen/arch/x86/hvm/hvm.c | 7 +-
xen/arch/x86/hvm/mtrr.c| 2 +-
xen/arch/x86/hvm/svm/
There are two functions in hvm.c to deal with tear-down and a domain:
hvm_domain_relinquish_resources() and hvm_domain_destroy(). However, only
the latter has an associated method in 'hvm_funcs'. This patch adds
a method for the former.
A subsequent patch will define a VMX implementation.
Signed-
Use mfn_t rather than unsigned long and change previous tests against 0 to
tests against INVALID_MFN (also introducing initialization to that value).
Signed-off-by: Paul Durrant
Acked-by: Kevin Tian
Reviewed-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
Cc: Jun Naka
vmx_alloc_vlapic_mapping() currently contains some very odd looking code
that allocates a MEMF_no_owner domheap page and then shares with the guest
as if it were a xenheap page. This then requires vmx_free_vlapic_mapping()
to call a special function in the mm code: free_shared_domheap_page().
By u
On 1/17/20 1:31 PM, Alexandru Stefan ISAILA wrote:
> At this moment the default_access param from xc_altp2m_create_view is
> not used.
>
> This patch assigns default_access to p2m->default_access at the time of
> initializing a new altp2m view.
>
> Signed-off-by: Alexandru Isaila
> Acked-by: Jan
On 1/22/20 11:44 AM, Sergey Dyasli wrote:
> On 22/01/2020 10:57, George Dunlap wrote:
>> On 1/22/20 10:14 AM, Julien Grall wrote:
>>>
>>>
>>> On 22/01/2020 10:01, Sergey Dyasli wrote:
On 20/01/2020 10:01, Jan Beulich wrote:
> On 17.01.2020 17:44, Sergey Dyasli wrote:
>> v2 --> v3:
Hi,
On 23/01/2020 11:32, Sergey Dyasli wrote:
On 22/01/2020 11:25, Julien Grall wrote:
On 22/01/2020 11:19, Sergey Dyasli wrote:
On 22/01/2020 10:14, Julien Grall wrote:
On 22/01/2020 10:01, Sergey Dyasli wrote:
On 20/01/2020 10:01, Jan Beulich wrote:
On 17.01.2020 17:44, Sergey Dyasli
On 1/23/20 2:42 PM, Julien Grall wrote:
> Hi,
>
> On 23/01/2020 11:32, Sergey Dyasli wrote:
>> On 22/01/2020 11:25, Julien Grall wrote:
>>>
>>>
>>> On 22/01/2020 11:19, Sergey Dyasli wrote:
On 22/01/2020 10:14, Julien Grall wrote:
>
>
> On 22/01/2020 10:01, Sergey Dyasli wrote:
>>
On 1/23/20 2:03 PM, Paul Durrant wrote:
> vmx_alloc_vlapic_mapping() currently contains some very odd looking code
> that allocates a MEMF_no_owner domheap page and then shares with the guest
> as if it were a xenheap page. This then requires vmx_free_vlapic_mapping()
> to call a special function i
Hi,
On 23/01/2020 14:45, George Dunlap wrote:
On 1/23/20 2:42 PM, Julien Grall wrote:
Hi,
On 23/01/2020 11:32, Sergey Dyasli wrote:
On 22/01/2020 11:25, Julien Grall wrote:
On 22/01/2020 11:19, Sergey Dyasli wrote:
On 22/01/2020 10:14, Julien Grall wrote:
On 22/01/2020 10:01, Sergey Dy
On 1/23/20 2:52 PM, Julien Grall wrote:
> Hi,
>
> On 23/01/2020 14:45, George Dunlap wrote:
>> On 1/23/20 2:42 PM, Julien Grall wrote:
>>> Hi,
>>>
>>> On 23/01/2020 11:32, Sergey Dyasli wrote:
On 22/01/2020 11:25, Julien Grall wrote:
>
>
> On 22/01/2020 11:19, Sergey Dyasli wrote:
On 23.01.2020 15:52, Julien Grall wrote:
> Therefore, they will have to accept whatever string is reported by
> HVMLoader (or Xen). As you already allow Xen to configure it, why would
> that be a problem to change the one in Kconfig? Why do you need to fix
> it up in hvmloader as well?
Because,
On 23.01.2020 15:03, Paul Durrant wrote:
> There are two functions in hvm.c to deal with tear-down and a domain:
> hvm_domain_relinquish_resources() and hvm_domain_destroy(). However, only
> the latter has an associated method in 'hvm_funcs'. This patch adds
> a method for the former.
>
> A subseq
From: Jan Beulich Sent: Thursday, January 23, 2020 3:19 AM
>
> On 22.01.2020 21:23, Wei Liu wrote:
> > --- a/xen/arch/x86/e820.c
> > +++ b/xen/arch/x86/e820.c
> > @@ -36,6 +36,22 @@ boolean_param("e820-verbose", e820_verbose);
> > struct e820map e820;
> > struct e820map __initdata e820_raw;
> >
On 23/01/2020 14:03, Paul Durrant wrote:
diff --git a/xen/common/domain.c b/xen/common/domain.c
index ee3f9ffd3e..30c777acb8 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -339,6 +339,8 @@ static int sanitise_domain_config(struct
xen_domctl_createdomain *config)
return arc
On 23.01.2020 15:03, Paul Durrant wrote:
> vmx_alloc_vlapic_mapping() currently contains some very odd looking code
> that allocates a MEMF_no_owner domheap page and then shares with the guest
> as if it were a xenheap page. This then requires vmx_free_vlapic_mapping()
> to call a special function
On 1/22/20 4:55 PM, Jan Beulich wrote:
> On 22.01.2020 17:51, Tamas K Lengyel wrote:
>> On Wed, Jan 22, 2020 at 8:23 AM Jan Beulich wrote:
>>>
>>> On 21.01.2020 18:49, Tamas K Lengyel wrote:
The owner domain of shared pages is dom_cow, use that for get_page
otherwise the function fails t
On 23/01/2020 14:03, Paul Durrant wrote:
> Use mfn_t rather than unsigned long and change previous tests against 0 to
> tests against INVALID_MFN (also introducing initialization to that value).
>
> Signed-off-by: Paul Durrant
> Acked-by: Kevin Tian
> Reviewed-by: Jan Beulich
> ---
> Cc: Andrew
On Tue, Jan 21, 2020 at 10:21:09AM +, Roger Pau Monné wrote:
> The issue is that this change is passing the guest domain_create_state
> to libxl__domain_build in libxl__spawn_stub_dm, and hence the
> stubdomain doesn't get created. I have the following patch that fixes
> it, but it's kind of di
On 1/23/20 3:32 PM, Jan Beulich wrote:
> On 23.01.2020 15:03, Paul Durrant wrote:
>> vmx_alloc_vlapic_mapping() currently contains some very odd looking code
>> that allocates a MEMF_no_owner domheap page and then shares with the guest
>> as if it were a xenheap page. This then requires vmx_free_vl
On Fri, Jan 17, 2020 at 05:25:12PM +0100, Jan Beulich wrote:
> On 17.01.2020 17:08, Roger Pau Monné wrote:
> > On Fri, Jan 17, 2020 at 04:56:00PM +0100, Jan Beulich wrote:
> >> On 17.01.2020 16:09, Roger Pau Monne wrote:
> >>> The Intel SDM states:
> >>>
> >>> "When an illegal vector value (0 to 15
On 22.01.2020 21:23, Wei Liu wrote:
> --- a/xen/arch/x86/guest/hyperv/hyperv.c
> +++ b/xen/arch/x86/guest/hyperv/hyperv.c
> @@ -27,7 +27,10 @@
> #include
> #include
>
> +#include "private.h"
> +
> struct ms_hyperv_info __read_mostly ms_hyperv;
> +DEFINE_PER_CPU_READ_MOSTLY(void *, hv_pcpu_in
> -Original Message-
> From: Julien Grall
> Sent: 23 January 2020 15:26
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
> ; George Dunlap ; Ian
> Jackson ; Konrad Rzeszutek Wilk
> ; Stefano Stabellini ; Jun
> Nakajima ; K
On 23/01/2020 15:46, Durrant, Paul wrote:
-Original Message-
From: Julien Grall
Sent: 23 January 2020 15:26
To: Durrant, Paul ; xen-devel@lists.xenproject.org
Cc: Jan Beulich ; Andrew Cooper
; Wei Liu ; Roger Pau Monné
; George Dunlap ; Ian
Jackson ; Konrad Rzeszutek Wilk
; Stefano Sta
On 22.01.2020 21:23, Wei Liu wrote:
> This will be useful when invoking hypercall that targets specific
> vcpu(s).
>
> Signed-off-by: Wei Liu
> Reviewed-by: Paul Durrant
For formal reasons
Acked-by: Jan Beulich
However I wonder whether the Viridian entry in MAINTAINERS shouldn't
be extended b
On Thu, Jan 23, 2020 at 8:32 AM George Dunlap wrote:
>
> On 1/22/20 4:55 PM, Jan Beulich wrote:
> > On 22.01.2020 17:51, Tamas K Lengyel wrote:
> >> On Wed, Jan 22, 2020 at 8:23 AM Jan Beulich wrote:
> >>>
> >>> On 21.01.2020 18:49, Tamas K Lengyel wrote:
> The owner domain of shared pages i
On 1/23/20 3:46 PM, Durrant, Paul wrote:
>> -Original Message-
>> From: Julien Grall
>> Sent: 23 January 2020 15:26
>> To: Durrant, Paul ; xen-devel@lists.xenproject.org
>> Cc: Jan Beulich ; Andrew Cooper
>> ; Wei Liu ; Roger Pau Monné
>> ; George Dunlap ; Ian
>> Jackson ; Konrad Rzeszutek
On 22.01.2020 21:23, Wei Liu wrote:
> @@ -142,15 +143,40 @@ static void setup_hypercall_pcpu_arg(void)
> this_cpu(hv_vp_index) = vp_index_msr;
> }
>
> +static void setup_vp_assist(void)
> +{
> +void *mapping;
> +uint64_t val;
> +
> +mapping = this_cpu(hv_vp_assist);
> +
> +i
On 1/21/20 5:49 PM, Tamas K Lengyel wrote:
> During VM forking the client lock will already be taken.
>
> Signed-off-by: Tamas K Lengyel
> Acked-by: Andrew Coopers
Acked-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
htt
On 1/21/20 5:49 PM, Tamas K Lengyel wrote:
> All callers pass 0 in.
>
> Signed-off-by: Tamas K Lengyel
> Reviewed-by: Wei Liu
Acked-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/list
> -Original Message-
> From: Jan Beulich
> Sent: 23 January 2020 15:32
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
> ; George Dunlap ; Ian
> Jackson ; Julien Grall ; Konrad
> Rzeszutek Wilk ; Stefano Stabellini
> ; Jun Nakajima ; K
On 23.01.2020 16:43, Roger Pau Monné wrote:
> On Fri, Jan 17, 2020 at 05:25:12PM +0100, Jan Beulich wrote:
>> On 17.01.2020 17:08, Roger Pau Monné wrote:
>>> On Fri, Jan 17, 2020 at 04:56:00PM +0100, Jan Beulich wrote:
On 17.01.2020 16:09, Roger Pau Monne wrote:
> The Intel SDM states:
>>>
On 1/21/20 5:49 PM, Tamas K Lengyel wrote:
> Create struct mem_sharing_domain under hvm_domain and move mem sharing
> variables into it from p2m_domain and hvm_domain.
>
> Expose the mem_sharing_enabled macro to be used consistently across Xen.
>
> Remove some duplicate calls to mem_sharing_enabl
On 23/01/2020 05:19, Bobby Eshleman wrote:
> On Wed, Jan 22, 2020 at 02:57:47PM +, Andrew Cooper wrote:
>> How much time do you have to put towards the port? Is this something in
>> your free time, or something you are doing as part of work? Ultimately,
>> we are going to need to increase the
On 23.01.2020 16:56, Durrant, Paul wrote:
>> From: Jan Beulich
>> Sent: 23 January 2020 15:32
>>
>> On 23.01.2020 15:03, Paul Durrant wrote:
>>> vmx_alloc_vlapic_mapping() currently contains some very odd looking code
>>> that allocates a MEMF_no_owner domheap page and then shares with the
>> gues
flight 146418 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146418/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
On 1/21/20 5:49 PM, Tamas K Lengyel wrote:
> MEM_SHARING_DESTROY_GFN is used on the 'flags' bitfield during unsharing.
> However, the bitfield is not used for anything else, so just convert it to a
> bool instead.
>
> Signed-off-by: Tamas K Lengyel
> Reviewed-by: Jan Beulich
But is there a part
On 23/01/2020 11:42, Jan Beulich wrote:
> In order to avoid permanently having to ask that no new command line
> options using underscores be introduced (albeit I'm likely to still make
> remarks), and in order to also allow extending the use of hyphens to
> pre-existing ones, introduce custom comp
On Thu, Jan 23, 2020 at 9:14 AM George Dunlap wrote:
>
> On 1/21/20 5:49 PM, Tamas K Lengyel wrote:
> > MEM_SHARING_DESTROY_GFN is used on the 'flags' bitfield during unsharing.
> > However, the bitfield is not used for anything else, so just convert it to a
> > bool instead.
> >
> > Signed-off-by
On 1/22/20 3:07 PM, Anchal Agarwal wrote:
>> In this case tsc_verify_tsc_adjust(true) this does nothing as
>> feature bit X86_FEATURE_TSC_ADJUST is not available to guest.
Is it not available to your specific guest? Because AFAICT it is
available in general (to HVM/PVH guests).
> 4. Also, th
On 1/23/20 4:23 PM, Tamas K Lengyel wrote:
> On Thu, Jan 23, 2020 at 9:14 AM George Dunlap
> wrote:
>>
>> On 1/21/20 5:49 PM, Tamas K Lengyel wrote:
>>> MEM_SHARING_DESTROY_GFN is used on the 'flags' bitfield during unsharing.
>>> However, the bitfield is not used for anything else, so just conve
On 23.01.2020 17:32, George Dunlap wrote:
> On 1/23/20 4:23 PM, Tamas K Lengyel wrote:
>> On Thu, Jan 23, 2020 at 9:14 AM George Dunlap
>> wrote:
>>>
>>> On 1/21/20 5:49 PM, Tamas K Lengyel wrote:
MEM_SHARING_DESTROY_GFN is used on the 'flags' bitfield during unsharing.
However, the bit
1 - 100 of 143 matches
Mail list logo
