>>> On 11.10.16 at 17:53, wrote:
> On Tue, Oct 11, 2016 at 6:08 AM, Jan Beulich wrote:
> Andrew Cooper 10/10/16 6:44 PM >>>
>>>On 10/10/16 01:35, Haozhong Zhang wrote:
Xen hypervisor needs assistance from Dom0 Linux kernel for following tasks:
1) Reserve an area on NVDIMM devices f
>>> On 11.10.16 at 16:27, wrote:
> On 10/11/2016 09:32 AM, Ian Jackson wrote:
>> Boris Ostrovsky writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to
> newer commit"):
>>> On 10/11/2016 05:52 AM, Ian Jackson wrote:
Maybe we could consider these as backports to earlier releases.
Howe
>>> On 11.10.16 at 23:11, wrote:
> On 11/10/2016 14:32, Ian Jackson wrote:
>> Boris Ostrovsky writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to
>> newer commit"):
>>> BTW, another option for backporting may be removing -Werror. If we know
>>> we are not changing sources then we might consi
This patchset is to fix triggering NMI watchdog during dump timer info
on the huge machine with a mount of physical cpus. Detail please see
change log of Patch 1.
Previous discussion:
https://patchwork.kernel.org/patch/9328449/
Change since V1:
Add "async" param for handle_keypress() to i
Keyhandler may run for a long time in serial port driver's
timer handler on the large machine with a lot of physical
cpus(e,g dump_timerq()) when serial port driver works in
the poll mode(via the exception mechanism).
If a timer handler runs a long time, it will block nmi_timer_fn()
to feed NMI w
Dumping timer info may run for a long time on the huge machine with
a lot of physical cpus. To avoid triggering NMI watchdog, add
process_pending_softirqs() in the loop of dumping timer info.
Reviewed-by: Konrad Rzeszutek Wilk
Signed-off-by: Lan Tianyu
---
xen/common/timer.c |1 +
1 files c
>>> On 12.10.16 at 17:44, wrote:
> This patchset is to fix triggering NMI watchdog during dump timer info
> on the huge machine with a mount of physical cpus. Detail please see
> change log of Patch 1.
>
> Previous discussion:
> https://patchwork.kernel.org/patch/9328449/
>
> Change since V1:
>
flight 101384 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101384/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 46cd2cb6a7ba5b1fdaff1eb18a13dc399d6a7fe2
baseline version:
ovmf 4b8234d05400a852a4268
On 2016年10月12日 16:09, Jan Beulich wrote:
On 12.10.16 at 17:44, wrote:
>> This patchset is to fix triggering NMI watchdog during dump timer info
>> on the huge machine with a mount of physical cpus. Detail please see
>> change log of Patch 1.
>>
>> Previous discussion:
>> https://patchwork.ker
>>> On 10.10.16 at 18:00, wrote:
> --- a/xen/common/libelf/libelf-loader.c
> +++ b/xen/common/libelf/libelf-loader.c
> @@ -174,8 +174,8 @@ void elf_parse_bsdsyms(struct elf_binary *elf, uint64_t
> pstart)
> /* Space to store the size of the elf image */
> sz = sizeof(uint32_t);
>
> -
flight 67865 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67865/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-i386-squeeze-netboot-pygrub 9 debian-di-install fail like
67795
test-amd64-i
flight 101386 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101386/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-xsm 14 guest-sav
On Tue, Oct 11, 2016 at 08:31:31PM +0100, Juergen Schinker wrote:
>
>
> >
> > We're going to tag rc2 some time this week. Thanks for help testing Xen!
> >
> > Wei.
> >
> >> J
> >>
> >> - On 11 Oct, 2016, at 09:37, Wei Liu wei.l...@citrix.com wrote:
> >>
> >> > No, you can try to work ar
On 12/10/16 05:07, Kyle Huey wrote:
> rr (http://rr-project.org/), a Linux userspace record-and-replay reverse-
> execution debugger, would like to trap and emulate the CPUID instruction.
> This would allow us to a) mask away certain hardware features that rr does
> not support (e.g. RDRAND) and b)
On Wed, Oct 12, 2016 at 04:20:02PM +0800, Lan Tianyu wrote:
> On 2016年10月12日 16:09, Jan Beulich wrote:
> On 12.10.16 at 17:44, wrote:
> >> This patchset is to fix triggering NMI watchdog during dump timer info
> >> on the huge machine with a mount of physical cpus. Detail please see
> >> chan
On 10/11/16 13:17 -0700, Dan Williams wrote:
On Tue, Oct 11, 2016 at 12:48 PM, Konrad Rzeszutek Wilk
wrote:
On Tue, Oct 11, 2016 at 12:28:56PM -0700, Dan Williams wrote:
On Tue, Oct 11, 2016 at 11:33 AM, Konrad Rzeszutek Wilk
wrote:
> On Tue, Oct 11, 2016 at 10:51:19AM -0700, Dan Williams wro
Ian Jackson writes ("Re: Proposed plan and URL name for new VM to download xen
tarballs (ftp.xenproject.org)"):
> Sure, I don't have an opinion. I have changed this, so it's now
> under:
> https://downloads.xenproject.org/release/xen/
No-one has objected, so we are now committing to this. The
flight 101393 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101393/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
coverity-amd646 coverity-upload fail REGR. vs. 101279
version t
> On 12 Oct 2016, at 11:38, Ian Jackson wrote:
>
> Ian Jackson writes ("Re: Proposed plan and URL name for new VM to download
> xen tarballs (ftp.xenproject.org)"):
>> Sure, I don't have an opinion. I have changed this, so it's now
>> under:
>> https://downloads.xenproject.org/release/xen/
>
Hi all
Xen 4.8 RC2 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.8.0-rc2
For you convenience, please find tarball and signature at:
https://downloads.xenproject.org/release/xen/4.8.0-rc2/
Please send bug reports and test reports to
xen-de...@lists.xenproject
On 09/10/2016 21:50, Emil Condrea wrote:
> On Tue, Oct 4, 2016 at 11:06 AM, Paolo Bonzini wrote:
>>
>>
>> On 04/10/2016 08:43, Emil Condrea wrote:
>>> xen_be_frontend_changed -> xen_fe_frontend_changed
>>
>> This is not correct. The front-end is implemented in the guest domain,
>> while the bac
Ian Jackson writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer
commit"):
> That was eventually done. I'm not sure exactly when the change was
> made. Does gcc -Wno-foo work properly on all the gcc's we care about ?
Jan Beulich writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to
flight 101383 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101383/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101372
test-amd64-i386-xl-qemut-wi
On Thu, Oct 06, 2016 at 09:20:07AM -0600, Jan Beulich wrote:
> >>> On 27.09.16 at 17:57, wrote:
> > The logic used to setup the CPUID leaves is extremely simplistic (and
> > probably wrong for hardware different than mine). I'm not sure what's the
> > best way to deal with this, the code that curr
On 12/10/16 21:38, Ian Jackson wrote:
> Ian Jackson writes ("Re: Proposed plan and URL name for new VM to download
> xen tarballs (ftp.xenproject.org)"):
>> Sure, I don't have an opinion. I have changed this, so it's now
>> under:
>> https://downloads.xenproject.org/release/xen/
>
> No-one has
Wei Liu writes ("Re: [PATCH v2 0/2] Xen: Fix Xen hypervisor panic during
dumping timer info on huge machine."):
> On Wed, Oct 12, 2016 at 04:20:02PM +0800, Lan Tianyu wrote:
> > On 2016年10月12日 16:09, Jan Beulich wrote:
> > > Also, any reason you send to the list twice (once @lists.xen.org,
> > > a
When running as Xen dom0 a special processor_aggregator driver is
needed. Don't register the standard driver in this case.
Without that check an error message:
"Error: Driver 'processor_aggregator' is already registered,
aborting..."
will be displayed.
Signed-off-by: Juergen Gross
---
drivers
On 12/10/16 12:06, Roger Pau Monne wrote:
> On Thu, Oct 06, 2016 at 09:20:07AM -0600, Jan Beulich wrote:
> On 27.09.16 at 17:57, wrote:
>>> The logic used to setup the CPUID leaves is extremely simplistic (and
>>> probably wrong for hardware different than mine). I'm not sure what's the
>>> be
>>> On 12.10.16 at 12:33, wrote:
> The layout is shown as the following diagram.
>
> +---+---+---+--+--+
> | whatever used | Partition | Super | Reserved | /dev/pmem0p1 |
> | by kernel| Table | Block | for Xen | |
> +-
>>> On 11.10.16 at 15:39, wrote:
> Hello Jan,
>
> On 06/10/16 13:21, Jan Beulich wrote:
> On 05.10.16 at 20:30, wrote:
>>> On 30/09/2016 02:46, Jan Beulich wrote:
>>> On 29.09.16 at 23:42, wrote:
> +#else
> +static void __init free_ebmalloc_unused_mem(void)
> +{
> +}
>>>
flight 101389 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101389/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-multivcpu 14 guest-saverestore fail REGR. vs. 101000
test-amd64-i386-pair
Hey Ronald,
My ultimate vision for the libxl golang project is to have the following:
- Golang bindings for all core libxl functionality
- A test program which exersises as much of that functionality as is
reasonable
The C libxl library has two components: parts that are written by hand
(such as
>>> On 11.10.16 at 16:01, wrote:
> On Tue, Oct 04, 2016 at 05:16:09AM -0600, Jan Beulich wrote:
>> >>> On 04.10.16 at 11:12, wrote:
>> > On Fri, Sep 30, 2016 at 09:52:56AM -0600, Jan Beulich wrote:
>> >> >>> On 27.09.16 at 17:57, wrote:
>> >> > @@ -336,7 +343,8 @@ static unsigned long __init com
>>> On 11.10.16 at 16:06, wrote:
> On Fri, Sep 30, 2016 at 09:52:56AM -0600, Jan Beulich wrote:
>> >>> On 27.09.16 at 17:57, wrote:
>> > + * VM86 TSS. Note that after this not all e820 regions will be aligned
>> > + * to PAGE_SIZE.
>> > + */
>> > +for ( i = 1; i <= d->arch.nr_e820
>>> On 12.10.16 at 13:06, wrote:
> On Thu, Oct 06, 2016 at 09:20:07AM -0600, Jan Beulich wrote:
>> >>> On 27.09.16 at 17:57, wrote:
>> > The logic used to setup the CPUID leaves is extremely simplistic (and
>> > probably wrong for hardware different than mine). I'm not sure what's the
>> > best w
>>> On 11.10.16 at 12:31, wrote:
> --- /dev/null
> +++ b/xen/common/gcov/gcc_4_7.c
> @@ -0,0 +1,205 @@
> +/*
> + * This code provides functions to handle gcc's profiling data format
> + * introduced with gcc 4.7.
> + *
> + * This file is based heavily on gcc_3_4.c file.
> + *
> + * For a bette
Hello Jan,
On 12/10/2016 12:45, Jan Beulich wrote:
On 11.10.16 at 15:39, wrote:
On 06/10/16 13:21, Jan Beulich wrote:
On 05.10.16 at 20:30, wrote:
On 30/09/2016 02:46, Jan Beulich wrote:
On 29.09.16 at 23:42, wrote:
+#else
+static void __init free_ebmalloc_unused_mem(void)
+{
+}
+#endif
>>> On 12.10.16 at 14:51, wrote:
> Hello Jan,
>
> On 12/10/2016 12:45, Jan Beulich wrote:
> On 11.10.16 at 15:39, wrote:
>>> On 06/10/16 13:21, Jan Beulich wrote:
>>> On 05.10.16 at 20:30, wrote:
> On 30/09/2016 02:46, Jan Beulich wrote:
> On 29.09.16 at 23:42, wrote:
>
On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
> >>> On 11.10.16 at 12:31, wrote:
> > --- /dev/null
> > +++ b/xen/common/gcov/gcc_4_7.c
> > @@ -0,0 +1,205 @@
> > +/*
> > + * This code provides functions to handle gcc's profiling data format
> > + * introduced with gcc 4.7.
> > + *
>>> On 12.10.16 at 06:07, wrote:
> ---
In addition to what Andrew said: Please version your patch, and please
add a short summary of what changed compared to the previous version
here.
> @@ -2931,6 +2941,11 @@ static int vmx_msr_write_intercept(unsigned int msr,
> uint64_t msr_content)
>
>>> On 12.10.16 at 15:06, wrote:
> But I have no idea how useful it would be to use gcov and livepatching
> together. For now the easiest thing to do is to
>
>depends on !LIVEPATCH
>
> in Kconfig.
I agree.
Jan
___
Xen-devel mailing list
Xen-de
I use systemd and openvswitch
release: 4.7.0-1-amd64
version: #1 SMP Debian 4.7.5-1 (2016-09-26)
machine: x86_64
nr_cpus: 4
max_cpu_id : 3
nr_nodes : 1
cores_per_socket : 2
threads_per_core : 2
c
On Wed, Oct 12, 2016 at 02:13:57PM +0100, Juergen Schinker wrote:
> I use systemd and openvswitch
>
>
> release: 4.7.0-1-amd64
But this shows 4.7.0-1. Maybe you didn't install Xen properly? Please
make sure all residuals from previous releases are gone.
Also please start a new t
>>> On 12.10.16 at 09:58, wrote:
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -347,7 +347,7 @@ static void switch_serial_input(void)
> static void __serial_rx(char c, struct cpu_user_regs *regs)
> {
> if ( xen_rx )
> -return handle_keypress(c, regs);
>
> And then - how is all of this supposed to be working in conjucntion
> with live patching, where the patch may have been created by yet
> another compiler version?
Uh, I hope one does not create a livepatch patch with another compiler version!
Let me put on the TODO to make livepatch-build-tools
On Fri, Oct 07, 2016 at 07:22:33PM +0100, Wei Liu wrote:
> On Fri, Oct 07, 2016 at 10:34:15AM -0700, Stefano Stabellini wrote:
> > On Fri, 7 Oct 2016, Alistair Francis wrote:
> > > On Thu, Oct 6, 2016 at 9:36 AM, Edgar E. Iglesias
> > > wrote:
> > > > From: "Edgar E. Iglesias"
> > > >
> > > > Dis
>>> On 11.10.16 at 02:57, wrote:
> +/*
> + * In fact, we can remove this hooks inside itself if no new device is in the
> + * process of getting assigned and "from" hook is NULL. However, it is not
> + * straightforward to find a clear solution, so just leave it here.
> + */
> static void vmx_pi_
On 12/10/16 14:06, Wei Liu wrote:
> On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
> On 11.10.16 at 12:31, wrote:
>>> --- /dev/null
>>> +++ b/xen/common/gcov/gcc_4_7.c
>>> @@ -0,0 +1,205 @@
>>> +/*
>>> + * This code provides functions to handle gcc's profiling data format
>>> +
On 12/10/16 14:24, George Dunlap wrote:
> On 12/10/16 14:06, Wei Liu wrote:
>> On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
>> On 11.10.16 at 12:31, wrote:
--- /dev/null
+++ b/xen/common/gcov/gcc_4_7.c
@@ -0,0 +1,205 @@
+/*
+ * This code provides funct
On Wed, Oct 12, 2016 at 02:24:51PM +0100, George Dunlap wrote:
> On 12/10/16 14:06, Wei Liu wrote:
> > On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
> > On 11.10.16 at 12:31, wrote:
> >>> --- /dev/null
> >>> +++ b/xen/common/gcov/gcc_4_7.c
> >>> @@ -0,0 +1,205 @@
> >>> +/*
> >>>
that is the live kernel
Linux xen 4.7.0-1-amd64 #1 SMP Debian 4.7.5-1 (2016-09-26) x86_64 GNU/Linux
I have to boot a stable xen version to use my machine again which is 4.6
I only use one machine - that's why i use Virtualization
I start every major app with its own ded VM and have Xorg o
On Tue, Oct 04, 2016 at 09:43:33AM +0300, Emil Condrea wrote:
> Its purpose is to store frontend related functions.
>
> Signed-off-by: Quan Xu
> Signed-off-by: Emil Condrea
Looks good, once the comments on the previous patches are addressed,
same comments for patch 5, 6 and 7.
--
Anthony PERA
On Tue, Oct 04, 2016 at 09:43:37AM +0300, Emil Condrea wrote:
> The name of the functions moved to xen_pvdev.c:
> * xenstore_cleanup_dir
> * xen_config_cleanup
> * xenstore_mkdir
>
> Signed-off-by: Emil Condrea
Acked-by: Anthony PERARD
--
Anthony PERARD
___
On Tue, Oct 04, 2016 at 09:43:38AM +0300, Emil Condrea wrote:
> Prepare xen_be_printf to be used by both backend and frontends:
> * xen_be_printf -> xen_pv_printf
>
> Signed-off-by: Emil Condrea
Acked-by: Anthony PERARD
--
Anthony PERARD
___
Xen-d
On Wed, Oct 12, 2016 at 02:26:26PM +0100, George Dunlap wrote:
[...]
> >>
> >> There is a version field in gcov_info, so we can compare that and reject
> >> incompatible version.
> >>
> >> We need to use hooks in livepatching to call the constructor /
> >> destructor when applying / reverting a liv
>>> On 12.10.16 at 15:23, wrote:
>> And then - how is all of this supposed to be working in conjucntion
>> with live patching, where the patch may have been created by yet
>> another compiler version?
>
> Uh, I hope one does not create a livepatch patch with another compiler
> version!
>
> Let
>>> On 12.10.16 at 15:26, wrote:
> On 12/10/16 14:24, George Dunlap wrote:
>> I would expect most users to want to build a single hypervisor that can
>> be used for both gcov testing and live patching (under different
>> circumstances).
>
> I mean software provider, not user, of course. That's w
On 12/10/16 14:26, George Dunlap wrote:
> On 12/10/16 14:24, George Dunlap wrote:
>> On 12/10/16 14:06, Wei Liu wrote:
>>> On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
>>> On 11.10.16 at 12:31, wrote:
> --- /dev/null
> +++ b/xen/common/gcov/gcc_4_7.c
> @@ -0,0 +1,20
On Tue, Oct 04, 2016 at 09:43:39AM +0300, Emil Condrea wrote:
> Prepare xen_be_unbind_evtchn to be shared with frontends:
> * xen_be_unbind_evtchn -> xen_pv_unbind_evtchn
>
> Signed-off-by: Emil Condrea
Acked-by: Anthony PERARD
--
Anthony PERARD
_
On Wed, Oct 12, 2016 at 09:29:04AM -0400, Konrad Rzeszutek Wilk wrote:
[...]
> >
> > Wouldn't it be just as easy, and more useful, to set a "has been
> > livepatched" flag, and return errors for all gcov hypercalls if its' set?
> >
> > I would expect most users to want to build a single hyperviso
On Tue, Oct 04, 2016 at 09:43:40AM +0300, Emil Condrea wrote:
> Prepare xen_be_send_notify to be shared with frontends:
> * xen_be_send_notify -> xen_pv_send_notify
>
> Signed-off-by: Emil Condrea
Acked-by: Anthony PERARD
--
Anthony PERARD
___
Xen
On Tue, Oct 04, 2016 at 09:43:42AM +0300, Emil Condrea wrote:
> Prepare xen_be_find_xendev to be shared with frontends:
> * xen_be_find_xendev -> xen_pv_find_xendev
>
> Signed-off-by: Emil Condrea
Acked-by: Anthony PERARD
--
Anthony PERARD
___
Xen
On 12/10/16 14:41, George Dunlap wrote:
> On 12/10/16 14:34, Andrew Cooper wrote:
>> On 12/10/16 14:26, George Dunlap wrote:
>>> On 12/10/16 14:24, George Dunlap wrote:
On 12/10/16 14:06, Wei Liu wrote:
> On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
> On 11.10.16 at
On Wed, Oct 12, 2016 at 07:31:52AM -0600, Jan Beulich wrote:
> >>> On 12.10.16 at 15:23, wrote:
> >> And then - how is all of this supposed to be working in conjucntion
> >> with live patching, where the patch may have been created by yet
> >> another compiler version?
> >
> > Uh, I hope one doe
>>> On 11.10.16 at 02:57, wrote:
> static void pi_desc_init(struct vcpu *v)
> {
> -uint32_t dest;
> -
> v->arch.hvm_vmx.pi_desc.nv = posted_intr_vector;
>
> -dest = cpu_physical_id(v->processor);
> -
> -if ( x2apic_enabled )
> -v->arch.hvm_vmx.pi_desc.ndst = dest;
> -
On Tue, Oct 04, 2016 at 09:43:43AM +0300, Emil Condrea wrote:
> Prepare xen_be_del_xendev to be shared with frontends:
> * xen_be_del_xendev -> xen_pv_del_xendev
>
> Signed-off-by: Emil Condrea
Acked-by: Anthony PERARD
--
Anthony PERARD
___
Xen-de
On Wed, Oct 12, 2016 at 02:29:51PM +0100, Juergen Schinker wrote:
>
> that is the live kernel
> Linux xen 4.7.0-1-amd64 #1 SMP Debian 4.7.5-1 (2016-09-26) x86_64 GNU/Linux
>
Oh, right. Sorry I missed that.
>
> I have to boot a stable xen version to use my machine again which is 4.6
>
Then t
On Wed, Oct 12, 2016 at 03:23:43PM +0200, Edgar E. Iglesias wrote:
> On Fri, Oct 07, 2016 at 07:22:33PM +0100, Wei Liu wrote:
> > On Fri, Oct 07, 2016 at 10:34:15AM -0700, Stefano Stabellini wrote:
> > > On Fri, 7 Oct 2016, Alistair Francis wrote:
> > > > On Thu, Oct 6, 2016 at 9:36 AM, Edgar E. Ig
On Wed, Oct 12, 2016 at 02:40:08PM +0100, Wei Liu wrote:
> On Wed, Oct 12, 2016 at 09:29:04AM -0400, Konrad Rzeszutek Wilk wrote:
> [...]
> > >
> > > Wouldn't it be just as easy, and more useful, to set a "has been
> > > livepatched" flag, and return errors for all gcov hypercalls if its' set?
> >
On Wed, Oct 12, 2016 at 09:46:51AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Oct 12, 2016 at 02:40:08PM +0100, Wei Liu wrote:
> > On Wed, Oct 12, 2016 at 09:29:04AM -0400, Konrad Rzeszutek Wilk wrote:
> > [...]
> > > >
> > > > Wouldn't it be just as easy, and more useful, to set a "has been
>
On Tue, Oct 04, 2016 at 09:43:41AM +0300, Emil Condrea wrote:
> Prepare xen_be_evtchn_event to be shared with frontends:
> * xen_be_evtchn_event -> xen_pv_evtchn_event
>
> Signed-off-by: Emil Condrea
Acked-by: Anthony PERARD
--
Anthony PERARD
___
On 12/10/16 14:34, Andrew Cooper wrote:
> On 12/10/16 14:26, George Dunlap wrote:
>> On 12/10/16 14:24, George Dunlap wrote:
>>> On 12/10/16 14:06, Wei Liu wrote:
On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
On 11.10.16 at 12:31, wrote:
>> --- /dev/null
>> +++
>>> On 11.10.16 at 02:57, wrote:
> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -547,6 +547,49 @@ static int remap_entry_to_msi_msg(
> return 0;
> }
>
> +static bool_t pi_can_suppress_irte_update(struct iremap_entry *new,
bool (and true/
>>> On 11.10.16 at 02:57, wrote:
> @@ -638,7 +638,8 @@ static int msi_msg_to_remap_entry(
> GET_IREMAP_ENTRY(ir_ctrl->iremap_maddr, index,
> iremap_entries, iremap_entry);
>
> -memcpy(&new_ire, iremap_entry, sizeof(struct iremap_entry));
> +if ( iremap_entry->r
On Wed, Oct 12, 2016 at 02:47:18PM +0100, Wei Liu wrote:
> On Wed, Oct 12, 2016 at 03:23:43PM +0200, Edgar E. Iglesias wrote:
> > On Fri, Oct 07, 2016 at 07:22:33PM +0100, Wei Liu wrote:
> > > On Fri, Oct 07, 2016 at 10:34:15AM -0700, Stefano Stabellini wrote:
> > > > On Fri, 7 Oct 2016, Alistair F
On 10/12/2016 07:00 AM, Ian Jackson wrote:
> Ian Jackson writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer
> commit"):
>> That was eventually done. I'm not sure exactly when the change was
>> made. Does gcc -Wno-foo work properly on all the gcc's we care about ?
> Jan Beulich writes
>>> On 12.10.16 at 15:44, wrote:
> On Wed, Oct 12, 2016 at 07:31:52AM -0600, Jan Beulich wrote:
>> >>> On 12.10.16 at 15:23, wrote:
>> >> And then - how is all of this supposed to be working in conjucntion
>> >> with live patching, where the patch may have been created by yet
>> >> another compi
On Wed, Oct 12, 2016 at 12:00:56PM +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer
> commit"):
> > That was eventually done. I'm not sure exactly when the change was
> > made. Does gcc -Wno-foo work properly on all the gcc's we care about ?
Wei Liu writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit
[and 1 more messages]"):
> FAOD, I consider this sub-thread for "what should we do for stable
> versions of Xen". This is orthogonal to whether we should upgrade our
> in-tree ipxe version. In other words, I plan to comm
On 12.10.2016 15:44, Konrad Rzeszutek Wilk wrote:
On Wed, Oct 12, 2016 at 07:31:52AM -0600, Jan Beulich wrote:
On 12.10.16 at 15:23, wrote:
And then - how is all of this supposed to be working in conjucntion
with live patching, where the patch may have been created by yet
another compiler ver
On 10/12/2016 9:19 PM, Jan Beulich wrote:
On 12.10.16 at 09:58, wrote:
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -347,7 +347,7 @@ static void switch_serial_input(void)
static void __serial_rx(char c, struct cpu_user_regs *regs)
{
if ( xen_rx )
-return
On 10/12/2016 7:08 PM, Ian Jackson wrote:
Wei Liu writes ("Re: [PATCH v2 0/2] Xen: Fix Xen hypervisor panic during dumping
timer info on huge machine."):
On Wed, Oct 12, 2016 at 04:20:02PM +0800, Lan Tianyu wrote:
On 2016年10月12日 16:09, Jan Beulich wrote:
Also, any reason you send to the lis
flight 101390 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101390/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-xsm 3 host-install(3)broken REGR. vs. 101004
flight 101392 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101392/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 50d4be4f4e3d5beb2c1aa58853b92e3cc1f4cb9a
baseline version:
ovmf 46cd2cb6a7ba5b1fdaff1
Wiht the latest rework of the xen-netback driver, we get a warning
on ARM about the types passed into min():
drivers/net/xen-netback/rx.c: In function 'xenvif_rx_next_chunk':
include/linux/kernel.h:739:16: error: comparison of distinct pointer types
lacks a cast [-Werror]
The reason is that XEN_
On 10/12/16 05:32 -0600, Jan Beulich wrote:
On 12.10.16 at 12:33, wrote:
The layout is shown as the following diagram.
+---+---+---+--+--+
| whatever used | Partition | Super | Reserved | /dev/pmem0p1 |
| by kernel| Table | Block | for Xen
Three newly introduced functions are not defined when CONFIG_XEN_PVHVM is
disabled, but are still being used:
arch/x86/xen/enlighten.c:141:12: warning: ‘xen_cpu_up_prepare’ used but never
defined
arch/x86/xen/enlighten.c:142:12: warning: ‘xen_cpu_up_online’ used but never
defined
arch/x86/xen/en
On 10/12/2016 11:20 AM, Arnd Bergmann wrote:
> Three newly introduced functions are not defined when CONFIG_XEN_PVHVM is
> disabled, but are still being used:
>
> arch/x86/xen/enlighten.c:141:12: warning: ‘xen_cpu_up_prepare’ used but never
> defined
> arch/x86/xen/enlighten.c:142:12: warning: ‘xe
On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
> >>> On 11.10.16 at 12:31, wrote:
> > --- /dev/null
> > +++ b/xen/common/gcov/gcc_4_7.c
> > @@ -0,0 +1,205 @@
> > +/*
> > + * This code provides functions to handle gcc's profiling data format
> > + * introduced with gcc 4.7.
> > + *
This run is configured for baseline tests only.
flight 67867 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67867/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 46cd2cb6a7ba5b1fdaff1eb18a13dc399d6a7fe2
baseline v
>>> On 12.10.16 at 16:58, wrote:
> On 10/12/16 05:32 -0600, Jan Beulich wrote:
> On 12.10.16 at 12:33, wrote:
>>> The layout is shown as the following diagram.
>>>
>>> +---+---+---+--+--+
>>> | whatever used | Partition | Super | Reserved | /dev/pme
On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich wrote:
On 12.10.16 at 16:58, wrote:
>> On 10/12/16 05:32 -0600, Jan Beulich wrote:
>> On 12.10.16 at 12:33, wrote:
The layout is shown as the following diagram.
+---+---+---+--+--+
>>
>>> On 12.10.16 at 17:33, wrote:
> On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
>> >>> On 11.10.16 at 12:31, wrote:
>> > --- /dev/null
>> > +++ b/xen/common/gcov/gcc_4_7.c
>> > @@ -0,0 +1,205 @@
>> > +/*
>> > + * This code provides functions to handle gcc's profiling data format
On Thu, Oct 06, 2016 at 09:40:50AM -0600, Jan Beulich wrote:
> >>> On 27.09.16 at 17:57, wrote:
> > FWIW, I think that the current approach that I've used in order to craft the
> > MADT is not the best one, IMHO it would be better to place the MADT at the
> > end of the E820_ACPI region (expanding
>>> On 12.10.16 at 17:42, wrote:
> On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich wrote:
> On 12.10.16 at 16:58, wrote:
>>> On 10/12/16 05:32 -0600, Jan Beulich wrote:
>>> On 12.10.16 at 12:33, wrote:
> The layout is shown as the following diagram.
>
> +---+---
>>> On 12.10.16 at 16:30, wrote:
>
> On 10/12/2016 9:19 PM, Jan Beulich wrote:
> On 12.10.16 at 09:58, wrote:
>>> --- a/xen/drivers/char/console.c
>>> +++ b/xen/drivers/char/console.c
>>> @@ -347,7 +347,7 @@ static void switch_serial_input(void)
>>> static void __serial_rx(char c, struct c
>>> On 12.10.16 at 17:35, wrote:
> On Thu, Oct 06, 2016 at 09:40:50AM -0600, Jan Beulich wrote:
>> >>> On 27.09.16 at 17:57, wrote:
>> > +static void __init acpi_zap_table_signature(char *name)
>> > +{
>> > +struct acpi_table_header *table;
>> > +acpi_status status;
>> > +union {
>> >
> > > ### Data ring
> > >
> > > Data rings are used for sending and receiving data over a connected
> > > socket. They
> > > are created upon a successful **accept** or **connect** command.
> > >
> > > A data ring is composed of two pieces: the interface and the **in** and
> > > **out**
> > > b
On Wed, Oct 12, 2016 at 9:01 AM, Jan Beulich wrote:
On 12.10.16 at 17:42, wrote:
>> On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich wrote:
>> On 12.10.16 at 16:58, wrote:
On 10/12/16 05:32 -0600, Jan Beulich wrote:
On 12.10.16 at 12:33, wrote:
>> The layout is shown as
On Wed, Oct 12, 2016 at 04:17:57PM +0200, Martin Pohlack wrote:
> On 12.10.2016 15:44, Konrad Rzeszutek Wilk wrote:
> > On Wed, Oct 12, 2016 at 07:31:52AM -0600, Jan Beulich wrote:
> > > > > > On 12.10.16 at 15:23, wrote:
> > > > > And then - how is all of this supposed to be working in conjucnti
1 - 100 of 147 matches
Mail list logo
