flight 120916 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120916/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail REGR. vs. 118294
build-i386-pvops
Hi Manish,
On 03/16/2018 11:58 AM, Manish Jaggi wrote:
Add MIDR values for Cavium ThunderX1 SoC family.
Did you intend to use a : instead of .?
ThunderX1, 81XX, 83XX.
Signed-off-by: Manish Jaggi
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 65eb1071e
Hi,
On 03/16/2018 11:58 AM, Manish Jaggi wrote:
Some Cavium Thunder CPUs suffer a problem where a Xen guest may
inadvertently cause the host kernel to quit receiving interrupts.
This patch adds CONFIG_CAVIUM_ERRATUM_30115. Subsequent patches will
provide workaround.
Signed-off-by: Manish Jaggi
On 03/16/2018 11:58 AM, Manish Jaggi wrote:
This patchset is a Xen port of Marc's patchset.
arm64: KVM: Mediate access to GICv3 sysregs at EL2 [1]
The current RFC patchset is a subset of [1], as it handleing only Group1 traps
as a PoC. Most of the trap code is added in vsysreg.c. Trap handler
Hi Manish,
On 03/16/2018 11:58 AM, Manish Jaggi wrote:
Since this is a SoC errata and trapping of certain group1 registers
should not affect the normal flow. A new file vgic-v3-sr.c is added.
You trap both group1 and group0. But your first sentence is a bit
difficult to understand. How about:
>>> On 19.03.18 at 17:57, wrote:
>> -Original Message-
> [snip]
>> >> How are you making sure this is a mapping that was established via
>> >> the map op? Without that this can be (ab)used to ...
>> >>
>> >> > +put_page(page);
>> >>
>> >> ... underflow the refcount of a page.
>> >>
>>
Hi,
On 03/15/2018 08:30 PM, Andre Przywara wrote:
tl;dr: Coarse changelog below, individual patches have changelogs as
well. git branch:
http://www.linux-arm.org/git?p=xen-ap.git;a=shortlog;h=refs/heads/vgic-new/v2
git://linux-arm.org/xen-ap.git branch vgic-new/v2
Another update, addressing the
On 03/20/2018 03:40 AM, Julien Grall wrote:
Hi Andrew,
On 03/19/2018 07:13 PM, Andrew Cooper wrote:
Its sole caller, start_xen(), is __init.
Actually, most of that files could benefits of __init as this is domain
only build.
In any case, this patch is already a good start. So:
Acked-by:
Hi George,
On 03/15/2018 04:15 PM, George Dunlap wrote:
On Wed, Mar 14, 2018 at 6:19 PM, wrote:
From: Julien Grall
The construction _gfn(paddr_to_pfn(...)) can be simplified by using
gaddr_to_gfn.
Signed-off-by: Julien Grall
Not sure if "simplified" is the right word here (and in the pr
On 03/15/2018 07:20 AM, Alan Robinson wrote:
Hi Julien,
Hi Alan,
At the same time move the remaining M2P define just above just above
set_gpfn_from_mfn to keep all the dummy helpers for M2P together.
At the same time move the remaining M2P define just above
set_gpfn_from_mfn to keep a
On Tue, Mar 20, 2018 at 05:49:22AM +1000, Alexey G wrote:
> On Mon, 19 Mar 2018 15:58:02 +
> Roger Pau Monné wrote:
>
> >On Tue, Mar 13, 2018 at 04:33:52AM +1000, Alexey Gerasimenko wrote:
> >> Much like normal PCI BARs or other chipset-specific memory-mapped
> >> resources, MMCONFIG area nee
While hunting a strange bug in my PCID patch series hinting at some
TLB invalidation problem I discovered a piece of code looking rather
fishy to me.
Is it correct for new_tlbflush_clock_period() to use FLUSH_TLB instead
of FLUSH_TLB_GLOBAL?
While not being a problem in current code as both will
On Tue, Mar 20, 2018 at 07:20:53AM +1000, Alexey G wrote:
> On Mon, 19 Mar 2018 17:49:09 +
> Roger Pau Monné wrote:
>
> >On Tue, Mar 13, 2018 at 04:33:56AM +1000, Alexey Gerasimenko wrote:
> >> This patch extends hvmloader_acpi_build_tables() with code which
> >> detects if MMCONFIG is availa
Le 20/03/2018 à 02:54, Michael S. Tsirkin a écrit :
> QEMU coding style at the moment asks for all non-system
> include files to be used with #include "foo.h".
> However this rule actually does not make sense and
> creates issues for when the included file is generated.
If you change that, we can
On Tue, Mar 20, 2018 at 07:46:04AM +1000, Alexey G wrote:
> On Mon, 19 Mar 2018 17:33:34 +
> Roger Pau Monné wrote:
>
> >On Tue, Mar 13, 2018 at 04:33:55AM +1000, Alexey Gerasimenko wrote:
> >> This adds construct_mcfg() function to libacpi which allows to build
> >> MCFG table for a given mm
Hi George,
On 03/15/2018 04:25 PM, George Dunlap wrote:
On Wed, Mar 14, 2018 at 6:19 PM, wrote:
From: Julien Grall
Arm does not have an M2P and very unlikely to get one in the future,
therefore don't keep defines that are not necessary in the common code.
At the same time move the remainin
On Tue, Mar 20, 2018 at 08:11:49AM +1000, Alexey G wrote:
> On Mon, 19 Mar 2018 17:01:18 +
> Roger Pau Monné wrote:
>
> >On Tue, Mar 13, 2018 at 04:33:53AM +1000, Alexey Gerasimenko wrote:
> >> Provide a new domain config option to select the emulated machine
> >> type, device_model_machine.
Hi George,
On 03/15/2018 04:36 PM, George Dunlap wrote:
On Wed, Mar 14, 2018 at 6:20 PM, wrote:
From: Julien Grall
No functional change intended.
If you end up respinning this you might also add:
"While we're here, use PFN_DOWN() rather than open coding it."
Sure.
Signed-off Julie
>>> On 20.03.18 at 09:50, wrote:
> While hunting a strange bug in my PCID patch series hinting at some
> TLB invalidation problem I discovered a piece of code looking rather
> fishy to me.
>
> Is it correct for new_tlbflush_clock_period() to use FLUSH_TLB instead
> of FLUSH_TLB_GLOBAL?
>
> While
On Tue, Mar 20, 2018 at 09:44:33AM +1000, Alexey G wrote:
> On Mon, 19 Mar 2018 15:30:14 +
> Roger Pau Monné wrote:
>
> >On Tue, Mar 13, 2018 at 04:33:51AM +1000, Alexey Gerasimenko wrote:
> >> +{
> >> +case 0x0300:
> >
> >All this values need to be defines documented somewhere.
>
> -Original Message-
> From: Roger Pau Monne
> Sent: 20 March 2018 08:51
> To: Alexey G
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Ian Jackson ; Jan
> Beulich ; Wei Liu ; Paul Durrant
>
> Subject: Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG
> area in the MM
On 20/03/18 10:19, Jan Beulich wrote:
On 20.03.18 at 09:50, wrote:
>> While hunting a strange bug in my PCID patch series hinting at some
>> TLB invalidation problem I discovered a piece of code looking rather
>> fishy to me.
>>
>> Is it correct for new_tlbflush_clock_period() to use FLUSH_TL
Hi Jan,
On 03/15/2018 08:14 AM, Jan Beulich wrote:
On 14.03.18 at 19:20, wrote:
From: Julien Grall
At the same time replace _mfn(0) by INVALID_MFN or drop the initializer
when it is not necessary. This will make clearer that the MFN
initialized is not valid.
Other than _mfn(0) -> INVALID_MF
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 20 March 2018 08:12
> To: Paul Durrant
> Cc: Andrew Cooper ; George Dunlap
> ; Ian Jackson ; Wei Liu
> ; Stefano Stabellini ; xen-
> de...@lists.xenproject.org; Tim (Xen.org)
> Subject: RE: [Xen-devel] [PATCH 7/7]
>>> On 19.03.18 at 22:20, wrote:
> On Mon, 19 Mar 2018 17:49:09 +
> Roger Pau Monné wrote:
>>On Tue, Mar 13, 2018 at 04:33:56AM +1000, Alexey Gerasimenko wrote:
>>> --- a/tools/firmware/hvmloader/util.c
>>> +++ b/tools/firmware/hvmloader/util.c
>>> @@ -782,6 +782,69 @@ int get_pc_machine_type
At this moment the Debug events for the AMD architecture are not
forwarded to the monitor layer.
This patch adds the Debug event to the common capabilities, adds
the VMEXIT_ICEBP then forwards the event to the monitor layer.
Chapter 2: SVM Processor and Platform Extensions: "Note: A vector 1
exce
On Fri, Mar 16, 2018 at 2:57 PM, Joao Martins wrote:
> On 03/15/2018 03:45 PM, Boris Ostrovsky wrote:
>> On 03/15/2018 10:22 AM, Joao Martins wrote:
>>> All uploaded PM data from non-dom0 CPUs takes the info from vCPU 0 and
>>> changing only the acpi_id. For processors which P-state coordination t
On Tue, Mar 20, 2018 at 09:58:23AM +0100, Laurent Vivier wrote:
> Le 20/03/2018 à 02:54, Michael S. Tsirkin a écrit :
> > QEMU coding style at the moment asks for all non-system
> > include files to be used with #include "foo.h".
> > However this rule actually does not make sense and
> > creates is
So, how do we address the performance regression fixed by this patch?
Olaf
Am Mon, 12 Mar 2018 10:15:08 +0100
schrieb Olaf Hering :
> Am Tue, 6 Mar 2018 11:07:54 +
> schrieb Andrew Cooper :
>
> > > Add a new domctl XEN_DOMCTL_set_vtsc_tolerance_khz to adjust the
> > > tolerance value of a r
>>> On 20.03.18 at 10:32, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 20 March 2018 08:12
>>
>> >>> On 19.03.18 at 17:57, wrote:
>> > What I meant was that safety (against underflow) is predicated on
>> > iommu_lookup_page() failing if the mapping was not established through
>>> On 20.03.18 at 10:29, wrote:
> On 20/03/18 10:19, Jan Beulich wrote:
> On 20.03.18 at 09:50, wrote:
>>> While hunting a strange bug in my PCID patch series hinting at some
>>> TLB invalidation problem I discovered a piece of code looking rather
>>> fishy to me.
>>>
>>> Is it correct for n
On 20 March 2018 at 09:44, Daniel P. Berrangé wrote:
> We can follow what autoconf does, and add a check to configure to see if
> there are generated files left in the source dir, when configuring with
> builddir != srcdir, and exit with error, telling user to clean their
> src dir first.
We alre
>>> On 15.03.18 at 12:58, wrote:
> --- a/xen/arch/x86/pv/callback.c
> +++ b/xen/arch/x86/pv/callback.c
> @@ -71,10 +71,11 @@ static void unregister_guest_nmi_callback(void)
> memset(t, 0, sizeof(*t));
> }
>
> -static long register_guest_callback(struct callback_register *reg)
> +static int
On 19/03/2018 21:43, Christian Lindig wrote:
>
>> On 19. Mar 2018, at 19:13, Andrew Cooper wrote:
>>
>> +max_grant_frames: int32;
>> +max_maptrack_frames: int32;
> As part of:
>
>> +type domctl_create_config =
>> +{
>> + ssidref: int32;
>> + handle: string;
>> + flags: do
>>> On 15.03.18 at 13:43, wrote:
> On 14/03/18 08:29, Jan Beulich wrote:
>> As of commit 4008c71d7a ("x86/alt: Support for automatic padding
>> calculations") there's no point having explict ASM_NOPn instances in
>> alternatives anymore - drop them. As a result also drop the asm/nops.h
>> inclusio
On Tue, Mar 20, 2018 at 10:01:24AM +, Peter Maydell wrote:
> On 20 March 2018 at 09:44, Daniel P. Berrangé wrote:
> > We can follow what autoconf does, and add a check to configure to see if
> > there are generated files left in the source dir, when configuring with
> > builddir != srcdir, and
>>> On 15.03.18 at 21:30, wrote:
> If we change something in a vCPU that affects its runnability or
> otherwise needs the vCPU's attention, we might need to tell the scheduler
> about it.
> We are using this in one place (vIRQ injection) at the moment, but will
> need this at more places soon.
> S
flight 120943 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120943/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 120037
test-amd64-amd64-xl-qemut-win7-amd64
>>> On 15.03.18 at 13:07, wrote:
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -2448,27 +2448,24 @@ int nvmx_n2_vmexit_handler(struct cpu_user_regs *regs,
> break;
> case EXIT_REASON_CR_ACCESS:
> {
> -unsigned long exit_qualification;
> -
Hi,
On 19/03/18 21:53, Julien Grall wrote:
>
>
> On 03/19/2018 05:32 PM, Andre Przywara wrote:
>> Hi,
>
> Hi,
>
>> On 06/03/18 18:13, Julien Grall wrote:
>>> Hi Andre,
>>>
>>> On 05/03/18 16:03, Andre Przywara wrote:
The new VGIC implementation centers around a struct vgic_irq instance
>>
>>> On 16.03.18 at 14:30, wrote:
> +int vpci_msix_arch_print(const struct vpci_msix *msix)
> +{
> +unsigned int i;
> +
> +for ( i = 0; i < msix->max_entries; i++ )
> +{
> +const struct vpci_msix_entry *entry = &msix->entries[i];
> +
> +printk("%6u vec=%02x%7s%6s%3sasser
Hi,
Sorry for the formatting.
On 20 Mar 2018 19:01, "Andre Przywara" wrote:
I am happy to add a comment saying that a list is not the right data
structure.
Fair enough. I won't argue more, let's keep the list and add a comment. I
do want to see that series merged in Xen 4.11.
Cheers,
Chee
On 03/20/2018 09:41 AM, Rafael J. Wysocki wrote:
> On Fri, Mar 16, 2018 at 2:57 PM, Joao Martins
> wrote:
>> On 03/15/2018 03:45 PM, Boris Ostrovsky wrote:
>>> On 03/15/2018 10:22 AM, Joao Martins wrote:
All uploaded PM data from non-dom0 CPUs takes the info from vCPU 0 and
changing onl
>>> On 16.03.18 at 14:29, wrote:
> This functionality is going to reside in vpci.c (and the corresponding
> vpci.h header), and should be arch-agnostic. The handlers introduced
> in this patch setup the basic functionality required in order to trap
> accesses to the PCI config space, and allow dec
On Mon, Mar 19, 2018 at 10:18:34AM -0600, Jan Beulich wrote:
> >>> On 16.03.18 at 14:30, wrote:
> > +static int modify_bars(const struct pci_dev *pdev, bool map, bool rom_only)
> > +{
> > +struct vpci_header *header = &pdev->vpci->header;
> > +struct rangeset *mem = rangeset_new(NULL, NULL
Hi,
On 20/03/18 08:30, Julien Grall wrote:
> Hi,
>
> On 03/15/2018 08:30 PM, Andre Przywara wrote:
>> tl;dr: Coarse changelog below, individual patches have changelogs as
>> well. git branch:
>> http://www.linux-arm.org/git?p=xen-ap.git;a=shortlog;h=refs/heads/vgic-new/v2
>>
>> git://linux-arm.or
>>> On 20.03.18 at 12:12, wrote:
> On Mon, Mar 19, 2018 at 10:18:34AM -0600, Jan Beulich wrote:
>> >>> On 16.03.18 at 14:30, wrote:
>> > +static int modify_bars(const struct pci_dev *pdev, bool map, bool
>> > rom_only)
>> > +{
>> > +struct vpci_header *header = &pdev->vpci->header;
>> > +
On Tue, Mar 20, 2018 at 05:03:09AM -0600, Jan Beulich wrote:
> >>> On 16.03.18 at 14:30, wrote:
> > +int vpci_msix_arch_print(const struct vpci_msix *msix)
> > +{
> > +unsigned int i;
> > +
> > +for ( i = 0; i < msix->max_entries; i++ )
> > +{
> > +const struct vpci_msix_entry
On Tue, Mar 20, 2018 at 11:43:00AM +, Roger Pau Monné wrote:
> On Tue, Mar 20, 2018 at 05:03:09AM -0600, Jan Beulich wrote:
> > >>> On 16.03.18 at 14:30, wrote:
> > > +printk(XENLOG_G_WARNING
> > > + "Failed to remove MSIX table [%" PRI_gfn ", %"
> > > PRI_gfn "]
On Tue, Mar 20, 2018 at 10:27:19AM +, Daniel P. Berrangé wrote:
> On Tue, Mar 20, 2018 at 10:01:24AM +, Peter Maydell wrote:
> > On 20 March 2018 at 09:44, Daniel P. Berrangé wrote:
> > > We can follow what autoconf does, and add a check to configure to see if
> > > there are generated fil
On 03/19/2018 05:28 PM, Daniel Vetter wrote:
On Mon, Mar 19, 2018 at 3:19 PM, Oleksandr Andrushchenko
wrote:
On 03/19/2018 03:51 PM, Daniel Vetter wrote:
On Fri, Mar 16, 2018 at 12:52:09PM +0200, Oleksandr Andrushchenko wrote:
Hi, Daniel!
Sorry, if I strip the patch too much below.
On 03/16/
On Tue, Mar 20, 2018 at 09:58:23AM +0100, Laurent Vivier wrote:
> Le 20/03/2018 à 02:54, Michael S. Tsirkin a écrit :
> > QEMU coding style at the moment asks for all non-system
> > include files to be used with #include "foo.h".
> > However this rule actually does not make sense and
> > creates is
On Tue, Mar 20, 2018 at 09:44:06AM +, Daniel P. Berrangé wrote:
> On Tue, Mar 20, 2018 at 09:58:23AM +0100, Laurent Vivier wrote:
> > Le 20/03/2018 à 02:54, Michael S. Tsirkin a écrit :
> > > QEMU coding style at the moment asks for all non-system
> > > include files to be used with #include "f
flight 120946 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120946/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which did not suc
On Tue, Mar 20, 2018 at 02:12:24PM +0200, Michael S. Tsirkin wrote:
> On Tue, Mar 20, 2018 at 09:44:06AM +, Daniel P. Berrangé wrote:
> > On Tue, Mar 20, 2018 at 09:58:23AM +0100, Laurent Vivier wrote:
> > > Le 20/03/2018 à 02:54, Michael S. Tsirkin a écrit :
> > > > QEMU coding style at the mo
Dear All,
Any comments for the patch?
It addressed the issue mentioned here:
https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg00452.html
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.x
On Tue, Mar 20, 2018 at 12:18:41PM +, Daniel P. Berrangé wrote:
> On Tue, Mar 20, 2018 at 02:12:24PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Mar 20, 2018 at 09:44:06AM +, Daniel P. Berrangé wrote:
> > > On Tue, Mar 20, 2018 at 09:58:23AM +0100, Laurent Vivier wrote:
> > > > Le 20/03/20
On Thu, Mar 15, 2018 at 11:58:40AM +, Andrew Cooper wrote:
> Changes to arch.vgc_flags are made to current in syncrhonous context only, and
> don't need to be locked. (The only other changes are via
> arch_set_info_guest(), which operates on descheduled vcpus only).
>
> Replace the {set,clear
On Thu, Mar 15, 2018 at 11:58:41AM +, Andrew Cooper wrote:
> These functions are almost identical. They differ only in the error emitted
> for the use of CALLBACKTYPE_syscall (which is inconsequential to guests), and
> the type of their argument.
>
> Have the callers pass the unreg.type param
On Thu, 2018-02-15 at 12:51 +0200, Andrii Anisov wrote:
> From: Andrii Anisov
>
> Introduce per-vcpu scheduler operations permission verification.
> As long as Xvcpuinfo are in fact scheduler configuration
> manipulations
> there is no need to introduce specific access vectors.
>
> Signed-off-by
On Thu, Mar 15, 2018 at 11:58:42AM +, Andrew Cooper wrote:
> * Being internal functions, use int rather than long for the return value
> * Factor out pv_vcpu into a local variable. Reduces code volume, and removes
>some split lines.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger
On Tue, 2018-03-20 at 14:19 +0200, Andrii Anisov wrote:
> Dear All,
>
> Any comments for the patch?
>
> It addressed the issue mentioned here:
> https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg00452
> .html
>
Oops, sorry, I had missed it.
Now I've replied. I think it still need
On Tue, Mar 20, 2018 at 02:28:42PM +0200, Michael S. Tsirkin wrote:
> On Tue, Mar 20, 2018 at 12:18:41PM +, Daniel P. Berrangé wrote:
> > On Tue, Mar 20, 2018 at 02:12:24PM +0200, Michael S. Tsirkin wrote:
> > > On Tue, Mar 20, 2018 at 09:44:06AM +, Daniel P. Berrangé wrote:
> > > > On Tue,
On Tue, Mar 20, 2018 at 12:39:00PM +, Daniel P. Berrangé wrote:
> On Tue, Mar 20, 2018 at 02:28:42PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Mar 20, 2018 at 12:18:41PM +, Daniel P. Berrangé wrote:
> > > On Tue, Mar 20, 2018 at 02:12:24PM +0200, Michael S. Tsirkin wrote:
> > > > On Tue,
flight 120951 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120951/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ae38c9765a27264ecea03c6430b956b74a427213
baseline version:
ovmf 34d808add3dc23aaa37e1
On 03/20/2018 05:41 AM, Rafael J. Wysocki wrote:
> On Fri, Mar 16, 2018 at 2:57 PM, Joao Martins
> wrote:
>> On 03/15/2018 03:45 PM, Boris Ostrovsky wrote:
>>> On 03/15/2018 10:22 AM, Joao Martins wrote:
All uploaded PM data from non-dom0 CPUs takes the info from vCPU 0 and
changing onl
Hi,
I've been experimenting with Linux 4.14 on Xen 4.6. Now that Intel
microcode is generally
available, I'm starting to exercise the new mitigation code paths.
For Xen 4.6-4.8, microcode loading happens after
init_speculation_mitigations, so Xen only
detects the boot firmware features. The ear
flight 120987 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120987/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 120949
Tests which
On Tue, Mar 20, 2018 at 03:54:36AM +0200, Michael S. Tsirkin wrote:
> QEMU coding style at the moment asks for all non-system
> include files to be used with #include "foo.h".
> However this rule actually does not make sense and
> creates issues for when the included file is generated.
>
> In C, i
On Tue, Mar 20, 2018 at 03:54:36AM +0200, Michael S. Tsirkin wrote:
> QEMU coding style at the moment asks for all non-system
> include files to be used with #include "foo.h".
> However this rule actually does not make sense and
> creates issues for when the included file is generated.
>
> In C, i
>>> On 20.03.18 at 12:43, wrote:
> Since you only had comments on patch 7 and 11 and there's the extra
> fix for the test harness, should I just send those and provide you
> with a git branch that contains the rest?
Well, if it's not too much hassle for you I'd prefer if you resent the
full serie
On Tue, Mar 20, 2018 at 01:10:41PM +, Stefan Hajnoczi wrote:
> On Tue, Mar 20, 2018 at 03:54:36AM +0200, Michael S. Tsirkin wrote:
> > QEMU coding style at the moment asks for all non-system
> > include files to be used with #include "foo.h".
> > However this rule actually does not make sense a
Hi,
> > So for these, we should use "". None of these are generated files though.
>
> That leads to crazy inconsistent message for developers where 50% of QEMU
> header files must use <> and the other 50% of header files must use "".
The rules are pretty simple though:
(1) Headers which a
On 3/20/18 1:07 AM, Juergen Gross wrote:
> On 19/03/18 20:04, Doug Goldstein wrote:
>> commit 448c03b3cbe14873ee637755a29ea26ee7ca9ef9
>> Author: Juergen Gross
>> Date: Mon Feb 26 09:46:12 2018 +0100
>>
>> This commit breaks the build of qemu-xen-traditional for:
>>
>> Ubuntu 14.04: https://gitl
On Tue, Mar 20, 2018 at 02:32:16PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > So for these, we should use "". None of these are generated files though.
> >
> > That leads to crazy inconsistent message for developers where 50% of QEMU
> > header files must use <> and the other 50% of header file
On 20.03.2018 14:32, Gerd Hoffmann wrote:
> Hi,
>
>>> So for these, we should use "". None of these are generated files though.
>>
>> That leads to crazy inconsistent message for developers where 50% of QEMU
>> header files must use <> and the other 50% of header files must use "".
>
> The rul
On Tue, Mar 20, 2018 at 01:58:01PM +0200, Oleksandr Andrushchenko wrote:
> On 03/19/2018 05:28 PM, Daniel Vetter wrote:
> > There should be no difference between immediate removal and delayed
> > removal of the drm_device from the xenbus pov. The lifetimes of the
> > front-end (drm_device) and back
On Tue, Mar 20, 2018 at 01:41:17PM +, Daniel P. Berrangé wrote:
> On Tue, Mar 20, 2018 at 02:32:16PM +0100, Gerd Hoffmann wrote:
> > Hi,
> >
> > > > So for these, we should use "". None of these are generated files
> > > > though.
> > >
> > > That leads to crazy inconsistent message for d
On Tue, Mar 20, 2018 at 02:46:46PM +0100, Thomas Huth wrote:
> On 20.03.2018 14:32, Gerd Hoffmann wrote:
> > Hi,
> >
> >>> So for these, we should use "". None of these are generated files though.
> >>
> >> That leads to crazy inconsistent message for developers where 50% of QEMU
> >> header fi
On Tue, Mar 20, 2018 at 07:10:39AM -0600, Jan Beulich wrote:
> >>> On 20.03.18 at 12:43, wrote:
> > Since you only had comments on patch 7 and 11 and there's the extra
> > fix for the test harness, should I just send those and provide you
> > with a git branch that contains the rest?
>
> Well, if
On 20/03/18 10:56, Jan Beulich wrote:
On 20.03.18 at 10:29, wrote:
>> On 20/03/18 10:19, Jan Beulich wrote:
>> On 20.03.18 at 09:50, wrote:
While hunting a strange bug in my PCID patch series hinting at some
TLB invalidation problem I discovered a piece of code looking rather
>
On 2018-03-20 14:41, Daniel P. Berrangé wrote:
> On Tue, Mar 20, 2018 at 02:32:16PM +0100, Gerd Hoffmann wrote:
>> Hi,
>>
So for these, we should use "". None of these are generated files though.
>>>
>>> That leads to crazy inconsistent message for developers where 50% of QEMU
>>> header fi
On Tue, Mar 20, 2018 at 03:50:02PM +0200, Michael S. Tsirkin wrote:
> On Tue, Mar 20, 2018 at 01:41:17PM +, Daniel P. Berrangé wrote:
> > On Tue, Mar 20, 2018 at 02:32:16PM +0100, Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > > So for these, we should use "". None of these are generated file
flight 120947 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120947/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail REGR. vs. 120095
test-amd64-amd64-
On Tue, Mar 20, 2018 at 01:58:32PM +, Daniel P. Berrangé wrote:
> > That's the C language for you though. For better or worse, these are
> > the rules that K&R came up with.
>
> No one seriously tries to keep compliance with original K&R C these days,
> things have moved on massively since th
>>> On 20.03.18 at 13:58, wrote:
> I've been experimenting with Linux 4.14 on Xen 4.6. Now that Intel
> microcode is generally
> available, I'm starting to exercise the new mitigation code paths.
>
> For Xen 4.6-4.8, microcode loading happens after
> init_speculation_mitigations, so Xen only
> d
On 02/15/2018 05:51 AM, Andrii Anisov wrote:
From: Andrii Anisov
Introduce per-vcpu scheduler operations permission verification.
As long as Xvcpuinfo are in fact scheduler configuration manipulations
there is no need to introduce specific access vectors.
Signed-off-by: Andrii Anisov
Acked-
On 20/03/18 10:51, Jan Beulich wrote:
On 15.03.18 at 13:07, wrote:
>> --- a/xen/arch/x86/hvm/vmx/vvmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
>> @@ -2448,27 +2448,24 @@ int nvmx_n2_vmexit_handler(struct cpu_user_regs
>> *regs,
>> break;
>> case EXIT_REASON_CR_ACCESS:
>> {
>
>>> On 20.03.18 at 15:28, wrote:
> On 20/03/18 10:51, Jan Beulich wrote:
> On 15.03.18 at 13:07, wrote:
>>> +typedef union cr_access_qual {
>>> +unsigned long raw;
>>> +struct {
>>> +uint16_t cr:4,
>>> + access_type:2, /* VMX_CR_ACCESS_TYPE_* */
>>> +
Hello,
The following series contain an implementation of handlers for the PCI
configuration space inside of Xen. This allows Xen to detect accesses
to the PCI configuration space and react accordingly.
Why is this needed? IMHO, there are two main points of doing all this
emulation inside of Xen,
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
Changes since v6:
- Remove the rom local variable.
Changes si
Add handlers for the MSI control, address, data and mask fields in
order to detect accesses to them and setup the interrupts as requested
by the guest.
Note that the pending register is not trapped, and the guest can
freely read/write to it.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulic
Add handlers for accesses to the MSI-X message control field on the
PCI configuration space, and traps for accesses to the memory region
that contains the MSI-X table and PBA. This traps detect attempts from
the guest to configure MSI-X interrupts and properly sets them up.
Note that accesses to t
>>> On 20.03.18 at 13:58, wrote:
> With that in place, I'm seeing Dom0 receive a general protection fault on
> boot
>
> [ 25.460035] general protection fault: [#1] SMP
> [ 25.460292] EIP: switch_mm_irqs_off+0xbe/0x600
>
> switch_mm_irqs_off+0xbe is the inlined
> indirect_branch_predict
This functionality is going to reside in vpci.c (and the corresponding
vpci.h header), and should be arch-agnostic. The handlers introduced
in this patch setup the basic functionality required in order to trap
accesses to the PCI config space, and allow decoding the address and
finding the correspo
Introduce a set of handlers for the accesses to the MMCFG areas. Those
areas are setup based on the contents of the hardware MMCFG tables,
and the list of handled MMCFG areas is stored inside of the hvm_domain
struct.
The read/writes are forwarded to the generic vpci handlers once the
address is d
So that it can be called from outside in order to get the size of regular PCI
BARs. This will be required in order to map the BARs from PCI devices into PVH
Dom0 p2m.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackso
So that MMCFG regions not present in the MCFG ACPI table can be added
at run time by the hardware domain.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
Reviewed-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Paul Durrant
---
Changes since v7:
- Add newline in hvm_physd
This is needed for MSI-X, since MSI-X will need to be initialized
before parsing the BARs, so that the header BAR handlers are aware of
the MSI-X related holes and make sure they are not mapped in order for
the trap handlers to work properly.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulic
When a MSI device with per-vector masking capabilities is detected or
added to Xen all the vectors are masked when initializing it. This
implies that the first time the interrupt is bound to a domain it's
masked.
This however only applies to the first time the interrupt is bound
because neither th
1 - 100 of 220 matches
Mail list logo
