From: Shannon Zhao
Commit 9fd08b4 (efi: split out efi_get_gop()) splits out the
codes getting the pointer to GOP as efi_get_gop(), but it doesn't
initialize the variable handles and gop to NULL like what the original
codes do. This will cause booting failure on ARM while printing below
logs:
flight 63911 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63911/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 3 host-install(3) broken REGR. vs. 63662
test-amd64-amd64-xl-
Thanks for your effort on this series and kindly ping..
Thanks,
Feng
> -Original Message-
> From: Wu, Feng
> Sent: Tuesday, November 3, 2015 4:43 PM
> To: xen-devel@lists.xen.org
> Cc: Wu, Feng
> Subject: [PATCH v9 00/17] Add VT-d Posted-Interrupts support
>
> VT-d Posted-Interrupts is
As usual. Security, performance, convenience, price. Pick any mixture.
As is usual for most software, developer convenience trumps most other
considerations. I include ease of generating nice papers and jobs
under developer convenience.
Big players are much more concerned about performance, which
On Mon, Nov 09, 2015 at 04:31:58PM +, Franz wrote:
> Perhaps a way out of this impasse is to put bounties on Xen security tasks
> identified by Joanna and properly advertise these bounties to Xen users.
> [snip]
This is fundamentaly wrong idea. Security isn't something you can
"apply" or put b
On Mon, Nov 9, 2015 at 12:11 PM, Jan Beulich wrote:
> >>> On 06.11.15 at 18:22, wrote:
> > 1. First of all, I wish Xen was somehow more defensively coded. To
> provide
> > some
> > examples:
> >
> > a. In XSA-109 [5] there was a problem with the hypervisor dereferencing a
> > NULL
> > pointer. T
flight 63888 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63888/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 3 host-install(3) broken REGR. vs. 59254
test-amd64-amd64-xl-q
From: Fu Wei
This patch delete "file_name_index" variable and related comment.
They are for xen_module command which has been deleted.
Signed-off-by: Fu Wei
---
grub-core/loader/arm64/xen_boot.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/grub-core/
From: Fu Wei
xen_hypervisor
xen_linux
xen_initrd
xen_xsm
Signed-off-by: Fu Wei
---
docs/grub.texi | 38 ++
1 file changed, 38 insertions(+)
diff --git a/docs/grub.texi b/docs/grub.texi
index db765a3..1df3db2 100644
--- a/docs/grub.texi
+++ b
On 09.11.2015 17:15, Wei Liu wrote:
I accidentally deleted my old script, so I take the chance to change
the tracking email a bit. Now this email only tracks big items for
xen.git tree. Please reply for items you woulk like to see in 4.7 so
that people have an idea what is going on and prioritise
flight 63903 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63903/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 5 libvirt-build fail REGR. vs. 63340
Tests which did not succe
On 11/09/15 11:06, Riku Voipio wrote:
> In commit:
>
> d37d63d symbols: prefix static symbols with their source file names
>
> An unchecked fgets was added. This causes a compile error at least
> on ubuntu utopic:
>
> symbols.c: In function 'read_symbol':
> symbols.c:181:3: error: ignoring retur
Liuqiming (John) wrote on 2015-10-10:
>
> On 2015/10/10 14:32, Zhang, Yang Z wrote:
>> Zhang, Yang Z wrote on 2015-09-24:
>>> Liuqiming (John) wrote on 2015-09-24:
On 2015/9/24 11:25, Zhang, Yang Z wrote:
it completed, the following vmentry will pick up the pending interrupt.
>
On 10.11.2015 at 12:16, wrote:
> * VT-d asynchronous flush issue
> - Tian, Kevin
>
Wei, I will send out patch set for it.
-Quan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2015-5307,CVE-2015-8104 / XSA-156
version 2
x86: CPU lockup during exception delivery
UPDATES IN VERSION 2
Minor title and text adjustment.
CVE-2015-81
flight 63866 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63866/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 5 kernel-build fail REGR. vs. 62648
Tests which are failin
flight 63860 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63860/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 3 host-install(3) broken REGR. vs. 62642
build-armhf-pvops
flight 63859 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63859/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-boot fail REGR. vs. 62277
test-amd64-i386-xl-qemu
+1... so many great points here that ive thought many times its almost as
if i could have written it
great post!
chris
On Fri, Nov 6, 2015 at 12:22 PM, Joanna Rutkowska <
joa...@invisiblethingslab.com> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello,
>
> Recently Xen has rele
On 11/6/15 11:22 AM, Joanna Rutkowska wrote:
> Hello,
>
> Recently Xen has released the XSA-148 advisory [1] addressing a fatal bug in
> the
> hypervisor. The bug has been lurking there for the last 7 years! We, the Qubes
> OS Project, have commented on this in our Security Bulletin #22 [2]. And
On Monday 09 November 2015 17:42:50 Stefano Stabellini wrote:
> On Mon, 9 Nov 2015, Stefano Stabellini wrote:
> > On Mon, 9 Nov 2015, Arnd Bergmann wrote:
> > > On Monday 09 November 2015 14:10:22 Stefano Stabellini wrote:
> > >
> > > Just to make sure that this is actually the correct interface
>
On Monday 09 November 2015 17:14:24 Stefano Stabellini wrote:
> On Mon, 9 Nov 2015, Arnd Bergmann wrote:
> > On Monday 09 November 2015 13:53:30 Stefano Stabellini wrote:
> > > On Fri, 6 Nov 2015, Arnd Bergmann wrote:
> > > > I'm not quite sure about how the split between pvclock_wall_clock and
> >
On 09.11.2015 16:39, Daniel Kiper wrote:
> On Mon, Nov 09, 2015 at 04:34:20PM +0100, Vladimir 'φ-coder/phcoder'
> Serbinenko wrote:
>> On 09.11.2015 16:29, Daniel Kiper wrote:
>>> On Wed, Nov 04, 2015 at 01:03:56PM +0100, Vladimir 'phcoder' Serbinenko
>>> wrote:
Le 12 août 2015 11:04 AM, "Ia
On 20.07.2015 16:35, Daniel Kiper wrote:
> Signed-off-by: Daniel Kiper
What is handling the actual relocation? Why doesn't this patch include
support for ELF relocations?
> ---
> grub-core/loader/i386/multiboot_mbi.c |6 ++--
> grub-core/loader/multiboot.c | 12 +--
> grub-core
On 20.07.2015 16:35, Daniel Kiper wrote:
> Add grub_relocator64_efi relocator. It will be used on EFI 64-bit platforms
> when multiboot2 compatible image requests MULTIBOOT_TAG_TYPE_EFI_BS. Relocator
> will set lower parts of %rax and %rbx accordingly to multiboot2 specification.
> On the other han
On 21.07.2015 08:42, Andrei Borzenkov wrote:
> On Mon, Jul 20, 2015 at 5:35 PM, Daniel Kiper wrote:
>> malloc_in_range() should not use memory region if its starta is smaller
>> than size. Otherwise target wraps around and points to region which is
>> usually not a RAM, e.g.:
>>
>> loader/multiboo
On 11/9/15 9:06 AM, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 06, 2015 at 05:11:51PM +0100, Ian Campbell wrote:
>> On Tue, 2015-10-06 at 10:58 -0500, Doug Goldstein wrote:
>>> You stated this better than I did. My goal is not to necessarily make
>>> this like the Linux kernel where users toggle on
Chunyan Liu writes ("[PATCH V8 3/7] libxl: add pvusb API"):
> Add pvusb APIs, including:
> - attach/detach (create/destroy) virtual usb controller.
> - attach/detach usb device
> - list usb controller and usb devices
> - some other helper functions
Thanks for this.
I have reviewed it in deta
On Mon, 9 Nov 2015, Stefano Stabellini wrote:
> On Mon, 9 Nov 2015, Arnd Bergmann wrote:
> > On Monday 09 November 2015 14:10:22 Stefano Stabellini wrote:
> > > On Thu, 5 Nov 2015, Arnd Bergmann wrote:
> > > > On Thursday 05 November 2015 17:09:45 Stefano Stabellini wrote:
> > > > > + now = __c
On Thu, Nov 05, 2015 at 05:30:01PM +, Stefano Stabellini wrote:
> On Thu, 5 Nov 2015, Peter Zijlstra wrote:
> > How can this be missing? Things compile fine now, right?
>
> Fair enough.
>
>
> > So please better explain why we do this change.
>
> asm/paravirt.h is included by one of the othe
From: Stefano Stabellini
Remove dummy arm implementation of wallclock_time.
Use shared_info() in common code rather than x86-ism to access it, when
possible.
Define the static variable wc_sec, and the local variale sec in
update_domain_wallclock_time, as uint64_t instead of unsigned long, to
avo
From: Stefano Stabellini
Call update_domain_wallclock_time at domain initialization, specifically
in arch_set_info_guest for vcpu0, like we do on x86.
Set time_offset_seconds to the number of seconds between phisical boot
and domain initialization: it is going to be used to get/set the
wallclock
Hi all,
this small series enables the wallclock time on arm and it consists
mostly in code movement from x86 to common.
Changes in v2:
- remove stray blank lines
- remove include
- move version_update_* to include/xen/time.h
- introduce ifdef to fix build issue in common/time.c
- define wc_sec
On 11/06/2015 07:36 PM, Konrad Rzeszutek Wilk wrote:
From: Martin Pohlack
The mechanism to get this is via the XENVER_build_id and
we add a new subsequent sub-command to retrieve the
binary build-id. The hypercall allows an arbitrary
size (the buffer and len is provided to the hypervisor).
Not
On Mon, 9 Nov 2015, Arnd Bergmann wrote:
> On Monday 09 November 2015 14:10:22 Stefano Stabellini wrote:
> > On Thu, 5 Nov 2015, Arnd Bergmann wrote:
> > > On Thursday 05 November 2015 17:09:45 Stefano Stabellini wrote:
> > > > + now = __current_kernel_time();
> > >
> > > We don't have __cur
On Mon, 9 Nov 2015, Arnd Bergmann wrote:
> On Monday 09 November 2015 13:53:30 Stefano Stabellini wrote:
> > On Fri, 6 Nov 2015, Arnd Bergmann wrote:
> > > I'm not quite sure about how the split between pvclock_wall_clock and
> > > the delta works. Normally I'd expect that pvclock_wall_clock is the
On Thu, 5 Nov 2015, Julien Grall wrote:
> Hi Stefano,
>
> You forgot to CC Daniel for the XSM part. Please use
> scripts/get_maintainers.pl to get the relevant maintainers.
>
> On 05/11/15 16:57, Stefano Stabellini wrote:
> > Call update_domain_wallclock_time at domain initialization.
>
> It's n
On Mon, Nov 09, 2015 at 04:15:45PM +, Wei Liu wrote:
> I accidentally deleted my old script, so I take the chance to change
> the tracking email a bit. Now this email only tracks big items for
> xen.git tree. Please reply for items you woulk like to see in 4.7 so
> that people have an idea what
On Monday 09 November 2015 13:53:30 Stefano Stabellini wrote:
> On Fri, 6 Nov 2015, Arnd Bergmann wrote:
> > I'm not quite sure about how the split between pvclock_wall_clock and
> > the delta works. Normally I'd expect that pvclock_wall_clock is the
> > wallclock
> > time as it was at boot, while
I accidentally deleted my old script, so I take the chance to change
the tracking email a bit. Now this email only tracks big items for
xen.git tree. Please reply for items you woulk like to see in 4.7 so
that people have an idea what is going on and prioritise accordingly.
= Timeline =
We now ad
On Monday 09 November 2015 14:10:22 Stefano Stabellini wrote:
> On Thu, 5 Nov 2015, Arnd Bergmann wrote:
> > On Thursday 05 November 2015 17:09:45 Stefano Stabellini wrote:
> > > + now = __current_kernel_time();
> >
> > We don't have __current_kernel_time64() yet, but it is trivial
> > to add, jus
On Mon, Nov 09, 2015 at 03:51:48PM +, Julien Grall wrote:
> Hi,
>
> Any comments on this new version?
I completly ignored thinking that the:
c004a6f block/xen-blkfront: Make it running on 64KB page granularity
4f503fb block/xen-blkfront: split get_grant in 2
a7a6df2 block/xen-blkfront: Store
On Mon, Nov 09, 2015 at 04:47:20PM +0100, Dario Faggioli wrote:
> On Mon, 2015-11-09 at 15:23 +, Ian Campbell wrote:
> > On Mon, 2015-11-09 at 16:14 +0100, Dario Faggioli wrote:
> > >
> > > > As far as xl accessibility --- doesn't xenperf already read them
> > > > out?
> > > >
> > > Mmm... I
Hi,
Any comments on this new version?
Regards,
On 19/10/15 15:19, Julien Grall wrote:
> Hi all,
>
> This is a follow-up on the previous discussion [1] related to guest using 64KB
> page granularity which doesn't boot when the backend isn't using indirect
> descriptor.
>
> This has been success
On Mon, Nov 09, 2015 at 03:03:17PM +, George Dunlap wrote:
> So I had a user report that he couldn't get the vnclisten option to
> work. It turns out he was using a PV guest, and had the following in
> his config file:
>
> vfb=[ 'type=vnc' ]
> vnclisten='0.0.0.0'
>
> After digging around in
Xen is currently directly storing the value of GICD_ITARGETSR register
(for GICv2) and GICD_IROUTER (for GICv3) in the rank. This makes the
emulation of the registers access very simple but makes the code to get
the target vCPU for a given vIRQ more complex.
While the target vCPU of an vIRQ is ret
and use them in the vGIC emulation.
The GIC registers may support different access sizes. Rather than open
coding the access for every registers, provide a set of helpers to access
them.
The caller will have to call vgic_regN_* where N is the size of the
emulated registers.
The new helpers suppo
Based on 8.1.3 (IHI 0069A), unless stated otherwise, the 64-bit registers
supports both 32-bit and 64-bits access.
All the registers we properly emulate (i.e not RAZ/WI) supports 32-bit access.
For RAZ/WI, it's also seems to be the case but I'm not 100% sure. Anyway,
emulating 32-bit access for t
Each ITARGETSR register are 4-byte wide and the offset is in byte.
The current implementation is computing the end of the range wrongly
resulting to emulate only ITARGETSR{0,1} read-only. The rest will be
treated as read-write.
As 8 registers should be read-only, the end of the range should be
IT
Hi all,
This series aims to fix the 32-bit access on 64-bit registers. Some guest
OS such as FreeBSD and Linux (ITS and recently 32-bit guest using GICv3)
use 32-bit access and will crash at boot time.
For all the changes see in each patch.
Sincerely yours,
Julien Grall (6):
xen/arm: vgic-v2:
The current implementation ignores the whole write if one of the field is
0. Although, based on the spec (4.3.12 IHI 0048B.b), 0 is a valid value
when:
- The interrupt is not wired in the distributor. From the Xen
point of view, it means that the corresponding bit is not set in
d->arch.
During a store, the byte is always in the low part of the register (i.e
[0:7]).
We are incorrectly masking the register by using a shift of the byte
offset in the ITARGETSR while the byte is alwasy in r[0:7]. This will
result in a target list equal to 0 which is ignored by the emulation.
Because
On Mon, 2015-11-09 at 15:23 +, Ian Campbell wrote:
> On Mon, 2015-11-09 at 16:14 +0100, Dario Faggioli wrote:
> >
> > > As far as xl accessibility --- doesn't xenperf already read them
> > > out?
> > >
> > Mmm... ISTR having tried without much luck, and having heard that
> > it
> > wasn't fu
On Mon, Nov 09, 2015 at 04:34:20PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> On 09.11.2015 16:29, Daniel Kiper wrote:
> > On Wed, Nov 04, 2015 at 01:03:56PM +0100, Vladimir 'phcoder' Serbinenko
> > wrote:
> >> Le 12 août 2015 11:04 AM, "Ian Campbell" a écrit
> >> :
> >>>
> >>>
> >>>
On 09.11.2015 16:29, Daniel Kiper wrote:
> On Wed, Nov 04, 2015 at 01:03:56PM +0100, Vladimir 'phcoder' Serbinenko wrote:
>> Le 12 août 2015 11:04 AM, "Ian Campbell" a écrit :
>>>
>>>
>>> (Having written the below I see too late that this is a grub patch not a
>>> Xen one, a tag in the subject for
>>> On 06.11.15 at 17:05, wrote:
> Signed-off-by: Roger Pau Monné
> Reported by: Boris Ostrovsky
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Wed, Nov 04, 2015 at 01:03:56PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> Le 12 août 2015 11:04 AM, "Ian Campbell" a écrit :
> >
> >
> > (Having written the below I see too late that this is a grub patch not a
> > Xen one, a tag in the subject for such cross posted patches would be
> useful
On Mon, 2015-11-09 at 16:14 +0100, Dario Faggioli wrote:
>
> > As far as xl accessibility --- doesn't xenperf already read them out?
> >
> Mmm... ISTR having tried without much luck, and having heard that it
> wasn't functional any longer, but maybe I'm confusing it with something
> else. I'll tr
On Mon, 2015-11-09 at 10:02 -0500, Boris Ostrovsky wrote:
> On 11/09/2015 09:53 AM, Dario Faggioli wrote:
> > On Mon, 2015-11-09 at 14:00 +, Ian Campbell wrote:
> > > Signed-off-by: Ian Campbell
> > >
> > Reviewed-by: Dario Faggioli
> >
> > And, while we're here, I've been thinking since a
On 10/23/2015 03:04 PM, Juergen Gross wrote:
This series is a combination of my previous patches:
"libxc: remove most of tools/libxc/xc_dom_compat_linux.c"
"tools: remove unused wrappers for python"
I have split it up as requested by Ian Campbell, thus it consists of
13 patches instead just of
>>> On 09.11.15 at 16:02, wrote:
> On 09/11/15 14:52, Jan Beulich wrote:
>> As noted regarding the mixture of checks in p2m_pt_set_entry(),
>> introduce an new P2M type group allowing to be used everywhere we
>
> "a new P2M"
>
>> just care about accepting operations with either a valid MFN or a
On Tue, Oct 06, 2015 at 05:11:51PM +0100, Ian Campbell wrote:
> On Tue, 2015-10-06 at 10:58 -0500, Doug Goldstein wrote:
> > You stated this better than I did. My goal is not to necessarily make
> > this like the Linux kernel where users toggle on different bits at a
> > whim but more for developer
>>> On 06.11.15 at 17:05, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -5143,6 +5143,7 @@ static hvm_hypercall_t *const
> hvm_hypercall64_table[NR_hypercalls] = {
> HYPERCALL(sysctl),
> HYPERCALL(domctl),
> HYPERCALL(tmem_op),
> +HYPERCALL(xenpmu_op
On 11/09/2015 09:53 AM, Dario Faggioli wrote:
On Mon, 2015-11-09 at 14:00 +, Ian Campbell wrote:
Signed-off-by: Ian Campbell
Reviewed-by: Dario Faggioli
And, while we're here, I've been thinking since a while to try
implementing an xl interface for these counters... How bad of an idea
i
So I had a user report that he couldn't get the vnclisten option to
work. It turns out he was using a PV guest, and had the following in
his config file:
vfb=[ 'type=vnc' ]
vnclisten='0.0.0.0'
After digging around in the code, it turns out that the following is
accepted for PV guests:
vnc=1
vnc
On 09/11/15 14:52, Jan Beulich wrote:
> As noted regarding the mixture of checks in p2m_pt_set_entry(),
> introduce an new P2M type group allowing to be used everywhere we
"a new P2M"
> just care about accepting operations with either a valid MFN or a type
> permitting to be used without (valid)
On Mon, 2015-11-09 at 14:00 +, Ian Campbell wrote:
> Signed-off-by: Ian Campbell
>
Reviewed-by: Dario Faggioli
And, while we're here, I've been thinking since a while to try
implementing an xl interface for these counters... How bad of an idea
is that?
Is something like that possible alread
As noted regarding the mixture of checks in p2m_pt_set_entry(),
introduce an new P2M type group allowing to be used everywhere we
just care about accepting operations with either a valid MFN or a type
permitting to be used without (valid) MFN.
Note that p2m_mmio_dm is not included in P2M_NO_MFN_TY
Since calling the function isn't cheap, try to avoid the call when we
know up front it won't help; see the code comment for details on those
conditions.
Signed-off-by: Jan Beulich
---
v2: Adjust conditions and body of the if() to make them easier
understandable, without altering behavior (req
>>> On 09.11.15 at 15:24, wrote:
> On 09/11/15 14:20, Ian Campbell wrote:
>> On Mon, 2015-11-09 at 07:11 -0700, Jan Beulich wrote:
>> On 09.11.15 at 15:01, wrote:
SPIs are too numerous and not indivcidually as interesting.
Make the exists #IPIS counter x86 specific.
>>>
>>> I'd
Hi,
On 09/11/15 14:20, Ian Campbell wrote:
> On Mon, 2015-11-09 at 07:11 -0700, Jan Beulich wrote:
> On 09.11.15 at 15:01, wrote:
>>> SPIs are too numerous and not indivcidually as interesting.
>>>
>>> Make the exists #IPIS counter x86 specific.
>>
>> I'd recommend not to - even if ARM doesn'
Hi Matthew,
Can you please try with mpt2sas driver's max_msix_vectors set to one.
~Sreekanth
On Fri, Nov 6, 2015 at 11:38 PM, Matthew Vernon wrote:
> Hi,
>
> [These lists are in the MAINTAINERS file for mpt2sas; I hope this is
> the correct place to report this problem. Xen-devel CCd as this is
On Mon, 2015-11-09 at 07:11 -0700, Jan Beulich wrote:
> > > > On 09.11.15 at 15:01, wrote:
> > SPIs are too numerous and not indivcidually as interesting.
> >
> > Make the exists #IPIS counter x86 specific.
>
> I'd recommend not to - even if ARM doesn't want to use it, it's still a
> pretty gene
On 09/11/15 14:00, Ian Campbell wrote:
> Signed-off-by: Ian Campbell
Reviewed-by: George Dunlap
> ---
> xen/common/schedule.c| 1 +
> xen/include/xen/perfc_defn.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> index 292e9a0..
>>> On 06.11.15 at 18:37, wrote:
> --- a/xen/arch/x86/mm/mm-locks.h
> +++ b/xen/arch/x86/mm/mm-locks.h
> @@ -263,14 +263,21 @@ declare_mm_lock(altp2mlist)
> */
>
> declare_mm_rwlock(altp2m);
> -#define p2m_lock(p) \
> -{ \
> -
>>> On 09.11.15 at 15:01, wrote:
> SPIs are too numerous and not indivcidually as interesting.
>
> Make the exists #IPIS counter x86 specific.
I'd recommend not to - even if ARM doesn't want to use it, it's still a
pretty generic thing.
Jan
___
Xen-
On Thu, 5 Nov 2015, Arnd Bergmann wrote:
> On Thursday 05 November 2015 17:09:45 Stefano Stabellini wrote:
> > If Linux is running as dom0, call XENPF_settime to update the system
> > time in Xen on pvclock_gtod notifications.
> >
> > Signed-off-by: Stefano Stabellini
> > Signed-off-by: Ian Campb
>>> On 09.11.15 at 15:00, wrote:
> Signed-off-by: Ian Campbell
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
From: Fu Wei
Signed-off-by: Fu Wei
---
grub-core/loader/arm64/fdt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/grub-core/loader/arm64/fdt.c b/grub-core/loader/arm64/fdt.c
index 5202c14..901bd7b 100644
--- a/grub-core/loader/arm64/fdt.c
+++ b/grub-core/loader/arm64/fdt.c
@@ -25,6 +25,
SPIs are too numerous and not indivcidually as interesting.
Make the exists #IPIS counter x86 specific.
Signed-off-by: Ian Campbell
Cc: jbeul...@suse.com
---
xen/arch/arm/gic.c | 2 +-
xen/arch/arm/irq.c | 4 ++--
xen/include/asm-arm/perfc_defn.h | 3 ++-
xen/include
Signed-off-by: Ian Campbell
---
xen/common/schedule.c| 1 +
xen/include/xen/perfc_defn.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index 292e9a0..86d6cc0 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -896,6 +896
On Fri, 6 Nov 2015, Arnd Bergmann wrote:
> > > > ---
> > > > +static void xen_read_wallclock(struct timespec *ts)
> > > > +{
> > > > + u32 version;
> > > > + u64 delta;
> > > > + struct timespec now;
> > > > + struct shared_info *s = HYPERVISOR_shared_info;
> > > > + struct pvclock_wall_c
>>> On 06.11.15 at 18:22, wrote:
> 1. First of all, I wish Xen was somehow more defensively coded. To provide
> some
> examples:
>
> a. In XSA-109 [5] there was a problem with the hypervisor dereferencing a
> NULL
> pointer. The problem was fixed by the Xen Security Team by applying a patch
> w
On Fri, 2015-11-06 at 12:51 -0600, ed sandberg wrote:
> > Does your kernel have the Xen drivers (CONFIG_XEN and all which is
> > gated on that) enabled. In particular CONFIG_HVC_XEN.
> >
> Yes the config file I used to compile has CONFIG_XEN=y and
> CONFIG_HVC_XEN=y. Config file is attached.
Tha
libxenctrl links against this library.
Also, request the compat xc_map_foreign API from libxc.
Signed-off-by: Ian Campbell
---
v3: Library moved to tools/libs/
---
xen-hooks.mak | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen-hooks.mak b/xen-hooks.mak
index 229d642..c1ea4be 100644
---
These are already arch specific, so just use the appropriate
interfaces (as determined by looking at the xc_memalign backend).
Signed-off-by: Ian Campbell
Acked-by: Wei Liu
---
tools/libs/call/netbsd.c | 4 ++--
tools/libs/call/solaris.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
libxenforeignmemory has just been split out from libxc. From mini-os's
point of view we don't care about the distinction, so keep things
simple by just including libxenforeignmemory if libxc is enabled.
Signed-off-by: Ian Campbell
Acked-by: Samuel Thibault
Acked-by: Wei Liu
---
v2: Adjust for l
flight 63819 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63819/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 3 host-install(3) broken REGR. vs.
6
/dev/xen/evtchn related wrappers have been moved out of libxenctrl
into their own library.
Note that i386-dm/helper2.c's xc_interface * was always really an
xc_evtchn *, it's just they used to be typedefs to the same thing...
Signed-off-by: Ian Campbell
---
v3: Library moved to tools/libs/
---
Until the previous patch this relied on xc_fd(), which was only
implemented for Xen 4.0 and earlier.
Given this wasn't working since Xen 4.0 I have marked this as disabled
by default.
Removing this support drops the use of a bunch of symbols from
libxenctrl, specifically:
- xc_domain_create
I've just sent out v5. Anyone got any thoughts on how to proceed with qemu-
xen?
On Wed, 2015-10-21 at 16:47 +0100, Ian Campbell wrote:
> (Trimming CCs a bit)
>
> On Wed, 2015-10-21 at 16:22 +0100, Ian Campbell wrote:
> >
> [...]
> > Still to come would be libraries for specific out of tree pur
In Xen 4.7 we are refactoring parts libxenctrl into a number of
separate libraries which will provide backward and forward API and ABI
compatiblity.
One such library will be libxengnttab which provides access to grant
tables.
In preparation for this switch the compatibility layer in xen_common.h
libxentoollog has just been split out from libxc. From mini-os's point
of view we don't care about the distinction, so keep things simple by
just including libxentoollog if libxc is enabled.
Signed-off-by: Ian Campbell
Acked-by: Samuel Thibault
Acked-by: Wei Liu
---
v2: Adjust for libs/$lib lay
Signed-off-by: Ian Campbell
Acked-by: Wei Liu
---
tools/libs/foreignmemory/include/xenforeignmemory.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/libs/foreignmemory/include/xenforeignmemory.h
b/tools/libs/foreignmemory/include/xenforeignmemory.h
index 99ec883
libxenevtchn has just been split out from libxc. From mini-os's point
of view we don't care about the distinction, so keep things simple by
just including libxenevtchn if libxc is enabled.
Signed-off-by: Ian Campbell
Acked-by: Samuel Thibault
Acked-by: Wei Liu
---
v2: Adjust for libs/$lib layou
We intend to stabilise some parts of the libxenctrl interface by
splitting out some functionality into separate stable libraries.
This is the mini-os part of the first phase of that change.
This mail is (or is intended to be) a reply to a "0/"
super-intro mail covering all of the related patch se
This has been split out of libxenctrl, so the build needs to be able
to find the header and the library. QEMU does not use xtl_* itself so
-rpath-link is sufficient to allow linking to libxenctrl.so (which
links against libxentoollog).
Signed-off-by: Ian Campbell
Acked-by: Ian Jackson
---
v3: L
Using an existing libxenctrl handle after a fork was never
particularly safe (especially if foreign mappings existed at the time
of the fork) and the xc fd has been unavailable for many releases.
Reopen the handle after fork and therefore do away with xc_fd().
Signed-off-by: Ian Campbell
Acked-b
This means adding -L for libxen{evtchn,gnttab,foreignmemory} so that
it can link them directly (rather than using the libxenctrl compat
layer exposed via -rpath-link). Also add -I for libxenforeignmemory.
Signed-off-by: Ian Campbell
Acked-by: Wei Liu
---
tools/Makefile | 4
1 file changed,
We intend to stabilise some parts of the libxenctrl interface by
splitting out some functionality into separate stable libraries.
This is the qemu-xen part of the first phase of that change.
This mail is (or is intended to be) a reply to a "0/"
super-intro mail covering all of the related patch s
1 - 100 of 159 matches
Mail list logo
