* Jiri Slaby wrote:
> Documentation/asm-annotations.rst | 218
> arch/x86/include/asm/linkage.h| 10 +-
> include/linux/linkage.h | 257
> --
> 3 files changed, 475 insertions(+), 10 deletions(-)
> create mode
On 12/05/18 03:36, osstest service owner wrote:
> flight 122660 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/122660/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-xl-qemuu-debianhvm
On Fri, May 11, 2018 at 11:38:04AM +0100, Andrew Cooper wrote:
> In hindsight, the end result of the Spectre mitigations aren't as great as I'd
> hoped, and have several inefficiencies. Also, the `bti=` command line option
> isn't as flexible as intended.
I think this is a good argument for this
On Fri, May 11, 2018 at 11:38:05AM +0100, Andrew Cooper wrote:
> Make it available from the beginning of init_speculation_mitigations(), and
> pass it into appropriate functions. Fix an RSBA typo while moving the
> affected comment.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
__
flight 122718 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122718/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 122667
version targeted for testi
flight 74714 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74714/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-i386-sid-netboot-pvgrub 10 debian-di-install fail like 74689
test-armhf-armhf-armhf-sid-n
Anthony, Stefano,
Ping?
I'd like to get your feedback before spinning a v3 to incorporate Eric's
suggestion regarding the commit comment for #2.
Paul
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 10 May 2018 10:15
> To: qemu-de...@nongnu.org; xen-
Juergen Gross writes ("Re: [Xen-devel] [xen-unstable test] 122660: regressions
- trouble: blocked/broken/fail/pass"):
> On 12/05/18 03:36, osstest service owner wrote:
> > flight 122660 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/122660/
> >
> > Regressions :-(
>
On 11/05/18 22:47, Stefano Stabellini wrote:
On Fri, 11 May 2018, Dario Faggioli wrote:
On Fri, 2018-05-11 at 14:08 +0100, Julien Grall wrote:
The whole idea here is we have only one place taking the decision and
we
don't spread BUG_ON()/panic/stop_cpu everywhere. The benefit is
having
only o
The full size of the BAR is stored in the lower PCIIORegion.size. The
upper PCIIORegion.size is 0. Calculate the size of the upper half
correctly from the lower half otherwise the size read by the guest will
be incorrect.
Signed-off-by: Ross Lagerwall
---
hw/xen/xen_pt_config_init.c | 2 ++
1 f
flight 122719 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122719/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 broken
test-arm64-arm64-libvir
On Fri, May 11, 2018 at 11:38:06AM +0100, Andrew Cooper wrote:
> At the moment, we have two different encodings of Xen's MSR_SPEC_CTRL value,
> which is a side effect of how the Spectre series developed. One encoding is
> via an alias with the bottom bit of bti_ist_info, and can encode IBRS or not
flight 122715 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122715/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl broken
test-arm64-arm64-xl-
>>> On 08.05.18 at 04:38, wrote:
> On Mon, May 7, 2018 at 5:16 AM Jan Beulich wrote:
>
>> While on native entry into the kernel happens on the trampoline stack,
>> PV Xen kernels are being entered with the current thread stack right
>> away. Hence source and destination stacks are identical in t
>>> On 08.05.18 at 14:18, wrote:
> On Mon, Apr 30, 2018 at 09:56:38AM -0600, Jan Beulich wrote:
>> >>> On 08.07.17 at 23:53, wrote:
>> > @@ -164,6 +165,7 @@ delete-unfresh-files:
>> > include/xen/compile.h: include/xen/compile.h.in .banner
>> >@sed -e 's/@@date@@/$(XEN_BUILD_DATE)/g' \
>> >
>>> On 08.05.18 at 14:47, wrote:
> On Fri, May 04, 2018 at 09:38:03AM -0600, Jan Beulich wrote:
>> >>> On 08.07.17 at 23:53, wrote:
>> > --- a/xen/arch/x86/Rules.mk
>> > +++ b/xen/arch/x86/Rules.mk
>> > @@ -7,6 +7,8 @@ CFLAGS += -I$(BASEDIR)/include
>> > CFLAGS += -I$(BASEDIR)/include/asm-x86/ma
>>> On 08.05.18 at 15:09, wrote:
> On Fri, May 04, 2018 at 09:46:33AM -0600, Jan Beulich wrote:
>> >>> On 08.07.17 at 23:53, wrote:
>> > --- a/xen/arch/x86/boot/head.S
>> > +++ b/xen/arch/x86/boot/head.S
>> > @@ -383,9 +383,13 @@ __efi64_mb2_start:
>> > jmp x86_32_switch
>> >
>> > .
When EFI booting the Dell PowerEdge R540 it consistently wanders into
the weeds and gets an invalid opcode in the EFI ResetSystem call. This
is the same bug which affects the PowerEdge R740 so fix it in the same
way: quirk this hardware to use the ACPI reboot method instead.
BIOS Information
V
On 14/05/18 12:28, Jan Beulich wrote:
On 08.05.18 at 04:38, wrote:
>> On Mon, May 7, 2018 at 5:16 AM Jan Beulich wrote:
>>
>>> While on native entry into the kernel happens on the trampoline stack,
>>> PV Xen kernels are being entered with the current thread stack right
>>> away. Hence sourc
>>> On 08.05.18 at 11:25, wrote:
> --- a/xen/arch/x86/hvm/vmsi.c
> +++ b/xen/arch/x86/hvm/vmsi.c
> @@ -663,6 +663,42 @@ void vpci_msi_arch_mask(struct vpci_msi *msi, const
> struct pci_dev *pdev,
> vpci_mask_pirq(pdev->domain, msi->arch.pirq + entry, mask);
> }
>
> +static int vpci_msi_up
>>> On 08.05.18 at 11:25, wrote:
> --- a/xen/arch/x86/hvm/vmsi.c
> +++ b/xen/arch/x86/hvm/vmsi.c
> @@ -699,6 +699,29 @@ static int vpci_msi_update(const struct pci_dev *pdev,
> uint32_t data,
> return 0;
> }
>
> +int vpci_msi_arch_update(struct vpci_msi *msi, const struct pci_dev *pdev)
>
>>> On 08.05.18 at 11:33, wrote:
> Class 0 devices are legacy pre PCI 2.0 devices that didn't have a
> class code. Treat them as endpoints, so that they can be handled by
> the IOMMU and properly passed-through to the hardware domain.
>
> Such device has been seen on a Super Micro server, lspci -
>>> On 09.05.18 at 22:33, wrote:
> @@ -64,6 +67,17 @@ ENTRY(pvh_start_xen)
> mov %eax,%es
> mov %eax,%ss
>
> + /* Set base address in stack canary descriptor. */
> + movl _pa(gdt_start),%eax
> + movl $_pa(canary),%ecx
> + movw %cx, (PVH_GDT_ENTRY_CANARY * 8) + 0(%eax)
On 05/14/2018, 05:04 AM, Randy Dunlap wrote:
> HTH.
Definitely, thanks for proof-reading.
--
js
suse labs
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
>>> On 10.05.18 at 11:08, wrote:
> @@ -304,6 +313,30 @@ static inline uint64_t hpet_fixup_reg(
> return new;
> }
>
> +static void timer_sanitize_int(HPETState *h, unsigned int tn)
"int" as sort of a suffix here might be misleading (could be viewed as some
sort of integer as well) - how ab
On Wed, 9 May 2018 10:18:52 -0300
Mauro Carvalho Chehab wrote:
> As we move stuff around, some doc references are broken. Fix some of
> them via this script:
> ./scripts/documentation-file-ref-check --fix-rst
>
> Manually checked if the produced result is valid, removing a few
> false-pos
>>> On 11.05.18 at 17:02, wrote:
> osstest service owner writes ("[xen-4.6-testing test] 122657: regressions -
> FAIL"):
>> flight 122657 xen-4.6-testing real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/122657/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are bloc
>>> On 13.05.18 at 01:01, wrote:
> flight 122678 xen-4.7-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/122678/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-arm64-arm64-libvirt-xsm
Jan Beulich writes ("Re: staging-4.6 seems to be broken"):
> On 11.05.18 at 17:02, wrote:
> > osstest service owner writes ("[xen-4.6-testing test] 122657: regressions -
...
> > At least some of these are surely real regressions.
>
> Are you saying that just because of the amount of failures abo
flight 122809 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122809/
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 Mon, May 14, 2018 at 06:46:08AM -0600, Jan Beulich wrote:
> >>> On 08.05.18 at 11:33, wrote:
> > Class 0 devices are legacy pre PCI 2.0 devices that didn't have a
> > class code. Treat them as endpoints, so that they can be handled by
> > the IOMMU and properly passed-through to the hardware do
>>> On 14.05.18 at 15:46, wrote:
> Jan Beulich writes ("Re: staging-4.6 seems to be broken"):
>> On 11.05.18 at 17:02, wrote:
>> > osstest service owner writes ("[xen-4.6-testing test] 122657: regressions
>> > -
> ...
>> > At least some of these are surely real regressions.
>>
>> Are you sayin
>>> On 10.05.18 at 19:15, wrote:
> ---
> xen/arch/x86/hvm/mtrr.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
What about hvm_msr_{read,write}_intercept()'s uses of MTRR_VCNT?
> @@ -683,6 +686,9 @@ static int hvm_save_mtrr_msr(struct domain *d,
> hvm_domain_context_t *
Am Thu, 10 May 2018 11:40:18 +0100
schrieb Anthony PERARD :
> I'm not sure if that information is going to help, but that what I have
> for now about the lock of block images.
I think the issue is not with two dom0s locking the same file, but with one
qemu process trying to lock the same region
On Mon, May 14, 2018 at 06:24:37AM -0600, Jan Beulich wrote:
> >>> On 08.05.18 at 11:25, wrote:
> > --- a/xen/arch/x86/hvm/vmsi.c
> > +++ b/xen/arch/x86/hvm/vmsi.c
> > @@ -663,6 +663,42 @@ void vpci_msi_arch_mask(struct vpci_msi *msi, const
> > struct pci_dev *pdev,
> > vpci_mask_pirq(pdev->
Jan Beulich writes ("Re: staging-4.6 seems to be broken"):
> Hrrrm indeed. 4.8 flight 12658 and 4.9 flight 12659 look about as bad as
> the 4.6 one you've commented on.
I took a look at the host histories for some of the hosts involved and
these failures do not seem to have occurred at the same ti
>>> On 10.05.18 at 19:15, wrote:
> Copy the state found on the hardware when creating a PVH Dom0. Since
> the memory map provided to a PVH Dom0 is based on the native one using
> the same set of MTRR ranges should provide Dom0 with a sane MTRR state
> without having to manually build it in Xen.
>
On Mon, May 14, 2018 at 06:29:37AM -0600, Jan Beulich wrote:
> >>> On 08.05.18 at 11:25, wrote:
> > --- a/xen/arch/x86/hvm/vmsi.c
> > +++ b/xen/arch/x86/hvm/vmsi.c
> > @@ -699,6 +699,29 @@ static int vpci_msi_update(const struct pci_dev *pdev,
> > uint32_t data,
> > return 0;
> > }
> >
>
From: Oleksandr Andrushchenko
This is the sync up with the canonical definition of the keyboard
protocol in Xen:
1. Add missing string constants for {feature|request}-raw-pointer
to align with the rest of the interface file.
2. Add new XenStore feature fields, so it is possible to individuall
From: Oleksandr Andrushchenko
It is now only possible to control if multi-touch virtual device
is created or not (via the corresponding XenStore entries),
but keyboard and pointer devices are always created.
In some cases this is not desirable. For example, if virtual
keyboard device is exposed t
>>> On 14.05.18 at 16:15, wrote:
> On Mon, May 14, 2018 at 06:24:37AM -0600, Jan Beulich wrote:
>> >>> On 08.05.18 at 11:25, wrote:
>> > --- a/xen/arch/x86/hvm/vmsi.c
>> > +++ b/xen/arch/x86/hvm/vmsi.c
>> > @@ -663,6 +663,42 @@ void vpci_msi_arch_mask(struct vpci_msi *msi, const
> struct pci_dev
>>> On 14.05.18 at 16:27, wrote:
> On Mon, May 14, 2018 at 06:29:37AM -0600, Jan Beulich wrote:
>> >>> On 08.05.18 at 11:25, wrote:
>> > --- a/xen/arch/x86/hvm/vmsi.c
>> > +++ b/xen/arch/x86/hvm/vmsi.c
>> > @@ -699,6 +699,29 @@ static int vpci_msi_update(const struct pci_dev
>> > *pdev, uint32_t
On Mon, May 14, 2018 at 08:56:16AM -0600, Jan Beulich wrote:
> >>> On 14.05.18 at 16:15, wrote:
> > On Mon, May 14, 2018 at 06:24:37AM -0600, Jan Beulich wrote:
> >> >>> On 08.05.18 at 11:25, wrote:
> >> > --- a/xen/arch/x86/hvm/vmsi.c
> >> > +++ b/xen/arch/x86/hvm/vmsi.c
> >> > @@ -663,6 +663,42
>>> On 14.05.18 at 17:00, wrote:
> On Mon, May 14, 2018 at 08:56:16AM -0600, Jan Beulich wrote:
>> >>> On 14.05.18 at 16:15, wrote:
>> > On Mon, May 14, 2018 at 06:24:37AM -0600, Jan Beulich wrote:
>> >> >>> On 08.05.18 at 11:25, wrote:
>> >> > --- a/xen/arch/x86/hvm/vmsi.c
>> >> > +++ b/xen/arc
On Fri, May 11, 2018 at 11:38:07AM +0100, Andrew Cooper wrote:
> All 3 bits of information here are control flags for the entry/exit code
> behaviour. Treat them as such, rather than having two different variables.
>
> Signed-off-by: Andrew Cooper
This patch does what it says on the tin.
FWIW:
>>> On 14.05.18 at 13:02, wrote:
> When EFI booting the Dell PowerEdge R540 it consistently wanders into
> the weeds and gets an invalid opcode in the EFI ResetSystem call. This
> is the same bug which affects the PowerEdge R740 so fix it in the same
> way: quirk this hardware to use the ACPI rebo
On Fri, May 11, 2018 at 11:38:08AM +0100, Andrew Cooper wrote:
> Currently, the SPEC_CTRL_{ENTRY,EXIT}_* macros encode Xen's choice of
> MSR_SPEC_CTRL as an immediate constant, and chooses between IBRS or not by
> doubling up the entire alternative block.
>
> There is now a variable holding Xen's
On Fri, May 11, 2018 at 11:38:09AM +0100, Andrew Cooper wrote:
> In hindsight, using NATIVE and VMEXIT as naming terminology was not clever.
> A future change wants to split SPEC_CTRL_EXIT_TO_GUEST into PV and HVM
> specific implementations, and using VMEXIT as a term is completely wrong.
>
> Take
On Fri, May 11, 2018 at 11:38:10AM +0100, Andrew Cooper wrote:
> In order to separately control whether MSR_SPEC_CTRL is virtualised for PV and
> HVM guests, split the feature used to control runtime alternatives into two.
> Xen will use MSR_SPEC_CTRL itself if either of these features are active.
>>> On 11.05.18 at 12:38, wrote:
> --- a/xen/arch/x86/spec_ctrl.c
> +++ b/xen/arch/x86/spec_ctrl.c
> @@ -128,7 +128,8 @@ static void __init print_details(enum ind_thunk thunk,
> uint64_t caps)
> thunk == THUNK_RETPOLINE ? "RETPOLINE" :
> thunk == THUNK_LFENCE? "LFENCE"
>>> On 11.05.18 at 12:38, wrote:
> In hindsight, the end result of the Spectre mitigations aren't as great as I'd
> hoped, and have several inefficiencies. Also, the `bti=` command line option
> isn't as flexible as intended.
>
> This series does four things:
>
> 1) Some internal cleanup, for
On Fri, May 11, 2018 at 11:38:11AM +0100, Andrew Cooper wrote:
> @@ -417,6 +419,32 @@ void __init init_speculation_mitigations(void)
> setup_clear_cpu_cap(X86_FEATURE_NO_XPTI);
>
> print_details(thunk, caps);
> +
> +/*
> + * If MSR_SPEC_CTRL is available, apply Xen's default
On Fri, May 11, 2018 at 11:38:14AM +0100, Andrew Cooper wrote:
> If Xen is virtualising MSR_SPEC_CTRL handling for guests, but using 0 as its
> own MSR_SPEC_CTRL value, spec_ctrl_{enter,exit}_idle() need not write to the
> MSR.
>
> Requested-by: Jan Beulich
> Signed-off-by: Andrew Cooper
> ---
>
>>> On 14.05.18 at 17:39, wrote:
> On Fri, May 11, 2018 at 11:38:11AM +0100, Andrew Cooper wrote:
>> @@ -417,6 +419,32 @@ void __init init_speculation_mitigations(void)
>> setup_clear_cpu_cap(X86_FEATURE_NO_XPTI);
>>
>> print_details(thunk, caps);
>> +
>> +/*
>> + * If MSR_
On Mon, 14 May 2018 08:27:36 +0200,
Oleksandr Andrushchenko wrote:
>
> From: Oleksandr Andrushchenko
>
> Please note: this patch series depends on [3].
>
> This patch series adds support for Xen [1] para-virtualized
> sound frontend driver. It implements the protocol from
> include/xen/interfac
On Thu, May 10, 2018 at 06:15:04PM +0100, Roger Pau Monne wrote:
> @@ -1014,6 +1034,30 @@ static int vcpu_hvm(struct xc_dom_image *dom)
> if ( dom->start_info_seg.pfn )
> bsp_ctx.cpu.rbx = dom->start_info_seg.pfn << PAGE_SHIFT;
>
> +/* Set the MTRR. */
> +bsp_ctx.mtrr_d.type
On Mon, May 14, 2018 at 05:00:51PM +0100, Wei Liu wrote:
> On Thu, May 10, 2018 at 06:15:04PM +0100, Roger Pau Monne wrote:
> > @@ -1014,6 +1034,30 @@ static int vcpu_hvm(struct xc_dom_image *dom)
> > if ( dom->start_info_seg.pfn )
> > bsp_ctx.cpu.rbx = dom->start_info_seg.pfn << PAGE
On Thu, May 10, 2018 at 06:15:05PM +0100, Roger Pau Monne wrote:
> Provided to both Dom0 and DomUs.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Jan Beulich
> Cc: Julien Grall
> Cc: Konrad Rzeszutek Wilk
> Cc: Stefano Stabellini
>
On 05/14/2018 06:52 PM, Takashi Iwai wrote:
On Mon, 14 May 2018 08:27:36 +0200,
Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Please note: this patch series depends on [3].
This patch series adds support for Xen [1] para-virtualized
sound frontend driver. It implements the prot
>>> On 14.05.18 at 18:03, wrote:
> On Thu, May 10, 2018 at 06:15:05PM +0100, Roger Pau Monne wrote:
>> --- a/docs/misc/pvh.markdown
>> +++ b/docs/misc/pvh.markdown
>> @@ -92,3 +92,18 @@ event channels. Delivery of those interrupts can be
>> configured in the same way
>> as HVM guests, check xen/
On Mon, May 14, 2018 at 05:03:52PM +0100, Wei Liu wrote:
> On Thu, May 10, 2018 at 06:15:05PM +0100, Roger Pau Monne wrote:
> > Provided to both Dom0 and DomUs.
> >
> > Signed-off-by: Roger Pau Monné
> > ---
> > Cc: Andrew Cooper
> > Cc: George Dunlap
> > Cc: Ian Jackson
> > Cc: Jan Beulich
>
On Mon, May 14, 2018 at 10:13:47AM -0600, Jan Beulich wrote:
> >>> On 14.05.18 at 18:03, wrote:
> > On Thu, May 10, 2018 at 06:15:05PM +0100, Roger Pau Monne wrote:
> >> --- a/docs/misc/pvh.markdown
> >> +++ b/docs/misc/pvh.markdown
> >> @@ -92,3 +92,18 @@ event channels. Delivery of those interru
On 05/14/2018 04:17 PM, Jan Beulich wrote:
On 14.05.18 at 13:02, wrote:
When EFI booting the Dell PowerEdge R540 it consistently wanders into
the weeds and gets an invalid opcode in the EFI ResetSystem call. This
is the same bug which affects the PowerEdge R740 so fix it in the same
way: quirk
On Mon, May 14, 2018 at 04:30:02AM -0600, Jan Beulich wrote:
> >>> On 08.05.18 at 14:18, wrote:
> > On Mon, Apr 30, 2018 at 09:56:38AM -0600, Jan Beulich wrote:
> >> >>> On 08.07.17 at 23:53, wrote:
> >> > @@ -164,6 +165,7 @@ delete-unfresh-files:
> >> > include/xen/compile.h: include/xen/compil
On Mon, May 14, 2018 at 05:16:10PM +0100, Roger Pau Monné wrote:
> On Mon, May 14, 2018 at 05:03:52PM +0100, Wei Liu wrote:
> > On Thu, May 10, 2018 at 06:15:05PM +0100, Roger Pau Monne wrote:
> > > Provided to both Dom0 and DomUs.
> > >
> > > Signed-off-by: Roger Pau Monné
> > > ---
> > > Cc: An
On Mon, May 14, 2018 at 08:26:30AM -0600, Jan Beulich wrote:
> >>> On 10.05.18 at 19:15, wrote:
> > Copy the state found on the hardware when creating a PVH Dom0. Since
> > the memory map provided to a PVH Dom0 is based on the native one using
> > the same set of MTRR ranges should provide Dom0 wi
On Mon, May 14, 2018 at 05:02:47PM +0100, Roger Pau Monné wrote:
> On Mon, May 14, 2018 at 05:00:51PM +0100, Wei Liu wrote:
> > On Thu, May 10, 2018 at 06:15:04PM +0100, Roger Pau Monne wrote:
> > > @@ -1014,6 +1034,30 @@ static int vcpu_hvm(struct xc_dom_image *dom)
> > > if ( dom->start_info
On Mon, May 14, 2018 at 05:42:53PM +0100, Wei Liu wrote:
> On Mon, May 14, 2018 at 05:02:47PM +0100, Roger Pau Monné wrote:
> > On Mon, May 14, 2018 at 05:00:51PM +0100, Wei Liu wrote:
> > > On Thu, May 10, 2018 at 06:15:04PM +0100, Roger Pau Monne wrote:
> > > > @@ -1014,6 +1034,30 @@ static int v
On Mon, May 14, 2018 at 04:40:39AM -0600, Jan Beulich wrote:
> >>> On 08.05.18 at 14:47, wrote:
> > On Fri, May 04, 2018 at 09:38:03AM -0600, Jan Beulich wrote:
> >> >>> On 08.07.17 at 23:53, wrote:
> >> > --- a/xen/arch/x86/Rules.mk
> >> > +++ b/xen/arch/x86/Rules.mk
> >> > @@ -7,6 +7,8 @@ CFLAG
On Mon, May 14, 2018 at 05:42:53PM +0100, Wei Liu wrote:
> On Mon, May 14, 2018 at 05:02:47PM +0100, Roger Pau Monné wrote:
> > On Mon, May 14, 2018 at 05:00:51PM +0100, Wei Liu wrote:
> > > On Thu, May 10, 2018 at 06:15:04PM +0100, Roger Pau Monne wrote:
> > > > @@ -1014,6 +1034,30 @@ static int v
On Mon, May 14, 2018 at 04:43:13AM -0600, Jan Beulich wrote:
> >>> On 08.05.18 at 15:09, wrote:
> > On Fri, May 04, 2018 at 09:46:33AM -0600, Jan Beulich wrote:
> >> >>> On 08.07.17 at 23:53, wrote:
> >> > --- a/xen/arch/x86/boot/head.S
> >> > +++ b/xen/arch/x86/boot/head.S
> >> > @@ -383,9 +383,
On Mon, 14 May 2018, Julien Grall wrote:
> On 11/05/18 22:47, Stefano Stabellini wrote:
> > On Fri, 11 May 2018, Dario Faggioli wrote:
> > > On Fri, 2018-05-11 at 14:08 +0100, Julien Grall wrote:
> > > > The whole idea here is we have only one place taking the decision and
> > > > we
> > > > don't
On Thu, May 10, 2018 at 09:38:26AM +1000, John Thomson wrote:
> Hi,
> Trying to build Xen staging with GCC 8.1.0 and facing some of the new
> warnings:
>
> For OVMF, I used these three commits:
> https://github.com/tianocore/edk2/compare/1d212a83df0eaf32a6f5d4159beb2d77832e0231^...9de306701312f98
In order to support auditing of qemu depriv, my audit tool wants to
know the fd of a privcmd handle on which it can easily make
hypercalls. xencall provides such a handle, but has no cooked
facilities for making hypercalls. So I open a libxc handle. That
means I need to get the privcmd fd out of
I want this to support my qemu depriv descriptor audit tool.
Signed-off-by: Ian Jackson
---
tools/libs/call/core.c| 5 +
tools/libs/call/include/xencall.h | 8
tools/libs/call/libxencall.map| 1 +
tools/libs/gnttab/gntshr_core.c | 6 ++
tool
Add mention of LIBXL_QEMU_USER_RANGE_BASE, in case that is what the
user was intending.
Signed-off-by: Ian Jackson
---
tools/libxl/libxl_dm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 18ada69..7289509 100644
---
I am working on auditing whether deprvileging qemu has actually
worked. The approach I have chosen is to fish the descriptors out of
qemu (by using debugging facilities), and try to make hypercalls
etc. using them.
To take making a hypercall as an example: this is not easily done
without libxc.
These functions are no longer defined or used anywhere. The
declarations should have been deleted when the definitions were.
Signed-off-by: Ian Jackson
---
tools/libxc/xc_private.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
index 03
On Sat, May 12, 2018 at 08:55:46PM +0800, Kun Cheng wrote:
> Hello Xen devs,
>
> I'm learning code in xen-4.10.0/tools/xl to find out how to program with
> libxl.
>
> I've trying to use libxenlight.so (compiled and installed from xen 4.10.0
> source code) to control my vms from my own code until
On 14/05/18 17:22, Ross Lagerwall wrote:
> On 05/14/2018 04:17 PM, Jan Beulich wrote:
> On 14.05.18 at 13:02, wrote:
>>> When EFI booting the Dell PowerEdge R540 it consistently wanders into
>>> the weeds and gets an invalid opcode in the EFI ResetSystem call. This
>>> is the same bug which af
On 14/05/18 18:08, Ian Jackson wrote:
> diff --git a/tools/libs/call/libxencall.map b/tools/libs/call/libxencall.map
> index 2f96144..299ca38 100644
> --- a/tools/libs/call/libxencall.map
> +++ b/tools/libs/call/libxencall.map
> @@ -2,6 +2,7 @@ VERS_1.0 {
> global:
> xencall_ope
On Fri, May 11, 2018 at 5:11 AM, Alexandru Isaila
wrote:
> Signed-off-by: Alexandru Isaila
Acked-by: Tamas K Lengyel
> ---
> xen/include/asm-x86/monitor.h | 13 +
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86
On Mon, May 14, 2018 at 1:03 PM, Wei Liu wrote:
> On Thu, May 10, 2018 at 09:38:26AM +1000, John Thomson wrote:
>>
>> /build/xen-git/src/xen/stubdom/tpm_emulator-x86_64/tpm/tpm_deprecated.c:437:7:
>> error: 'memcmp' reading 20 bytes from a region of size 8
>> [-Werror=stringop-overflow=]
>>i
On 05/14/2018 08:50 AM, Jan Beulich wrote:
On 09.05.18 at 22:33, wrote:
>> @@ -64,6 +67,17 @@ ENTRY(pvh_start_xen)
>> mov %eax,%es
>> mov %eax,%ss
>>
>> +/* Set base address in stack canary descriptor. */
>> +movl _pa(gdt_start),%eax
>> +movl $_pa(canary),%ecx
>> +
On Mon, 14 May 2018 08:27:40 +0200,
Oleksandr Andrushchenko wrote:
> --- /dev/null
> +++ b/sound/xen/xen_snd_front_shbuf.c
> @@ -0,0 +1,193 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +
> +/*
> + * Xen para-virtual sound device
> + *
> + * Copyright (C) 2016-2018 EPAM Systems Inc.
> + *
> +
flight 122722 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122722/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm broken
test-arm64-arm64-xl
On Tue, 15 May 2018, at 04:20, Jason Andryuk wrote:
> > On Thu, May 10, 2018 at 09:38:26AM +1000, John Thomson wrote:
> >> /build/xen-git/src/xen/stubdom/tpm_emulator-x86_64/tpm/tpm_deprecated.c:437:7:
> >> error: 'memcmp' reading 20 bytes from a region of size 8
> >> [-Werror=stringop-overflow=]
CC xenctrl_stubs.o
xenctrl_stubs.c: In function 'failwith_xc':
xenctrl_stubs.c:65:17: error: 'snprintf' output may be truncated before the
last format character [-Werror=format-truncation=]
"%d: %s: %s", error->code,
^
xenctrl_stubs.c:64:4: note: 'snprintf' output 6 o
> > Here is a patch-series which adding Processor Trace enabling in XEN
> > guest. You can get It's software developer manuals from:
> > https://software.intel.com/sites/default/files/managed/c5/15/archi
> > te ct ure-instruction-set-extensions-programming-reference.pdf
> > In
Thank you, Wei.
I have solved it. The error accured as 'ctx' was not correctly initailized.
On Tue, May 15, 2018 at 1:11 AM Wei Liu wrote:
> On Sat, May 12, 2018 at 08:55:46PM +0800, Kun Cheng wrote:
> > Hello Xen devs,
> >
> > I'm learning code in xen-4.10.0/tools/xl to find out how to program
flight 122723 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122723/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm broken
test-arm64-arm64-xl
On 05/14/2018 11:28 PM, Takashi Iwai wrote:
On Mon, 14 May 2018 08:27:40 +0200,
Oleksandr Andrushchenko wrote:
--- /dev/null
+++ b/sound/xen/xen_snd_front_shbuf.c
@@ -0,0 +1,193 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+
+/*
+ * Xen para-virtual sound device
+ *
+ * Copyright (C) 2016-2018
On Tue, 15 May 2018 07:46:38 +0200,
Oleksandr Andrushchenko wrote:
>
> On 05/14/2018 11:28 PM, Takashi Iwai wrote:
> > On Mon, 14 May 2018 08:27:40 +0200,
> > Oleksandr Andrushchenko wrote:
> >> --- /dev/null
> >> +++ b/sound/xen/xen_snd_front_shbuf.c
> >> @@ -0,0 +1,193 @@
> >> +// SPDX-License-I
On 05/15/2018 09:01 AM, Takashi Iwai wrote:
On Tue, 15 May 2018 07:46:38 +0200,
Oleksandr Andrushchenko wrote:
On 05/14/2018 11:28 PM, Takashi Iwai wrote:
On Mon, 14 May 2018 08:27:40 +0200,
Oleksandr Andrushchenko wrote:
--- /dev/null
+++ b/sound/xen/xen_snd_front_shbuf.c
@@ -0,0 +1,193 @@
+/
94 matches
Mail list logo
