Today there is a global limit of pages mapped via /dev/xen/gntdev set
to 1 million pages per default. There is no reason why that limit is
existing, as total number of foreign mappings is limited by the
hypervisor anyway and preferring kernel mappings over userspace ones
doesn't make sense.
Additi
The Xen gntdev driver's checking of the number of allowed mapped pages
is in need of some sanitizing work.
Juergen Gross (2):
xen/gntdev: replace global limit of mapped pages by limit per call
xen/gntdev: switch from kcalloc() to kvcalloc()
drivers/xen/gntdev-common.h | 2 +-
drivers/xen/gn
With sufficient many pages to map gntdev can reach order 9 allocation
sizes. As there is no need to have physically contiguous buffers switch
to kvcalloc() in order to avoid failing allocations.
Signed-off-by: Juergen Gross
---
drivers/xen/gntdev.c | 30 +++---
1 file cha
flight 139084 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139084/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 6418500c9f9c91a698564bbc264c513461611472
baseline version:
freebsd 163feb2e45c
flight 139075 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139075/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail
REGR. vs. 138977
Test
On 17.07.19 19:22, Joe Perches wrote:
On Wed, 2019-07-17 at 08:49 +0200, Juergen Gross wrote:
On 17.07.19 08:46, Joe Perches wrote:
On Tue, 2019-07-16 at 12:26 +0800, Zhenzhong Duan wrote:
.. as "nopv" support needs it to be changeable at boot up stage.
Checkpatch reports warning, so move var
flight 139076 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139076/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs.
139037
Tests which did not
flight 139069 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139069/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs. 139032
On Wed, Jul 17, 2019 at 12:21:58PM +0200, Roger Pau Monné wrote:
> On Wed, Jul 17, 2019 at 03:00:44AM +0200, Marek Marczykowski-Górecki wrote:
> > Add libxc wrapper for PHYSDEVOP_msi_control introduced in previous
> > commit.
> >
> > Signed-off-by: Marek Marczykowski-Górecki
>
> LGTM, albeit I f
On Wed, Jul 17, 2019 at 12:18:43PM +0200, Roger Pau Monné wrote:
> On Wed, Jul 17, 2019 at 03:00:43AM +0200, Marek Marczykowski-Górecki wrote:
> > Allow device model running in stubdomain to enable/disable MSI(-X),
> > bypassing pciback. While pciback is still used to access config space
> > from w
flight 139068 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139068/
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 7 xen-boot fail REGR.
vs. 133580
test-amd64
flight 139072 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139072/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 35e242b698cdc6205e99a6d6a188bf27fecf9fb4
baseline version:
ovmf 51dd408ae1022e5c93784
Hi,
>
> Well, Xen has been supported the omap5 for quite a while. So there are
> two possibilities regarding the current SMP code:
> 1) It is totally broken and therefore never worked on any omap5
> platform.
> 2) It works but with maybe modification in U-boot.
>
> Looking at the mailing l
Calling _put_page_type while also holding the page_lock
for that page can cause a deadlock.
The comment being dropped is incorrect since it's now out-of-date.
Signed-off-by: Tamas K Lengyel
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Wei Liu
Cc: Roger Pau Monne
---
v6: rebase on
No functional change
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/mm/mem_sharing.c | 265 ++
1 file changed, 138 insertions(+), 127 deletions(-)
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index a5fe89e339..aaf8c2f2c8 100644
---
Disable it by default as it is only an experimental subsystem.
Signed-off-by: Tamas K Lengyel
Acked-by: Daniel De Graaf
Acked-by: Razvan Cojocaru
Acked-by: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Roger Pau Monne
Cc: George Dunlap
Cc: Ian Jackson
Cc: Julien Grall
Cc: Konrad Rzeszute
This is an assorted series of fixes to the memory sharing subsystem.
Patch 1-2: fix general brokeness of the system
Patch 3-5: nice-to-haves & cleanups, could be applied independently from the
rest of the patches in the series
Tamas K Lengyel (5):
x86/mem_sharing: reorder when pages
Improves performance for release builds.
Signed-off-by: Tamas K Lengyel
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Roger Pau Monne
---
v6: patch ping
---
xen/include/asm-x86/mem_sharing.h | 4
1 file changed, 4 insertions(+)
diff --git a/xen/include/asm-x86/mem_sharing.h
b/xen/
Patch cf4b30dca0a "Add debug code to detect illegal page_lock and put_page_type
ordering" added extra sanity checking to page_lock/page_unlock for debug builds
with the assumption that no hypervisor path ever locks two pages at once.
This assumption doesn't hold during memory sharing so we copy a
> -Original Message-
[snip]
> >>> +}
> >>> +
> >>> +if ( !vm_event_check(ved) )
> >>> +return -EINVAL;
> >>> +
> >>> +if ( frame != 0 || nr_frames != to_channels(ved)->nr_frames )
> >>> +return -EINVAL;
> >>
> >> Is there a particular reason for this all-or-nothi
On 17/07/2019 14:02, Jan Beulich wrote:
> On 17.07.2019 13:26, Andrew Cooper wrote:
>> On 17/07/2019 08:09, Jan Beulich wrote:
>>> On 17.07.2019 01:51, Andrew Cooper wrote:
On 15/07/2019 19:57, Foerster, Leonard wrote:
> * dom0less: bootstrap domains without the involvement of dom0
>
On Wed, 2019-07-17 at 17:04 +0100, George Dunlap wrote:
> On 8/25/18 1:21 AM, Dario Faggioli wrote:
> > If a pCPU has been/is being offlined, we don't want it to be
> > neither
> > assigned to any pCPU, nor in the wait list.
> >
> > Therefore, when we detect that a vcpu is going offline, remove it
On Wed, 2019-07-17 at 08:49 +0200, Juergen Gross wrote:
> On 17.07.19 08:46, Joe Perches wrote:
> > On Tue, 2019-07-16 at 12:26 +0800, Zhenzhong Duan wrote:
> > > .. as "nopv" support needs it to be changeable at boot up stage.
> > >
> > > Checkpatch reports warning, so move variable declarations
On 17/07/2019 14:07, Jan Beulich wrote:
> On 17.07.2019 13:42, Andrew Cooper wrote:
>> On 17/07/2019 07:42, Jan Beulich wrote:
>>> This is to accompany commit ("x86/svm: Drop support for AMD's
>> 91f86f8634
> Hmm, odd - I'm sure I had checked, resulting in the impression that
> this didn't get com
On 17/07/2019 15:08, Roger Pau Monné wrote:
> Hello,
>
> As part of some PCI related cleanup I'm doing, which includes
> expanding the usage of pci_sbdf_t, I'm also planning to add a custom
> printf formatter for pci_sbdf_t [0], so that a SBDF can be printed
> without having to specify four formatt
On Mon, Jul 15, 2019 at 02:27:27PM +0100, George Dunlap wrote:
> Or use Android's build system?
I never worked with AOSP's sources, but after reading
https://elinux.org/Android_Build_System
the build system seems quite helpful.
If we can do the following to build libxl, I think we could live with
Hi Denis,
On 17/07/2019 17:32, Denis Obrezkov wrote:
I am trying to understand how this ever worked. omap5_smp_init is called
by two sets of platforms (based on compatible):
- ti,dra7: there were some hacks in U-boot to avoid the SMC. If I am
right, then I would not bother to support hacked
On 17/07/2019 13:37, Jan Beulich wrote:
> On 17.07.2019 12:33, George Dunlap wrote:
>>> On Jul 16, 2019, at 11:03 PM, Andrew Cooper
>>>
>>> We could trivially throw the fixes into the branch, tag it, sign it and
>>> throw it out into the open, but doing that on the embargo date itself
>>> would res
flight 139090 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139090/
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.07.2019 16:41, Petre Ovidiu PIRCALABU wrote:
> On Wed, 2019-07-17 at 10:06 +, Jan Beulich wrote:
>> On 16.07.2019 19:06, Petre Pircalabu wrote:
>>> +static void vm_event_channels_free_buffer(struct
>>> vm_event_channels_domain *impl)
>>>{
>>> -vm_event_ring_resume(to_ring(v->domai
Hi Julien,
>
> I am trying to understand how this ever worked. omap5_smp_init is called
> by two sets of platforms (based on compatible):
> - ti,dra7: there were some hacks in U-boot to avoid the SMC. If I am
> right, then I would not bother to support hacked U-boot.
> - ti,omap5: [1] sugge
flight 139062 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139062/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 129313
build-armhf-pvops
On Wed, 17 Jul 2019 09:28:17 -0300
Mauro Carvalho Chehab wrote:
> Some files over there won't parse well by Sphinx.
>
> Fix them.
>
> Signed-off-by: Mauro Carvalho Chehab
Hi Mauro,
Does feel like this one should perhaps have been broken up a touch!
For the IIO ones I've eyeballed it rather t
Array indexes used in the MSR read/write emulation functions as well as
the direct VMX / APIC-V hook are derived from guest controlled values.
Restrict their ranges to limit the side effects of speculative
execution.
Along these lines also constrain the vlapic_lvt_mask[] access.
Remove the unused
On 8/25/18 1:21 AM, Dario Faggioli wrote:
> If a pCPU has been/is being offlined, we don't want it to be neither
> assigned to any pCPU, nor in the wait list.
>
> Therefore, when we detect that a vcpu is going offline, remove it from
> both places.
Hmm, this commit message wasn't very informative
On Wed, Jul 17, 2019 at 11:54:35AM +0200, Roger Pau Monné wrote:
> On Wed, Jul 17, 2019 at 03:00:42AM +0200, Marek Marczykowski-Górecki wrote:
> > Stubdomains need to be given sufficient privilege over the guest which it
> > provides emulation for in order for PCI passthrough to work correctly.
> >
On Wed, 2019-07-17 at 16:42 +0300, Alexandru Stefan ISAILA wrote:
> > +
> > +out:
> > +rc2 = xc_domain_unpause(xch, domain_id);
> > +if ( rc1 || rc2 )
> > +{
> > +if ( rc2 )
> > +PERROR("Unable to pause domain\n");
> > +
> > +if ( rc1 == 0 )
> > +
On Wed, 2019-07-17 at 10:06 +, Jan Beulich wrote:
> On 16.07.2019 19:06, Petre Pircalabu wrote:
> > +static void vm_event_channels_free_buffer(struct
> > vm_event_channels_domain *impl)
> > {
> > -vm_event_ring_resume(to_ring(v->domain->vm_event_monitor));
> > +int i;
> > +
> > +v
On Wed, Jul 17, 2019 at 12:49:49PM +, Jan Beulich wrote:
> On 17.07.2019 12:26, Roger Pau Monné wrote:
> > On Wed, Jul 17, 2019 at 09:04:55AM +, Jan Beulich wrote:
> >> On 16.07.2019 16:26, Roger Pau Monné wrote:
> >>> On Wed, Jul 03, 2019 at 01:01:48PM +, Jan Beulich wrote:
> --
Hello,
As part of some PCI related cleanup I'm doing, which includes
expanding the usage of pci_sbdf_t, I'm also planning to add a custom
printf formatter for pci_sbdf_t [0], so that a SBDF can be printed
without having to specify four formatters (and pass four parameters)
each time (%04x:%02x:%02
flight 139056 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139056/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-buildfail REGR. vs. 138376
build-i386-pre
> Disable it by default as it is only an experimental subsystem.
>
> Signed-off-by: Tamas K Lengyel
This will now need re-basing, as the other change (adding further
CONFIG_HAS_MEM_SHARING) has just gone in. I'm sorry for the extra
round trip needed.
Jan
> +
> +out:
> +rc2 = xc_domain_unpause(xch, domain_id);
> +if ( rc1 || rc2 )
> +{
> +if ( rc2 )
> +PERROR("Unable to pause domain\n");
> +
> +if ( rc1 == 0 )
> +rc1 = rc2;
You can use !rc1 here.
> +}
> +
> +return rc1;
> +}
> +
> +int x
On 17.07.2019 14:38, Tamas K Lengyel wrote:
>> I've omitted all style comments (formatting, plain vs unsigned int
>> etc) - I'd like to leave that to the VM event maintainers.
>
> Do we have an automated way to check for style issues, like astyle?
We don't; there is some work underway towards tha
On 17.07.2019 13:42, Andrew Cooper wrote:
> On 17/07/2019 07:42, Jan Beulich wrote:
>> This is to accompany commit ("x86/svm: Drop support for AMD's
>
> 91f86f8634
Hmm, odd - I'm sure I had checked, resulting in the impression that
this didn't get committed yet.
>> Lightweight Profiling").
>>
>
On 17.07.2019 13:26, Andrew Cooper wrote:
> On 17/07/2019 08:09, Jan Beulich wrote:
>> On 17.07.2019 01:51, Andrew Cooper wrote:
>>> On 15/07/2019 19:57, Foerster, Leonard wrote:
* dom0less: bootstrap domains without the involvement of dom0
-> this might come in handy to at
On 17.07.2019 12:26, Roger Pau Monné wrote:
> On Wed, Jul 17, 2019 at 09:04:55AM +, Jan Beulich wrote:
>> On 16.07.2019 16:26, Roger Pau Monné wrote:
>>> On Wed, Jul 03, 2019 at 01:01:48PM +, Jan Beulich wrote:
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.
> I've omitted all style comments (formatting, plain vs unsigned int
> etc) - I'd like to leave that to the VM event maintainers.
Do we have an automated way to check for style issues, like astyle? In
my projects I integrate that into my Travis checks so I don't have to
do that manually (see
https
On 17.07.2019 12:33, George Dunlap wrote:
>
>> On Jul 16, 2019, at 11:03 PM, Andrew Cooper
>>
>> We could trivially throw the fixes into the branch, tag it, sign it and
>> throw it out into the open, but doing that on the embargo date itself
>> would result in an official release of Xen which has
Several entries at the stable ABI files won't parse if we pass
them directly to the ReST output.
Adjust them, in order to allow adding their contents as-is at
the stable ABI book.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/ABI/stable/firewire-cdev| 4 +
Documentation/ABI/st
On Wed, 2019-07-17 at 09:31 +, Jan Beulich wrote:
> On 16.07.2019 19:06, Petre Pircalabu wrote:
> > The vm_event_domain members are not accessed outside vm_event.c so
> > it's
> > better to hide de implementation details.
> >
> > Signed-off-by: Petre Pircalabu
> > Acked-by: Andrew Cooper
> >
On Tue, 2019-07-16 at 15:13 -0600, Tamas K Lengyel wrote:
> On Tue, Jul 16, 2019 at 11:06 AM Petre Pircalabu
> wrote:
> >
> > In high throughput introspection scenarios where lots of monitor
> > vm_events are generated, the ring buffer can fill up before the
> > monitor
> > application gets a cha
On 17/07/2019 07:42, Jan Beulich wrote:
> This is to accompany commit ("x86/svm: Drop support for AMD's
91f86f8634
> Lightweight Profiling").
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
> ---
> With AMD apparently having abandoned XOP encoded insns, another option
> would seem to b
On 17/07/2019 07:33, Jan Beulich wrote:
> Plus the only other AVX512_BITALG one.
>
> As in a few cases before, since the insns here and in particular their
> memory access patterns follow the usual scheme, I didn't think it was
> necessary to add a contrived test specifically for them, beyond the
>
On 17/07/2019 07:59, Jan Beulich wrote:
On 04.06.19 at 14:41, wrote:
>> Rather than checking that a page table is _not_ "owned" by the fake COW
>> domain, check that it's owned by the domain actually wanting to install
>> it.
>>
>> Switch away from BUG_ON() at the same time.
>>
>> Signed-off-
On 17/07/2019 08:09, Jan Beulich wrote:
> On 17.07.2019 01:51, Andrew Cooper wrote:
>> On 15/07/2019 19:57, Foerster, Leonard wrote:
>>> * dom0less: bootstrap domains without the involvement of dom0
>>> -> this might come in handy to at least setup and continue dom0
>>> on target x
On 16.07.2019 20:06, Petre Pircalabu wrote:
> Cleanup xen-access code in accordance with the XEN style guide.
>
> Signed-off-by: Petre Pircalabu
Reviewed-by: Alexandru Isaila
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xe
On 16.07.2019 20:06, Petre Pircalabu wrote:
> This simplifies the command line parsing logic and makes it easier to
> add new test parameters.
>
> Signed-off-by: Petre Pircalabu
Reviewed-by: Alexandru Isaila
___
Xen-devel mailing list
Xen-devel@list
On 16.07.2019 20:06, Petre Pircalabu wrote:
> Remove the domain reference from calls to vm_event interface function
> and use the backpointer from vm_event_domain.
>
> Affected functions:
> - __vm_event_claim_slot / vm_event_claim_slot / vm_event_claim_slot_nosleep
> - vm_event_cancel_slot
> - v
Several entries at the stable ABI files won't parse if we pass
them directly to the ReST output.
Adjust them, in order to allow adding their contents as-is at
the stable ABI book.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/ABI/stable/firewire-cdev| 4 +
Documentation/ABI/st
> On Jul 16, 2019, at 11:03 PM, Andrew Cooper
>
> We could trivially throw the fixes into the branch, tag it, sign it and
> throw it out into the open, but doing that on the embargo date itself
> would result in an official release of Xen which has had 0 testing in
> the incumbent test system.
On Wed, Jul 17, 2019 at 09:04:55AM +, Jan Beulich wrote:
> On 16.07.2019 16:26, Roger Pau Monné wrote:
> > On Wed, Jul 03, 2019 at 01:01:48PM +, Jan Beulich wrote:
> >> --- a/xen/arch/x86/acpi/cpu_idle.c
> >> +++ b/xen/arch/x86/acpi/cpu_idle.c
> >> @@ -110,6 +110,8 @@ boolean_param("lapic_
On Wed, Jul 17, 2019 at 03:00:44AM +0200, Marek Marczykowski-Górecki wrote:
> Add libxc wrapper for PHYSDEVOP_msi_control introduced in previous
> commit.
>
> Signed-off-by: Marek Marczykowski-Górecki
LGTM, albeit I find the usage of int instead of unsigned int for the
SBDF kind of weird, but it
On Wed, Jul 17, 2019 at 03:00:43AM +0200, Marek Marczykowski-Górecki wrote:
> Allow device model running in stubdomain to enable/disable MSI(-X),
> bypassing pciback. While pciback is still used to access config space
> from within stubdomain, it refuse to write to
> PCI_MSI_FLAGS_ENABLE/PCI_MSIX_F
On 16.07.2019 19:28, Andrew Cooper wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -1407,7 +1407,8 @@ static int alloc_l1_table(struct page_info *page)
> return 0;
>
>fail:
> -gdprintk(XENLOG_WARNING, "Failure in alloc_l1_table: slot %#x\n", i);
> +gdprintk(XENL
On 16.07.2019 19:06, Petre Pircalabu wrote:
> +static void vm_event_channels_free_buffer(struct vm_event_channels_domain
> *impl)
> {
> -vm_event_ring_resume(to_ring(v->domain->vm_event_monitor));
> +int i;
> +
> +vunmap(impl->slots);
> +impl->slots = NULL;
> +
> +for ( i = 0
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-xsm
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu
On Wed, 2019-07-17 at 11:49 +0300, Alexandru Stefan ISAILA wrote:
>
> On 16.07.2019 20:06, Petre Pircalabu wrote:
> > @@ -1004,7 +942,7 @@ struct xen_domctl_psr_cmt_op {
> >* Enable/disable monitoring various VM events.
> >* This domctl configures what events will be reported to helper
> >
On Wed, Jul 17, 2019 at 03:00:42AM +0200, Marek Marczykowski-Górecki wrote:
> Stubdomains need to be given sufficient privilege over the guest which it
> provides emulation for in order for PCI passthrough to work correctly.
> When a HVM domain try to enable MSI, QEMU in stubdomain calls
> PHYSDEVO
flight 139083 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139083/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 08b084ab48738040e34032ffb42387d88619bf1b
baseline version:
xen 38ee
Hi,
On 7/15/19 4:42 PM, George Dunlap wrote:
> On 7/15/19 3:23 PM, Jan Beulich wrote:
>> On 15.07.2019 16:11, George Dunlap wrote:
>>> There was a long discussion about security patches, with the general
>>> proposal being that we should cut a point release for every security issue.
>>
>> Interest
On 16.07.2019 19:06, Petre Pircalabu wrote:
> The vm_event_domain members are not accessed outside vm_event.c so it's
> better to hide de implementation details.
>
> Signed-off-by: Petre Pircalabu
> Acked-by: Andrew Cooper
> Acked-by: Tamas K Lengyel
> ---
> xen/common/vm_event.c | 26 +
On 16.07.2019 19:06, Petre Pircalabu wrote:
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -279,6 +279,8 @@ struct vcpu
> /* VM event */
> struct vm_event_domain
> {
> +/* Domain reference */
> +struct domain *d;
> spinlock_t lock;
> /* The ring has 6
On Tue, 2019-07-16 at 14:45 -0600, Tamas K Lengyel wrote:
> On Tue, Jul 16, 2019 at 11:06 AM Petre Pircalabu
> wrote:
> >
> > This patchset adds a new mechanism of sending synchronous vm_event
> > requests and handling vm_event responses without using a ring.
> > As each synchronous request pause
On 16.07.2019 17:06, Roger Pau Monné wrote:
> On Wed, Jul 03, 2019 at 01:04:13PM +, Jan Beulich wrote:
>> --- a/tools/misc/xenpm.c
>> +++ b/tools/misc/xenpm.c
>> @@ -64,7 +64,9 @@ void show_help(void)
>>" set-sched-smt enable|disable enable/disable
>> scheduler smt p
On 16.07.2019 20:06, Petre Pircalabu wrote:
> Decouple implementation from interface to allow vm_event_check to be
> used regardless of the vm_event underlying implementation.
>
> Signed-off-by: Petre Pircalabu
> Acked-by: Andrew Cooper
> Acked-by: Tamas K Lengyel
Reviewed-by: Alexandru Isai
On 16.07.2019 16:48, Roger Pau Monné wrote:
> On Wed, Jul 03, 2019 at 01:03:02PM +, Jan Beulich wrote:
>> @@ -592,7 +608,13 @@ static void acpi_processor_idle(void)
>>
>>do {
>>cx = &power->states[next_state];
>> -} while ( cx->type > max_state && --next
On 16.07.2019 16:26, Roger Pau Monné wrote:
> On Wed, Jul 03, 2019 at 01:01:48PM +, Jan Beulich wrote:
>> --- a/xen/arch/x86/acpi/cpu_idle.c
>> +++ b/xen/arch/x86/acpi/cpu_idle.c
>> @@ -110,6 +110,8 @@ boolean_param("lapic_timer_c2_ok", local
>>
>>struct acpi_processor_power *__read_mo
flight 139047 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139047/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemut-win7-amd64 13 guest-saverestore fail in 138919 pass
in 139047
test-amd64-i386-xl-
On 16.07.2019 20:06, Petre Pircalabu wrote:
> @@ -1004,7 +942,7 @@ struct xen_domctl_psr_cmt_op {
>* Enable/disable monitoring various VM events.
>* This domctl configures what events will be reported to helper apps
>* via the ring buffer "MONITOR". The ring has to be first enabled
>
On Tue, 2019-07-16 at 14:59 -0600, Tamas K Lengyel wrote:
> > diff --git a/xen/include/public/vm_event.h
> > b/xen/include/public/vm_event.h
> > index 959083d..c48bc21 100644
> > --- a/xen/include/public/vm_event.h
> > +++ b/xen/include/public/vm_event.h
> > @@ -36,6 +36,37 @@
> > #include "io/rin
On 17.07.2019 01:51, Andrew Cooper wrote:
> On 15/07/2019 19:57, Foerster, Leonard wrote:
>> * dom0less: bootstrap domains without the involvement of dom0
>> -> this might come in handy to at least setup and continue dom0
>> on target xen
>> -> If we have this this m
>>> On 04.06.19 at 14:41, wrote:
> Rather than checking that a page table is _not_ "owned" by the fake COW
> domain, check that it's owned by the domain actually wanting to install
> it.
>
> Switch away from BUG_ON() at the same time.
>
> Signed-off-by: Jan Beulich
I've got Roger's R-b - any c
83 matches
Mail list logo
