On Tue, Sep 24, 2019 at 11:20:06AM -0700, Roman Shaposhnik wrote:
> Hi!
>
> I'm a bit at a loss of what's happening here, but it seems that
> the latest Xen from master fails to boot on HP ProLiant DL20
> GEN10 server (same Xen boots fine on every other piece of
> hardware in my lab).
>
> There a
Fix two latent bugs discovered in review of my core scheduling series.
For the series:
Release-acked-by: Juergen Gross
Juergen Gross (2):
xen/sched: fix locking in a653sched_free_vdata()
xen/sched: fix freeing per-vcpu data in sched_move_domain()
xen/common/sched_arinc653.c | 6 ++
xen
In case of an allocation error of per-vcpu data in sched_move_domain()
the already allocated data is freed just using xfree(). This is wrong
as some schedulers need to do additional operations (e.g. the arinc653
scheduler needs to remove the vcpu-data from a list).
So instead xfree() make use of t
The arinc653 scheduler's free_vdata() function is missing proper
locking: as it is modifying the scheduler's private vcpu list it needs
to take the scheduler lock during that operation.
Signed-off-by: Juergen Gross
---
xen/common/sched_arinc653.c | 6 ++
1 file changed, 6 insertions(+)
diff
Commit df29d03f1d ("libxc/x86: avoid certain overflows in CPUID APIC ID
adjustments" introduced a one bit too narrow mask when checking whether
multiplying by 1 (in particular in leaf 1) would result in overflow.
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
--- a/tools/libxc/xc_cpuid_x
Ping? I don't think this series is awaiting any more acks.
Paul
> -Original Message-
> From: Paul Durrant
> Sent: 18 September 2019 11:41
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Andrew Cooper
> ; Anthony Perard
> ; David Scott ; George Dunlap
> ;
> Ian Jackson ; Kon
On 25.09.2019 09:05, Juergen Gross wrote:
> The arinc653 scheduler's free_vdata() function is missing proper
> locking: as it is modifying the scheduler's private vcpu list it needs
> to take the scheduler lock during that operation.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
(an
On 25.09.2019 09:05, Juergen Gross wrote:
> In case of an allocation error of per-vcpu data in sched_move_domain()
> the already allocated data is freed just using xfree(). This is wrong
> as some schedulers need to do additional operations (e.g. the arinc653
> scheduler needs to remove the vcpu-da
On 25.09.2019 10:40, Paul Durrant wrote:
> Ping? I don't think this series is awaiting any more acks.
I did enumerate the other day on irc what is still missing according
to my records. Would you mind pointing me at a libxl maintainer ack
for patch 1? I think I've managed to spot the missing one f
flight 141737 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141737/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 133580
test-amd64-i386-exa
> -Original Message-
> From: Jan Beulich
> Sent: 25 September 2019 09:51
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Petre Pircalabu
> ; Andrew Cooper
> ; Anthony Perard ;
> George Dunlap
> ; Ian Jackson ; Roger Pau
> Monne
> ; Volodymyr Babchuk ;
> Stefano Stabellini
> ;
Libxl maintainers... ping?
> -Original Message-
> From: Paul Durrant
> Sent: 18 September 2019 11:41
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Alexandru Isaila
> ; Razvan
> Cojocaru ; Jan Beulich ; Julien
> Grall
> ; Stefano Stabellini ;
> Volodymyr Babchuk
> ; Andrew C
On 24.09.2019 20:20, Roman Shaposhnik wrote:
> I'm a bit at a loss of what's happening here, but it seems that
> the latest Xen from master fails to boot on HP ProLiant DL20
> GEN10 server (same Xen boots fine on every other piece of
> hardware in my lab).
First of all - is this known to be a regr
flight 141747 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141747/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt16 guest-start/debian.repeat fail REGR. vs. 141683
Tests which did not suc
Hi,
On 24/09/2019 18:56, Stefano Stabellini wrote:
On Wed, 11 Sep 2019, Julien Grall wrote:
Hi Stefano,
On 8/21/19 4:53 AM, Stefano Stabellini wrote:
We don't have a clear way to know how many virtual SPIs we need for the
dom0-less domains. Introduce a new option under xen,domain to specify
t
Commit 4c6cd64519 ("mwait_idle: Skylake Client Support") added a table
with 8 entries, which - together with C0 - rendered the current limit
too low. It should have been accompanied by an increase of the constant;
do this now. Don't bump by too much though, as there are a number of on-
stack arrays
On 24/09/2019 19:07, Stefano Stabellini wrote:
On Wed, 11 Sep 2019, Julien Grall wrote:
On 8/21/19 4:53 AM, Stefano Stabellini wrote:
I can replace 0xX by X for #address-cells and #size-cells everywhere in
the example. I don't think it makes sense to do it for reg and
interrupts properties?
On 25.09.19 11:12, Jan Beulich wrote:
Commit 4c6cd64519 ("mwait_idle: Skylake Client Support") added a table
with 8 entries, which - together with C0 - rendered the current limit
too low. It should have been accompanied by an increase of the constant;
do this now. Don't bump by too much though, a
On Wed, Sep 18, 2019 at 11:41:10AM +0100, Paul Durrant wrote:
> Now that there is a per-domain IOMMU-enable flag, which should be set if
> any device is going to be passed through, stop deferring page table
> construction until the assignment is done. Also don't tear down the tables
> again when th
On 19.09.19 12:37, Jan Beulich wrote:
hvm_monitor_cpuid() expects the input registers, not two of the outputs.
However, once having made the necessary adjustment, the SVM and VMX
functions are so similar that they should be folded (thus avoiding
further similar asymmetries to get introduced). Us
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, September 19, 2019 6:38 PM
>
> hvm_monitor_cpuid() expects the input registers, not two of the outputs.
>
> However, once having made the necessary adjustment, the SVM and VMX
> functions are so similar that they should be folded (t
> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: Wednesday, September 25, 2019 12:42 AM
>
> Ping?
>
> Since I've got an Ack from Jan and Julien I think the missing Acks are
> for the Intel stuff and x86 generic and AMD by Andrew, since Jan
> explicitly expressed his Ack is only for p
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, September 13, 2019 7:10 PM
>
> This patch defines a new bit reported in the hw_cap field of struct
> xen_sysctl_physinfo to indicate whether the platform supports sharing of
> HAP page tables (i.e. the P2M) with the IOMMU. This informs
Hello xen,
I would like to participate in Outreachy. I was registered on the site few
days ago, filled some quite a big form but still can't see tasks'
descriptions.
Since, I like C programming I would like to know more about "Introduce
CONFIG_PDX and use it in Xen hypervisor". What hardware do I n
On Wed, Sep 25, 2019 at 04:41:26AM +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
On Wed, Sep 25, 2019 at 11:12:59AM +0200, Jan Beulich wrote:
> Commit 4c6cd64519 ("mwait_idle: Skylake Client Support") added a table
> with 8 entries, which - together with C0 - rendered the current limit
> too low. It should have been accompanied by an increase of the constant;
> do this now. Don
On Mon, Sep 23, 2019 at 11:09:24AM +0100, Wei Liu wrote:
> Xen is able to run as a guest on Xen. We plan to make it able to run
> on Hyper-V as well.
>
> Introduce CONFIG_GUEST which is set to true if either running on Xen
> or Hyper-V is desired. Restructure code hierarchy for new code to
> come.
flight 141743 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141743/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
Tests which are fail
On Mon, Sep 23, 2019 at 11:09:25AM +0100, Wei Liu wrote:
> ASM_CALL_CONSTRAINT is defined there.
>
> No functional change.
>
> Signed-off-by: Wei Liu
Reviewed-by: Roger Pau Monné
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.
On Mon, Sep 23, 2019 at 11:09:26AM +0100, Wei Liu wrote:
> The only user is Xen specific code in PV shim. We can therefore export
> the variable directly.
>
> Signed-off-by: Wei Liu
Reviewed-by: Roger Pau Monné
Thanks, Roger.
___
Xen-devel mailing l
On 24/09/2019 22:06, Stefano Stabellini wrote:
On Wed, 11 Sep 2019, Julien Grall wrote:
On 8/21/19 4:53 AM, Stefano Stabellini wrote:
Signed-off-by: Stefano Stabellini
Changes in v4:
- use recursion in the implementation
- rename handle_properties to handle_prop_pfdt
- rename scan_pt_n
flight 141810 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141810/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
coverity-amd647 coverity-upload fail REGR. vs. 141331
version t
On Mon, Sep 23, 2019 at 11:09:27AM +0100, Wei Liu wrote:
> We will add Hyper-V specific implementations in the future.
>
> No functional change.
>
> Signed-off-by: Wei Liu
> ---
> xen/arch/x86/guest/xen/xen.c | 32 ++--
> 1 file changed, 26 insertions(+), 6 deletions
On Mon, Sep 23, 2019 at 11:09:28AM +0100, Wei Liu wrote:
> The only implementation there is Xen.
>
> No functional change.
>
> Signed-off-by: Wei Liu
> ---
> xen/arch/x86/guest/Makefile| 2 +
> xen/arch/x86/guest/hypervisor.c| 112 +
> xen/arch/x86/
On Mon, Sep 23, 2019 at 11:09:29AM +0100, Wei Liu wrote:
> We need indication whether it has succeeded or not.
>
> Signed-off-by: Wei Liu
The code LGTM, I have just a suggestion on the approach.
> ---
> xen/arch/x86/guest/hypervisor.c | 5 -
> xen/arch/x86/guest/xen/xen.c| 7 ---
>
On Mon, Sep 23, 2019 at 11:09:30AM +0100, Wei Liu wrote:
> We use the same code structure as we did for Xen code.
>
> As starters, detect Hyper-V in probe_hyperv. More complex
> functionality will be added later.
>
> Signed-off-by: Wei Liu
> ---
> xen/arch/x86/Kconfig | 9 +
>
On Mon, Sep 23, 2019 at 11:09:31AM +0100, Wei Liu wrote:
> Signed-off-by: Wei Liu
> ---
> xen/arch/x86/setup.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index dec60d0301..bbcc5a503d 100644
> --- a/xen/arch/x86/setup.c
> ++
On Wed, 2019-09-25 at 09:05 +0200, Juergen Gross wrote:
> In case of an allocation error of per-vcpu data in
> sched_move_domain()
> the already allocated data is freed just using xfree(). This is wrong
> as some schedulers need to do additional operations (e.g. the
> arinc653
> scheduler needs to
On Wed, 2019-09-25 at 09:05 +0200, Juergen Gross wrote:
> The arinc653 scheduler's free_vdata() function is missing proper
> locking: as it is modifying the scheduler's private vcpu list it
> needs
> to take the scheduler lock during that operation.
>
> Signed-off-by: Juergen Gross
>
Reviewed-by:
On 9/16/19 11:59 AM, Pawel Wieczorkiewicz wrote:
The payloads' name strings can be of arbitrary size (typically small
with an upper bound of XEN_LIVEPATCH_NAME_SIZE).
Current implementation of the list operation interface allows to copy
names in the XEN_LIVEPATCH_NAME_SIZE chunks regardless of it
On Mon, Sep 23, 2019 at 11:09:23AM +0100, Wei Liu wrote:
> Hi all
>
> In case you're wondering, I can already run a fully fledged Xen system on
> Hyper-V with emulated disk and network.
>
> This is the very first stage for porting Xen to run on Hyper-V with all the
> goodies Hyper-V has to offer.
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-freebsd10-amd64
testid guest-start
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.or
On 25/09/2019 09:34, Jan Beulich wrote:
> Commit df29d03f1d ("libxc/x86: avoid certain overflows in CPUID APIC ID
> adjustments" introduced a one bit too narrow mask when checking whether
> multiplying by 1 (in particular in leaf 1) would result in overflow.
>
> Reported-by: Andrew Cooper
> Signed
On 25.09.19 00:33, Dario Faggioli wrote:
On Sat, 2019-09-14 at 10:52 +0200, Juergen Gross wrote:
Now that vcpu_migrate_start() and vcpu_migrate_finish() are used only
to ensure a vcpu is running on a suitable processor
Is this sentence like this (I mean with that "Now" at the beginning)
becaus
Hi Adam,
On Wed, Sep 25, 2019 at 6:38 AM Adam Ford wrote:
> I know it's rather late, but this patch broke the Etnaviv 3D graphics
> in my i.MX6Q.
>
> When I try to use the 3D, it returns some errors and the dmesg log
> shows some memory allocation errors too:
> [3.682347] etnaviv etnaviv: bo
On Wed, Sep 25, 2019 at 7:12 AM Fabio Estevam wrote:
>
> Hi Adam,
>
> On Wed, Sep 25, 2019 at 6:38 AM Adam Ford wrote:
>
> > I know it's rather late, but this patch broke the Etnaviv 3D graphics
> > in my i.MX6Q.
> >
> > When I try to use the 3D, it returns some errors and the dmesg log
> > shows
On Wed, Sep 25, 2019 at 11:41:50AM +0200, Roger Pau Monné wrote:
> It would still be nice to get the missing bits (interrupt enabling),
> or else this patch is kind of pointless, since it still doesn't allow
> stubdomains to work correctly with passed through devices.
Well, that part, as discussed
On 05.09.2019 21:49, Andrew Cooper wrote:
> For gen-cpuid.py, fix a comment describing self.names, and generate the
> reverse mapping in self.values. Write out INIT_FEATURE_NAMES which maps a
> string name to a bit position.
>
> For parse_cpuid(), use cmdline_strcmp() and perform a binary search
On Tue, 24 Sep 2019 at 12:31, Anthony PERARD wrote:
>
> The following changes since commit 2f93a3ecdd3bb060bd04f698ccafe66efd98563a:
>
> Merge remote-tracking branch
> 'remotes/davidhildenbrand/tags/s390x-tcg-2019-09-23' into staging (2019-09-23
> 15:44:52 +0100)
>
> are available in the Git r
On 25/09/2019 13:30, Jan Beulich wrote:
> On 05.09.2019 21:49, Andrew Cooper wrote:
>> For gen-cpuid.py, fix a comment describing self.names, and generate the
>> reverse mapping in self.values. Write out INIT_FEATURE_NAMES which maps a
>> string name to a bit position.
>>
>> For parse_cpuid(), use
On 25.09.2019 14:32, Andrew Cooper wrote:
> On 25/09/2019 13:30, Jan Beulich wrote:
>> On 05.09.2019 21:49, Andrew Cooper wrote:
>>> For gen-cpuid.py, fix a comment describing self.names, and generate the
>>> reverse mapping in self.values. Write out INIT_FEATURE_NAMES which maps a
>>> string name
On 24.09.19 17:22, Jan Beulich wrote:
On 24.09.2019 17:09, Jürgen Groß wrote:
On 24.09.19 17:00, Jan Beulich wrote:
On 24.09.2019 16:41, Jürgen Groß wrote:
for_each_sched_unit_vcpu() for an idle
unit might end premature when one of the vcpus is running in another
unit (idle_vcpu->sched_unit !=
On 25.09.2019 11:41, Roger Pau Monné wrote:
> On Wed, Sep 25, 2019 at 04:41:26AM +0200, Marek Marczykowski-Górecki wrote:
>> --- a/xen/arch/x86/irq.c
>> +++ b/xen/arch/x86/irq.c
>> @@ -254,7 +254,8 @@ void __init clear_irq_vector(int irq)
>> /*
>> * Dynamic irq allocate and deallocation for MSI
On Sat, 2019-09-14 at 10:52 +0200, Juergen Gross wrote:
> Switch null scheduler completely from vcpu to sched_unit usage.
>
> Signed-off-by: Juergen Gross
>
Reviewed-by: Dario Faggioli
With, if possible, all the occurrences of 'item' in comments actually
replaced with 'unit'.
Like, for instanc
On 24.09.19 12:53, Jan Beulich wrote:
On 14.09.2019 10:52, Juergen Gross wrote:
When scheduling an unit with multiple vcpus there is no guarantee all
vcpus are available (e.g. above maxvcpus or vcpu offline). Fall back to
idle vcpu of the current cpu in that case. This requires to store the
corr
On 25.09.19 14:51, Dario Faggioli wrote:
On Sat, 2019-09-14 at 10:52 +0200, Juergen Gross wrote:
Switch null scheduler completely from vcpu to sched_unit usage.
Signed-off-by: Juergen Gross
Reviewed-by: Dario Faggioli
With, if possible, all the occurrences of 'item' in comments actually
re
On 24.09.19 13:55, Jan Beulich wrote:
On 14.09.2019 10:52, Juergen Gross wrote:
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -724,8 +724,10 @@ void sched_destroy_domain(struct domain *d)
}
}
-void vcpu_sleep_nosync_locked(struct vcpu *v)
+static void vcpu_sleep_nosync_l
On 25.09.2019 14:40, Jürgen Groß wrote:
> On 24.09.19 17:22, Jan Beulich wrote:
>> On 24.09.2019 17:09, Jürgen Groß wrote:
>>> On 24.09.19 17:00, Jan Beulich wrote:
On 24.09.2019 16:41, Jürgen Groß wrote:
> for_each_sched_unit_vcpu() for an idle
> unit might end premature when one of
On 24.09.19 14:04, Jan Beulich wrote:
On 14.09.2019 10:52, Juergen Gross wrote:
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -351,26 +351,10 @@ static void sched_spin_unlock_double(spinlock_t *lock1,
spinlock_t *lock2,
spin_unlock_irqrestore(lock1, flags);
}
-static voi
On 25.09.2019 14:58, Jürgen Groß wrote:
> On 24.09.19 12:53, Jan Beulich wrote:
>> On 14.09.2019 10:52, Juergen Gross wrote:
>>> @@ -2015,7 +2079,8 @@ static void sched_slave(void)
>>>
>>> pcpu_schedule_unlock_irq(lock, cpu);
>>>
>>> -sched_context_switch(vprev, sched_unit2vcpu_cpu(
On 24.09.19 14:16, Jan Beulich wrote:
On 14.09.2019 10:52, Juergen Gross wrote:
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -352,9 +352,10 @@ DEFINE_PER_CPU(unsigned int, last_tickle_cpu);
static inline void __runq_tickle(struct csched_unit *new)
{
unsigned int c
On 25.09.19 15:11, Jan Beulich wrote:
On 25.09.2019 14:58, Jürgen Groß wrote:
On 24.09.19 12:53, Jan Beulich wrote:
On 14.09.2019 10:52, Juergen Gross wrote:
@@ -2015,7 +2079,8 @@ static void sched_slave(void)
pcpu_schedule_unlock_irq(lock, cpu);
-sched_context_switch(vprev,
On 24.09.19 15:10, Jan Beulich wrote:
On 14.09.2019 10:52, Juergen Gross wrote:
Having a pointer to struct cpupool in struct sched_resource instead
of per cpu is enough.
Signed-off-by: Juergen Gross
Technically / mechanically
Reviewed-by: Jan Beulich
However, I'm confused by what appears t
On 25.09.2019 15:09, Jürgen Groß wrote:
> On 24.09.19 14:04, Jan Beulich wrote:
>> On 14.09.2019 10:52, Juergen Gross wrote:
>>> --- a/xen/common/schedule.c
>>> +++ b/xen/common/schedule.c
>>> @@ -351,26 +351,10 @@ static void sched_spin_unlock_double(spinlock_t
>>> *lock1, spinlock_t *lock2,
>>>
On Sat, 2019-09-14 at 10:52 +0200, Juergen Gross wrote:
> Switch rt scheduler completely from vcpu to sched_unit usage.
>
> Signed-off-by: Juergen Gross
>
Reviewed-by: Dario Faggioli
With just one additional note.
> * This scheduler follows the Preemptive Global Earliest Deadline
> First (ED
On 19/09/2019 14:21, Jan Beulich wrote:
> ACPI tables are free to list far more device coordinates than there are
> actual devices. By delaying the table allocations for most cases, and
> doing them only when an actual device is known to be present at a given
> position, overall memory used for the
On 19/09/2019 14:22, Jan Beulich wrote:
> Rather than doing this every time we set up interrupts for a device
> anew (and then in several places) fill this invariant field right after
> allocating struct pci_dev.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
On Wed, Sep 25, 2019 at 02:29:41PM +0200, Marek Marczykowski-Górecki wrote:
> On Wed, Sep 25, 2019 at 11:41:50AM +0200, Roger Pau Monné wrote:
> > It would still be nice to get the missing bits (interrupt enabling),
> > or else this patch is kind of pointless, since it still doesn't allow
> > stubd
On 24.09.19 15:34, Jan Beulich wrote:
On 14.09.2019 10:52, Juergen Gross wrote:
--- a/xen/common/cpupool.c
+++ b/xen/common/cpupool.c
@@ -175,6 +175,8 @@ static struct cpupool *cpupool_create(
return NULL;
}
}
+c->granularity = sched_granularity;
+c->opt_gra
On 23/09/2019 15:41, Jan Beulich wrote:
> On 23.09.2019 16:22, Roger Pau Monné wrote:
>> On Thu, Sep 19, 2019 at 03:22:54PM +0200, Jan Beulich wrote:
>>> Rather than doing this every time we set up interrupts for a device
>>> anew (and then in several places) fill this invariant field right after
On 25.09.2019 15:31, Andrew Cooper wrote:
> On 23/09/2019 15:41, Jan Beulich wrote:
>> On 23.09.2019 16:22, Roger Pau Monné wrote:
>>> On Thu, Sep 19, 2019 at 03:22:54PM +0200, Jan Beulich wrote:
Rather than doing this every time we set up interrupts for a device
anew (and then in severa
On 24.09.19 15:49, Jan Beulich wrote:
On 14.09.2019 10:52, Juergen Gross wrote:
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -59,7 +59,7 @@ integer_param("sched_ratelimit_us", sched_ratelimit_us);
enum sched_gran __read_mostly opt_sched_granularity = SCHED_GRAN_cpu;
unsigned in
On 19/09/2019 14:23, Jan Beulich wrote:
> There's no point setting up tables with more space than a PCI device can
> use. For both MSI and MSI-X we can determine how many interrupts could
> be set up at most. Tables allocated during ACPI table parsing, however,
> will (for now at least) continue to
On 19/09/2019 14:24, Jan Beulich wrote:
> Move the device flags field up into an unused hole, thus shrinking
> overall structure size by 8 bytes. Use bool and uint_t as
> appropriate. Drop pointless (redundant) initializations.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On Sat, 2019-09-14 at 10:52 +0200, Juergen Gross wrote:
> Switch arinc653 scheduler completely from vcpu to sched_unit usage.
>
> Signed-off-by: Juergen Gross
>
Reviewed-by: Dario Faggioli
Similar considerations to the ones I made on sched_rt applies here, I
guess.
But again, as soon as core s
On 19/09/2019 14:24, Jan Beulich wrote:
> Having a single device table for all segments can't possibly be right.
That depends on your point of view. Given that there aren't AMD systems
(or really, x86 systems in general) with segments other than zero, a
single device table is reasonable, even if
On Sat, 2019-09-14 at 10:52 +0200, Juergen Gross wrote:
> Switch credit scheduler completely from vcpu to sched_unit usage.
>
> Signed-off-by: Juergen Gross
>
Reviewed-by: Dario Faggioli
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs,
On 25.09.2019 16:19, Andrew Cooper wrote:
> On 19/09/2019 14:24, Jan Beulich wrote:
>> Having a single device table for all segments can't possibly be right.
>
> That depends on your point of view. Given that there aren't AMD systems
> (or really, x86 systems in general)
You keep saying this, an
flight 141750 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141750/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 141691
test-amd64-i386-xl-qemuu-win7-amd64
On 19/09/2019 14:25, Jan Beulich wrote:
> Make sure we don't leave any DTEs unexpected requests through which
> would be passed through untranslated. Set V and IV right away (with
> all other fields left as zero), relying on the V and/or IV bits
> getting cleared only by amd_iommu_set_root_page_tab
On Sat, 2019-09-14 at 10:52 +0200, Juergen Gross wrote:
> Switch credit2 scheduler completely from vcpu to sched_unit usage.
>
> As we are touching lots of lines remove some white space at the end
> of
> the line, too.
>
> Signed-off-by: Juergen Gross
>
Reviewed-by: Dario Faggioli
I did spot a
On 25/09/2019 15:52, Nicolas Saenz Julienne wrote:
On Tue, 2019-09-24 at 16:59 -0500, Rob Herring wrote:
On Tue, Sep 24, 2019 at 1:12 PM Nicolas Saenz Julienne
wrote:
Hi All,
this series tries to address one of the issues blocking us from
upstreaming Broadcom's STB PCIe controller[1]. Namely,
Hi Volodymyr,
On 24/09/2019 16:46, Volodymyr Babchuk wrote:
This is the third version of maturing the OP-TEE mediator patches.
Changes also can be pulled from [3].
Changes from v2:
- The following 3 patches were commited:
xen/arm: optee: impose limit on shared buffer size
xen/arm: optee:
On Tue, 2019-09-24 at 16:59 -0500, Rob Herring wrote:
> On Tue, Sep 24, 2019 at 1:12 PM Nicolas Saenz Julienne
> wrote:
> > Hi All,
> > this series tries to address one of the issues blocking us from
> > upstreaming Broadcom's STB PCIe controller[1]. Namely, the fact that
> > devices not represent
Hi Hongyan
Thanks for picking up this work.
Please CC relevant maintainers and reviewers in the future. I have done
this for this cover letter.
The From: field of your emails is not correct. This makes people not
able to reply to you directly. You may want to check your email
settings.
On Wed,
On Wed, Sep 25, 2019 at 9:17 AM Adam Ford wrote:
> I tried cma=256M and noticed the cma dump at the beginning didn't
> change. Do we need to setup a reserved-memory node like
> imx6ul-ccimx6ulsom.dtsi did?
I don't think so.
Were you able to identify what was the exact commit that caused such r
On Wed, Sep 25, 2019 at 03:33:03PM +0100, hongyax wrote:
> From: Wei Liu
>
> ---
> xen/arch/x86/mm.c | 25 +
> 1 file changed, 13 insertions(+), 12 deletions(-)
>
This patch should have been squashed into the previous patch.
Wei.
__
1: x86: suppress XPTI-related TLB flushes when possible
2: x86/mm: honor opt_pcid also for 32-bit PV domains
3: x86/HVM: move NOFLUSH handling out of hvm_set_cr3()
4: x86/HVM: refuse CR3 loads with reserved (upper) bits set
5: x86/HVM: cosmetics to hvm_set_cr3()
The first patch was previously subm
On 25.09.19 17:02, Dario Faggioli wrote:
On Sat, 2019-09-14 at 10:52 +0200, Juergen Gross wrote:
Switch credit2 scheduler completely from vcpu to sched_unit usage.
As we are touching lots of lines remove some white space at the end
of
the line, too.
Signed-off-by: Juergen Gross
Reviewed-by:
(+Juergen)
Hi Dario,
On 11/09/2019 14:53, Dario Faggioli wrote:
On Fri, 2019-08-23 at 18:16 -0700, Stefano Stabellini wrote:
On Wed, 21 Aug 2019, Dario Faggioli wrote:
Hey, Stefano, Julien,
Here's another patch.
Rather than a debug patch, this is rather an actual "proposed
solution".
Can
On Sat, 2019-09-14 at 10:52 +0200, Juergen Gross wrote:
> The credit scheduler calls vcpu_pause_nosync() and vcpu_unpause()
> today.
>
It does. And, FWIW, I hate it with all my heart because of that (among
other things! :-D).
> Add sched_unit_pause_nosync() and sched_unit_unpause() to
> perform t
I can't see any technical or performance reason why we should treat
32-bit PV different from 64-bit PV in this regard.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
---
xen/arch/x86/pv/domain.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
--- a/xen/
Hi,
I am CCing Juergen to mark this as a blocker for 4.13. Without this patch, Xen
cannot be booted using GRUB.
Cheers,
On 17/09/2019 17:02, Julien Grall wrote:
The current implementations of xen_{map, unmap}_table() expect
{map, unmap}_domain_page() to be usable. Those helpers are used to
m
On Sat, 2019-09-14 at 10:52 +0200, Juergen Gross wrote:
> Let the schedulers put a sched_unit pointer into struct task_slice
> instead of a vcpu pointer.
>
> Signed-off-by: Juergen Gross
>
Reviewed-by: Dario Faggioli
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization
When there's no XPTI-enabled PV domain at all, there's no need to issue
respective TLB flushes. Hardwire opt_xpti_* to false when !PV, and
record the creation of PV domains by bumping opt_xpti_* accordingly.
As to the sticky opt_xpti_domu vs increment/decrement of opt_xpti_hwdom,
this is done this
One thing I forgot to ask: can you publish a git branch for this
series?
Thanks,
Wei.
On Wed, Sep 25, 2019 at 04:13:49PM +0100, Wei Liu wrote:
> Hi Hongyan
>
> Thanks for picking up this work.
>
> Please CC relevant maintainers and reviewers in the future. I have done
> this for this cover lett
The bit is meaningful only for MOV-to-CR3 insns, not anywhere else, in
particular not when loading nested guest state.
Signed-off-by: Jan Beulich
Reviewed-by: Paul Durrant
---
v3: Further restrict "noflush" local variable scopes. Remove (now
redundant) zapping of X86_CR3_NOFLUSH from hvm_mon
While bits 11 and below are, if not used for other purposes, reserved
but ignored, bits beyond physical address width are supposed to raise
exceptions (at least in the non-nested case; I'm not convinced the
current nested SVM/VMX behavior of raising #GP(0) here is correct, but
that's not the subjec
Eliminate the not really useful local variable "old". Reduce the scope
of "page". Rename the latched "current".
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Acked-by: Andrew Cooper
---
v2: Re-base over change earlier in the series.
---
xen/arch/x86/hvm/hvm.c | 30 +++
On 25.09.19 17:23, Julien Grall wrote:
Hi,
I am CCing Juergen to mark this as a blocker for 4.13. Without this
patch, Xen cannot be booted using GRUB.
Cheers,
On 17/09/2019 17:02, Julien Grall wrote:
The current implementations of xen_{map, unmap}_table() expect
{map, unmap}_domain_page() t
1 - 100 of 203 matches
Mail list logo
