On the 2019 Xen developer summit there was agreement that the Xen
hypervisor should gain support for a hierarchical name-value store
similar to the Linux kernel's sysfs.
In the beginning there should only be basic support: entries can be
added from the hypervisor itself only, there is a simple hyp
Provide version and compile information in /buildinfo/ node of the
Xen hypervisor file system. As this information is accessible by dom0
only no additional security problem arises.
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
V3:
- new patch
V4:
- add __read_mostly annotations (Jan
On the 2019 Xen developer summit there was agreement that the Xen
hypervisor should gain support for a hierarchical name-value store
similar to the Linux kernel's sysfs.
This is a first implementation of that idea adding the basic
functionality to hypervisor and tools side. The interface to any
us
Add the xenfs tool for accessing the hypervisor filesystem.
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
V1:
- rename to xenhypfs
- don't use "--" for subcommands
- add write support
V2:
- escape non-printable characters per default with cat subcommand
(Ian Jackson)
- add -b option to c
Add support to read and modify values of hypervisor runtime parameters
via the hypervisor file system.
As runtime parameters can be modified via a sysctl, too, this path has
to take the hypfs rw_lock as writer.
For custom runtime parameters the resulting parameter value needs to
be stored in a st
Add the infrastructure for the hypervisor filesystem.
This includes the hypercall interface and the base functions for
entry creation, deletion and modification.
In order not to have to repeat the same pattern multiple times in case
adding a new node should BUG_ON() failure, the helpers for addin
Add the new library libxenhypfs for access to the hypervisor filesystem.
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
V1:
- rename to libxenhypfs
- add xenhypfs_write()
V3:
- major rework due to new hypervisor interface
- add decompression capability
V4:
- add dependency to libz in pkgco
Add a new script xen/tools/binfile for including a binary file at build
time being usable via a pointer and a size variable in the hypervisor.
Make use of that generic tool in xsm.
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
V3:
- new patch
V4:
- add alignment parameter (Jan Beul
Add the /buildinfo/config entry to the hypervisor filesystem. This
entry contains the .config file used to build the hypervisor.
Signed-off-by: Juergen Gross
---
V3:
- store data in gzip format
- use binfile mechanism to create data file
- move code to kernel.c
---
.gitignore |
This is controlling Xen behavior alone, after all.
Reported-by: Jin Nan Wang
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -98,8 +98,6 @@ static int __init parse_spec_ctrl(const
if ( opt_pv_l1tf_domu < 0 )
opt_pv_l1tf_d
On 18.02.2020 22:45, Andrew Cooper wrote:
> On 18/02/2020 18:43, Jason Andryuk wrote:
>> On Mon, Feb 17, 2020, 8:22 PM Andrew Cooper
>> wrote:
>>> On 17/02/2020 20:41, Jason Andryuk wrote:
On Mon, Feb 17, 2020 at 2:46 PM Andrew Cooper
wrote:
> On 17/02/2020 19:19, Jason Andryuk wr
On 19.02.2020 06:35, Jürgen Groß wrote:
> On 18.02.20 22:03, Thomas Gleixner wrote:
>> Juergen Gross writes:
>>> Commit 111e7b15cf10f6 ("x86/ioperm: Extend IOPL config to control
>>> ioperm() as well") reworked the iopl syscall to use I/O bitmaps.
>>>
>>> Unfortunately this broke Xen PV domains us
At this moment a guest can call vmfunc to change the altp2m view. This
should be limited in order to avoid any unwanted view switch.
The new xc_altp2m_set_visibility() solves this by making views invisible
to vmfunc.
This is done by having a separate arch.altp2m_working_eptp that is
populated and
Jürgen Groß writes:
> On 18.02.20 22:03, Thomas Gleixner wrote:
>> BTW, why isn't stuff like this not catched during next or at least
>> before the final release? Is nothing running CI on upstream with all
>> that XEN muck active?
>
> This problem showed up by not being able to start the X server
On 19.02.20 10:22, Thomas Gleixner wrote:
Jürgen Groß writes:
On 18.02.20 22:03, Thomas Gleixner wrote:
BTW, why isn't stuff like this not catched during next or at least
before the final release? Is nothing running CI on upstream with all
that XEN muck active?
This problem showed up by not
A domid is considered recent if the domain it represents was destroyed
less than a specified number of seconds ago. For debugging and/or testing
purposes the number can be set using the environment variable
LIBXL_DOMID_REUSE_TIMEOUT. If the variable does not exist then a default
value of 60s is use
A subsequent patch will modify libxl to allow selection of a random domid
value when creating domains. Valid values are limited to a width of 15 bits,
so add an appropriate mask definition to the public header.
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Some code-paths use values other than INVALID_DOMID to indicate an invalid
domain id. Specifically, xl will pass a value of 0 when creating/restoring
a domain. Therefore modify libxl__logv() to use libxl_domid_valid_guest()
as a validity test.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc:
This patch adds a '-D' command line option to save and migrate to allow
the domain id to be incorporated into the saved domain configuration and
hence be preserved.
NOTE: Logically it may seem as though preservation of domid should be
dealt with by libxl, but the libxl migration stream has n
Paul Durrant (6):
libxl: add infrastructure to track and query 'recent' domids
libxl: modify libxl__logv() to only log valid domid values
public/xen.h: add a definition for a 'valid domid' mask
libxl: allow creation of domains with a specified or random domid
xl.conf: introduce 'domid_pol
This patch adds a 'domid' field to libxl_domain_create_info and then
modifies libxl__domain_make() to have Xen use that value if it is valid.
If the domid value is invalid then Xen will choose the domid, as before,
unless the value is the new special RANDOM_DOMID value added to the API.
This value
This patch adds a new global 'domid_policy' configuration option to decide
how domain id values are allocated for new domains. It may be set to one of
two values:
"xen", the default value, will cause an invalid domid value to be passed
to do_domain_create() preserving the existing behaviour of hav
flight 147290 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147290/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen c47984aabead53918e5ba6d43cdb3f1467452739
baseline version:
xen 707d
I also did a full review of all callers, and only the xen driver
forgot to call drm_dev_put in the failure path. Fix that up too.
v2: I noticed that xen has a drm_driver.release hook, and uses
drm_dev_alloc(). We need to remove the kfree from
xen_drm_drv_release().
bochs also has a release hook,
Nested VMX doesn't expose support for
SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE,
SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY or
SECONDARY_EXEC_APIC_REGISTER_VIRT, and hence the x2APIC MSRs should
always be trapped in the nested guest MSR bitmap, or else a nested
guest could access the hardware x2APIC MSRs giv
Import the functions and it's dependencies. Based on Linux 5.5, commit
id d5226fa6dbae0569ee43ecfc08bdcd6770fc4755.
Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
---
Changes since v4:
- Introduce BIT_WORD in generic header bitops.h (instead of the x86
one).
- Include byteorder.h for
So BIT_WORD can be imported from Linux. The difference between current
Linux implementation of BIT_WORD is that the size of the word unit is
a long integer, while the Xen one is hardcoded to 32 bits.
Current users of BITOP_WORD on Arm (which considers a word a long
integer) are switched to use the
Hello,
Patch #3 makes sure the x2APIC MSR range is always trapped, or else a
guest with nested virtualization enabled could manage to access some of
the x2APIC MSR registers from the host. Previous patches are preparatory
patches in order to import bitmap_{set/clear}.
Thanks, Roger.
Roger Pau Mo
xen_maybe_preempt_hcall() is called from the exception entry point
xen_do_hypervisor_callback with interrupts disabled.
_cond_resched() evades the might_sleep() check in cond_resched() which
would have caught that and schedule_debug() unfortunately lacks a check
for irqs_disabled().
Enable interr
Reported-by: Coverity
CID: 1458632
Fixes: 709d3ddea2d5e ('AMD/IOMMU: Common the #732/#733 errata handling in
iommu_read_log()')
Signed-off-by: Roger Pau Monné
---
xen/drivers/passthrough/amd/iommu_init.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/drivers/passthrough/amd/iommu_init.c
On 19/02/2020 11:19, Roger Pau Monne wrote:
> Reported-by: Coverity
> CID: 1458632
We tend to use just Coverity-ID: 1458632
> Fixes: 709d3ddea2d5e ('AMD/IOMMU: Common the #732/#733 errata handling in
> iommu_read_log()')
> Signed-off-by: Roger Pau Monné
> ---
> xen/drivers/passthrough/amd/iomm
On Wed, Feb 19, 2020 at 11:23:40AM +, Andrew Cooper wrote:
> On 19/02/2020 11:19, Roger Pau Monne wrote:
> > Reported-by: Coverity
> > CID: 1458632
>
> We tend to use just Coverity-ID: 1458632
Oh, I got confused with FreeBSD usage of CID.
>
> > Fixes: 709d3ddea2d5e ('AMD/IOMMU: Common the #
Hi Roger,
On 19/02/2020 10:22, Roger Pau Monne wrote:
So BIT_WORD can be imported from Linux. The difference between current
Linux implementation of BIT_WORD is that the size of the word unit is
a long integer, while the Xen one is hardcoded to 32 bits.
Current users of BITOP_WORD on Arm (which
On Wed, Feb 19, 2020 at 11:35:16AM +, Julien Grall wrote:
> Hi Roger,
>
> On 19/02/2020 10:22, Roger Pau Monne wrote:
> > So BIT_WORD can be imported from Linux. The difference between current
> > Linux implementation of BIT_WORD is that the size of the word unit is
> > a long integer, while t
Hyper-V's L0 assisted flush has fine-grained control over what gets
flushed. We need all the flags available to make the best decisions
possible.
No functional change because Xen's implementation doesn't care about
what is passed to it.
Signed-off-by: Wei Liu
Reviewed-by: Roger Pau Monné
Review
Implement a basic hook for L0 assisted TLB flush. The hook needs to
check if prerequisites are met. If they are not met, it returns an error
number to fall back to native flushes.
Introduce a new variable to indicate if hypercall page is ready.
Signed-off-by: Wei Liu
Reviewed-by: Roger Pau Monné
Hi all
This seris is based on Roger's L0 assisted flush series.
I have done some testing against a Linux on Hyper-V in a 32-vcpu VM.
All builds were done with -j32.
Building Xen on Linux:
real0m45.376s
user2m28.156s
sys 0m51.672s
Building Xen on Linux on Xen on Hyper-V, no assiste
Implement L0 assisted TLB flush for Xen on Hyper-V. It takes advantage
of several hypercalls:
* HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST
* HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX
* HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE
* HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX
Pick the most efficient hypercalls available.
On Mon, 2020-02-17 at 11:58 -0800, Sarah Newman wrote:
> On 1/7/20 6:25 AM, Alastair Browne wrote:
> >
> > After the tests, we decided to stick with 4.9.0.9 kernel and 4.12
> > Xen
> > for production use running credit1 as the default scheduler.
>
> One person CC'ed appears to be having the same
On 19.02.20 12:01, Thomas Gleixner wrote:
xen_maybe_preempt_hcall() is called from the exception entry point
xen_do_hypervisor_callback with interrupts disabled.
_cond_resched() evades the might_sleep() check in cond_resched() which
would have caught that and schedule_debug() unfortunately lacks
On 19/02/2020 11:41, Roger Pau Monné wrote:
On Wed, Feb 19, 2020 at 11:35:16AM +, Julien Grall wrote:
Hi Roger,
On 19/02/2020 10:22, Roger Pau Monne wrote:
So BIT_WORD can be imported from Linux. The difference between current
Linux implementation of BIT_WORD is that the size of the word
On Wed, Feb 19, 2020 at 09:11:19AM +0100, Juergen Gross wrote:
> Add a new script xen/tools/binfile for including a binary file at build
> time being usable via a pointer and a size variable in the hypervisor.
>
> Make use of that generic tool in xsm.
>
> Signed-off-by: Juergen Gross
> Reviewed-
Hi Roger,
On 13/02/2020 11:32, Roger Pau Monne wrote:
Most users of the cpu maps just care about the maps not changing while
the lock is being held, but don't actually modify the maps.
Convert the lock into a rw lock, and take the lock in read mode in
get_cpu_maps and in write mode in cpu_hotpl
flight 147221 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147221/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd 14 xen-boot/l1 fail REGR. vs. 147140
test-armhf-armhf-x
Hi Jan,
On 14/02/2020 09:37, Jan Beulich wrote:
On 13.02.2020 19:38, Andrew Cooper wrote:
On 13/02/2020 12:54, Juergen Gross wrote:
Keyhandlers dumping hypervisor information to the console often need
to take locks while accessing data. In order to not block in case of
system inconsistencies i
On 2/19/20 12:20 PM, Daniel Vetter wrote:
> I also did a full review of all callers, and only the xen driver
> forgot to call drm_dev_put in the failure path. Fix that up too.
>
> v2: I noticed that xen has a drm_driver.release hook, and uses
> drm_dev_alloc(). We need to remove the kfree from
> xe
On 13/02/2020 11:32, Roger Pau Monne wrote:
> Hello,
>
> The main aim of this series is to reduce the pressure around
> cpu_add_remove_lock by converting it into a rw lock. Most users of the
> lock want to take it in read mode, as they only care about the maps not
> changing.
>
> Patch #2 makes the
On Thu, 2020-02-13 at 15:35 +0100, Juergen Gross wrote:
> get_cpu_idle_time() is calling vcpu_runstate_get() for an idle vcpu.
> With core scheduling active this is fragile, as idle vcpus are
> assigned
> to other scheduling units temporarily, and that assignment is changed
> in some cases without
On Thu, 2020-02-13 at 13:54 +0100, Juergen Gross wrote:
> All dumping functions invoked by the "runq" keyhandler are called
> with
> disabled interrupts, so there is no need to use the irqsave variants
> of any locks in those functions.
>
>
To me, this patch looks pretty independent from the seri
On 19.02.2020 12:32, Roger Pau Monné wrote:
> On Wed, Feb 19, 2020 at 11:23:40AM +, Andrew Cooper wrote:
>> On 19/02/2020 11:19, Roger Pau Monne wrote:
>>> --- a/xen/drivers/passthrough/amd/iommu_init.c
>>> +++ b/xen/drivers/passthrough/amd/iommu_init.c
>>> @@ -338,6 +338,7 @@ static int iommu_
Julien,
On 18.02.2020 17:53, Andrew Cooper wrote:
> On 18/02/2020 16:52, Jan Beulich wrote:
>> This is more robust than the raw xmalloc_bytes().
>>
>> Also add a sanity check on the input page range, to avoid returning
>> the less applicable -ENOMEM in such cases (and trying the allocation in
>> t
On 13.02.2020 12:32, Roger Pau Monne wrote:
> void __init register_cpu_notifier(struct notifier_block *nb)
> {
> -if ( !spin_trylock(&cpu_add_remove_lock) )
> +if ( !write_trylock(&cpu_add_remove_lock) )
> BUG(); /* Should never fail as we are called only during boot. */
> n
On 13.02.2020 12:32, Roger Pau Monne wrote:
> Don't allow cpu_hotplug_begin to fail by converting the trylock into a
> blocking lock acquisition. Write users of the cpu_add_remove_lock are
> limited to CPU plug/unplug operations, and cannot deadlock between
> themselves or other users taking the lo
On 19/02/2020 12:49, Jan Beulich wrote:
Julien,
On 18.02.2020 17:53, Andrew Cooper wrote:
On 18/02/2020 16:52, Jan Beulich wrote:
This is more robust than the raw xmalloc_bytes().
Also add a sanity check on the input page range, to avoid returning
the less applicable -ENOMEM in such cases (
On Wed, Feb 19, 2020 at 01:56:02PM +0100, Jan Beulich wrote:
> On 13.02.2020 12:32, Roger Pau Monne wrote:
> > void __init register_cpu_notifier(struct notifier_block *nb)
> > {
> > -if ( !spin_trylock(&cpu_add_remove_lock) )
> > +if ( !write_trylock(&cpu_add_remove_lock) )
> > B
On Wed, Feb 19, 2020 at 01:59:51PM +0100, Jan Beulich wrote:
> On 13.02.2020 12:32, Roger Pau Monne wrote:
> > Don't allow cpu_hotplug_begin to fail by converting the trylock into a
> > blocking lock acquisition. Write users of the cpu_add_remove_lock are
> > limited to CPU plug/unplug operations,
Quite possibly they had been in use when some of the PCI interfacing was
done in an ad hoc way rather than using the PCI functions we have. Right
now these have no users (left).
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/amd/iommu-defs.h
+++ b/xen/drivers/passthrough/amd/iommu-defs
Hi Daniel,
Thank you for the patch.
On Wed, Feb 19, 2020 at 11:20:34AM +0100, Daniel Vetter wrote:
> I also did a full review of all callers, and only the xen driver
> forgot to call drm_dev_put in the failure path. Fix that up too.
I'd split this patch in two then, with the Xen first coming fir
On 19.02.2020 14:19, Roger Pau Monné wrote:
> On Wed, Feb 19, 2020 at 01:56:02PM +0100, Jan Beulich wrote:
>> On 13.02.2020 12:32, Roger Pau Monne wrote:
>>> void __init register_cpu_notifier(struct notifier_block *nb)
>>> {
>>> -if ( !spin_trylock(&cpu_add_remove_lock) )
>>> +if ( !write
On 19.02.2020 14:22, Roger Pau Monné wrote:
> On Wed, Feb 19, 2020 at 01:59:51PM +0100, Jan Beulich wrote:
>> On 13.02.2020 12:32, Roger Pau Monne wrote:
>>> Don't allow cpu_hotplug_begin to fail by converting the trylock into a
>>> blocking lock acquisition. Write users of the cpu_add_remove_lock
Hi. This message is being sent once to each mailing list hosted by
the Xen Project.
Increasingly, mail systems on the public internet are demanding
restrictive SPF configurations [1] and DKIM signatures [2].
Currently the Xen Project systems have liberal configurations.
Unfortunately this means t
On 13.02.2020 13:54, Juergen Gross wrote:
> All dumping functions invoked by the "runq" keyhandler are called with
> disabled interrupts,
Is this actually needed for anything? It means not servicing
interrupts for perhaps an extended period of time. Debug keys
aren't promised to be non-intrusive,
On Thu, 2020-02-13 at 13:54 +0100, Juergen Gross wrote:
> Instead of using the normal locks use the keyhandler provided
> trylocks
> with timeouts. This requires a special primitive for the scheduler
> lock.
>
So, FWIW, I tend to agree with Andrew on the general aspects of this.
I.e., I personally
On Wed, Feb 19, 2020 at 02:42:58PM +0100, Jan Beulich wrote:
> On 19.02.2020 14:19, Roger Pau Monné wrote:
> > On Wed, Feb 19, 2020 at 01:56:02PM +0100, Jan Beulich wrote:
> >> On 13.02.2020 12:32, Roger Pau Monne wrote:
> >>> void __init register_cpu_notifier(struct notifier_block *nb)
> >>> {
>
On Wed, Feb 19, 2020 at 2:39 PM Laurent Pinchart
wrote:
>
> Hi Daniel,
>
> Thank you for the patch.
>
> On Wed, Feb 19, 2020 at 11:20:34AM +0100, Daniel Vetter wrote:
> > I also did a full review of all callers, and only the xen driver
> > forgot to call drm_dev_put in the failure path. Fix that u
On Wed, Feb 19, 2020 at 02:44:12PM +0100, Jan Beulich wrote:
> On 19.02.2020 14:22, Roger Pau Monné wrote:
> > On Wed, Feb 19, 2020 at 01:59:51PM +0100, Jan Beulich wrote:
> >> On 13.02.2020 12:32, Roger Pau Monne wrote:
> >>> Don't allow cpu_hotplug_begin to fail by converting the trylock into a
>
Jürgen Groß writes:
> On 19.02.20 12:01, Thomas Gleixner wrote:
>> xen_maybe_preempt_hcall() is called from the exception entry point
>> xen_do_hypervisor_callback with interrupts disabled.
>>
>> _cond_resched() evades the might_sleep() check in cond_resched() which
>> would have caught that and
On 19.02.2020 15:45, Roger Pau Monné wrote:
> On Wed, Feb 19, 2020 at 02:44:12PM +0100, Jan Beulich wrote:
>> On 19.02.2020 14:22, Roger Pau Monné wrote:
>>> On Wed, Feb 19, 2020 at 01:59:51PM +0100, Jan Beulich wrote:
On 13.02.2020 12:32, Roger Pau Monne wrote:
> Don't allow cpu_hotplug_b
On 19/02/2020 13:44, Jan Beulich wrote:
> On 19.02.2020 14:22, Roger Pau Monné wrote:
>> On Wed, Feb 19, 2020 at 01:59:51PM +0100, Jan Beulich wrote:
>>> On 13.02.2020 12:32, Roger Pau Monne wrote:
Don't allow cpu_hotplug_begin to fail by converting the trylock into a
blocking lock acquis
On 19.02.20 15:27, Jan Beulich wrote:
On 13.02.2020 13:54, Juergen Gross wrote:
All dumping functions invoked by the "runq" keyhandler are called with
disabled interrupts,
Is this actually needed for anything? It means not servicing
interrupts for perhaps an extended period of time. Debug keys
flight 147222 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147222/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
142932
test-amd64-i
On 19/02/2020 14:57, Jan Beulich wrote:
> On 19.02.2020 15:45, Roger Pau Monné wrote:
>> On Wed, Feb 19, 2020 at 02:44:12PM +0100, Jan Beulich wrote:
>>> On 19.02.2020 14:22, Roger Pau Monné wrote:
On Wed, Feb 19, 2020 at 01:59:51PM +0100, Jan Beulich wrote:
> On 13.02.2020 12:32, Roger Pa
On 19.02.20 15:31, Dario Faggioli wrote:
On Thu, 2020-02-13 at 13:54 +0100, Juergen Gross wrote:
Instead of using the normal locks use the keyhandler provided
trylocks
with timeouts. This requires a special primitive for the scheduler
lock.
So, FWIW, I tend to agree with Andrew on the general
On Wed, Feb 19, 2020 at 01:48:39PM +, Ian Jackson wrote:
> Hi. This message is being sent once to each mailing list hosted by
> the Xen Project.
>
> Increasingly, mail systems on the public internet are demanding
> restrictive SPF configurations [1] and DKIM signatures [2].
>
> Currently the
flight 147297 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147297/
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
flight 147229 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147229/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
145767
test-amd64-i386-xl-qemu
Having interrupts disabled all the time when running dump_runq() is
not necessary. All the called functions are doing proper locking
and disable interrupts if needed.
Signed-off-by: Juergen Gross
---
xen/common/sched/cpupool.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/xen/common/sche
On 19/02/2020 13:37, Jan Beulich wrote:
> Quite possibly they had been in use when some of the PCI interfacing was
> done in an ad hoc way rather than using the PCI functions we have. Right
> now these have no users (left).
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On Wed, 2020-02-19 at 16:02 +0100, Jürgen Groß wrote:
> On 19.02.20 15:27, Jan Beulich wrote:
> > On 13.02.2020 13:54, Juergen Gross wrote:
> > > All dumping functions invoked by the "runq" keyhandler are called
> > > with
> > > disabled interrupts,
> >
> > Is this actually needed for anything? It
On 19.02.2020 09:11, Juergen Gross wrote:
> +static int hypfs_get_path_user(char *buf,
> + XEN_GUEST_HANDLE_PARAM(const_char) uaddr,
> + unsigned long ulen)
> +{
> +if ( ulen > XEN_HYPFS_MAX_PATHLEN )
> +return -EINVAL;
> +
> +
Hi Andrew,
Thank you for stepping up and trying to make HVM_PARAM better :).
On 10/02/2020 18:45, Andrew Cooper wrote:
ARM currently has no restrictions on toolstack and guest access to the entire
HVM_PARAM block. As the paging/monitor/sharing features aren't under security
support, this doesn
On 19.02.2020 09:11, Juergen Gross wrote:
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -1,6 +1,7 @@
> obj-$(CONFIG_ARGO) += argo.o
> obj-y += bitmap.o
> obj-y += bsearch.o
> +obj-y += config_data.o
In particular with embedded uses in mind, I think this wants to
have a Kconfig co
On Wed, 2020-02-19 at 16:33 +0100, Juergen Gross wrote:
> Having interrupts disabled all the time when running dump_runq() is
> not necessary. All the called functions are doing proper locking
> and disable interrupts if needed.
>
> Signed-off-by: Juergen Gross
>
As said, I'm fine with this other
On 19.02.2020 16:07, Andrew Cooper wrote:
> On 19/02/2020 14:57, Jan Beulich wrote:
>> On 19.02.2020 15:45, Roger Pau Monné wrote:
>>> On Wed, Feb 19, 2020 at 02:44:12PM +0100, Jan Beulich wrote:
On 19.02.2020 14:22, Roger Pau Monné wrote:
> On Wed, Feb 19, 2020 at 01:59:51PM +0100, Jan Be
On Wed, Feb 19, 2020 at 03:07:14PM +, Andrew Cooper wrote:
> On 19/02/2020 14:57, Jan Beulich wrote:
> > On 19.02.2020 15:45, Roger Pau Monné wrote:
> >> On Wed, Feb 19, 2020 at 02:44:12PM +0100, Jan Beulich wrote:
> >>> On 19.02.2020 14:22, Roger Pau Monné wrote:
> On Wed, Feb 19, 2020 at
Ram block notifiers are currently not aware of resizes. Especially to
handle resizes during migration, but also to implement actually resizeable
ram blocks (make everything between used_length and max_length
inaccessible), we want to teach ram block notifiers about resizeable
ram.
Introduce the ba
Hi,
On 19/02/2020 15:49, Jan Beulich wrote:
On 19.02.2020 09:11, Juergen Gross wrote:
+int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
+{
+union {
+char buf[8];
+uint8_t u8;
+uint16_t u
If we skip the bootloader, the TTY path will be set for xenconsoled.
However, there is no guarantee that this will happen by the time we
want to call the console_available callback, so we have to wait.
Signed-off-by: Paweł Marczewski
---
tools/libxl/libxl_create.c | 33
On 19/02/2020 08:11, Juergen Gross wrote:
+int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
+{
+union {
+char buf[8];
+uint8_t u8;
+uint16_t u16;
+uint32_t u32;
+uint64_t
On Wed, Feb 19, 2020 at 05:06:20PM +0100, Jan Beulich wrote:
> On 19.02.2020 16:07, Andrew Cooper wrote:
> > On 19/02/2020 14:57, Jan Beulich wrote:
> >> On 19.02.2020 15:45, Roger Pau Monné wrote:
> >>> On Wed, Feb 19, 2020 at 02:44:12PM +0100, Jan Beulich wrote:
> On 19.02.2020 14:22, Roger
On Wed, Feb 19, 2020 at 2:19 AM Alexandru Stefan ISAILA
wrote:
>
> At this moment a guest can call vmfunc to change the altp2m view. This
> should be limited in order to avoid any unwanted view switch.
>
> The new xc_altp2m_set_visibility() solves this by making views invisible
> to vmfunc.
> This
On 19/02/2020 08:12, Jan Beulich wrote:
> This is controlling Xen behavior alone, after all.
>
> Reported-by: Jin Nan Wang
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xe
On Mon, Feb 10, 2020 at 11:46 AM Andrew Cooper
wrote:
>
> ARM currently has no restrictions on toolstack and guest access to the entire
> HVM_PARAM block. As the paging/monitor/sharing features aren't under security
> support, this doesn't need an XSA.
There is no paging or sharing implementatio
On 19.02.2020 09:11, Juergen Gross wrote:
> --- a/docs/misc/hypfs-paths.pandoc
> +++ b/docs/misc/hypfs-paths.pandoc
> @@ -152,3 +152,12 @@ The major version of Xen.
> /buildinfo/version/minor = INTEGER
>
> The minor version of Xen.
> +
> + /params/
> +
> +A directory of runtime paramet
On 19/02/2020 16:26, Julien Grall wrote:
On 19/02/2020 08:11, Juergen Gross wrote:
+int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned
long ulen)
+{
+ union {
+ char buf[8];
+ uint8_t u8;
+ uint16_t
On Thu, 2020-01-23 at 09:55 +0100, Juergen Gross wrote:
> 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
On 18/02/2020 13:15, Igor Druzhinin wrote:
> On 18/02/2020 12:21, Juergen Gross wrote:
>> Today the RCU handling in Xen is affecting scheduling in several ways.
>> It is raising sched softirqs without any real need and it requires
>> tasklets for rcu_barrier(), which interacts badly with core sched
On 19.02.2020 17:47, Dario Faggioli wrote:
> On Thu, 2020-01-23 at 09:55 +0100, Juergen Gross wrote:
>> --- a/xen/common/sched/credit2.c
>> +++ b/xen/common/sched/credit2.c
>> @@ -849,51 +822,71 @@ static inline bool same_core(unsigned int cpua,
>> unsigned int cpub)
>> cpu_to_core(cpua
On 19/02/2020 16:06, Jan Beulich wrote:
> On 19.02.2020 16:07, Andrew Cooper wrote:
>> On 19/02/2020 14:57, Jan Beulich wrote:
>>> On 19.02.2020 15:45, Roger Pau Monné wrote:
On Wed, Feb 19, 2020 at 02:44:12PM +0100, Jan Beulich wrote:
> On 19.02.2020 14:22, Roger Pau Monné wrote:
>> O
On 19.02.2020 10:18, Alexandru Stefan ISAILA wrote:
> @@ -4835,6 +4836,23 @@ static int do_altp2m_op(
> break;
> }
>
> +case HVMOP_altp2m_set_visibility:
> +{
> +uint16_t altp2m_idx = a.u.set_visibility.altp2m_idx;
> +
> +if ( a.u.set_visibility.pad )
> +
1 - 100 of 140 matches
Mail list logo
