On June 01, 2016 6:24 PM, Jan Beulich wrote:
> >>> On 31.05.16 at 15:57, wrote:
> > --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> > +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> > @@ -295,12 +297,22 @@ static void __hwdom_init
> amd_iommu_hwdom_init(struct domain *d)
> >
On May 27, 2016 10:06 PM, Jan Beulich wrote:
> >>> On 27.05.16 at 15:34, wrote:
> > On Fri, May 27, 2016 at 06:16:30AM -0600, Jan Beulich wrote:
> >> >>> On 27.05.16 at 12:39, wrote:
> >> > Is this a regression? Does it work on previous versions of Xen?
> >>
> >> I think this is what was already
On 6/1/2016 6:09 PM, Tamas K Lengyel wrote:
On Wed, Jun 1, 2016 at 3:49 PM, Julien Grall wrote:
On 01/06/2016 18:10, Tamas K Lengyel wrote:
Hi all,
Hi Tamas,
following the steps from http://wiki.xen.org/wiki/HiKey I'm unable to
get the board to boot Xen. I'm using the Debian reference
>>> On 01.06.16 at 21:34, wrote:
> On 06/01/16 21:21, Tamas K Lengyel wrote:
>> On Wed, Jun 1, 2016 at 5:24 AM, Julien Grall wrote:
>>> On 01/06/16 09:41, Jan Beulich wrote:
Once an ABI is set in stone, and if that ABI allows for optimizations
(by consumers) like the one mentioned, I do
>>> On 02.06.16 at 02:14, wrote:
> Specifically:
>
> s/\.xsplice/\.xlivepatch/
> s/XSPLICE_OP/LIVEPATCH_OP/
> s/XSPLICE/LIVE_PATCH/
I agree with Andrew that for consistency there should never be an
underscore between "live" and "patch", no matter what case both
parts are in. Apart from consisten
> -Original Message-
> From: suravee.suthikulpa...@amd.com
> [mailto:suravee.suthikulpa...@amd.com]
> Sent: 01 June 2016 20:53
> To: xen-devel@lists.xen.org; Paul Durrant; jbeul...@suse.com; George
> Dunlap
> Cc: Keir (Xen.org); Suravee Suthikulpanit; Suravee Suthikulpanit
> Subject: [PATCH
>>> On 01.06.16 at 21:28, wrote:
> On Wed, Jun 01, 2016 at 09:41:42AM -0600, Jan Beulich wrote:
>> >>> On 01.06.16 at 17:23, wrote:
>> > On Fri, May 27, 2016 at 02:22:39AM -0600, Jan Beulich wrote:
>> >> >>> On 25.05.16 at 19:15, wrote:
>> >> > On Wed, May 25, 2016 at 01:20:23AM -0600, Jan Beuli
>>> On 01.06.16 at 21:53, wrote:
> On Wed, Jun 01, 2016 at 10:02:51AM -0600, Jan Beulich wrote:
>> >>> On 01.06.16 at 17:58, wrote:
>> > On Fri, May 27, 2016 at 02:37:06AM -0600, Jan Beulich wrote:
>> >> >>> On 25.05.16 at 21:48, wrote:
>> >> > On Wed, May 25, 2016 at 02:39:57AM -0600, Jan Beuli
On Fri, May 27, 2016 at 03:33:49AM -0600, Jan Beulich wrote:
> >>> On 25.05.16 at 23:36, wrote:
> > On Wed, May 25, 2016 at 04:33:54AM -0600, Jan Beulich wrote:
> >> >>> On 15.04.16 at 14:33, wrote:
[...]
> >> > +/*
> >> > + * Compiler is not able to optimize regular strlen()
> >> > + * if argu
On 06/02/2016 10:35 AM, Jan Beulich wrote:
> The criteria for inclusion or exclusion should
> follow a predictable model. I.e. if someone comes along and says
> "I need register Y", then there should be rules that (s)he can apply
> up front to determine what (at least in the vast majority of cases)
>>> On 01.06.16 at 21:03, wrote:
> On Fri, May 27, 2016 at 03:02:25AM -0600, Jan Beulich wrote:
>> >>> On 25.05.16 at 23:02, wrote:
>> > On Wed, May 25, 2016 at 03:32:37AM -0600, Jan Beulich wrote:
>> >> isn't going to be very helpful in the field, I'm afraid. Even more so
>> >> that there's no g
>>> On 02.06.16 at 10:15, wrote:
> On Fri, May 27, 2016 at 03:33:49AM -0600, Jan Beulich wrote:
>> >>> On 25.05.16 at 23:36, wrote:
>> > On Wed, May 25, 2016 at 04:33:54AM -0600, Jan Beulich wrote:
>> >> >>> On 15.04.16 at 14:33, wrote:
>> >> > +/*
>> >> > + * Compiler is not able to optimize re
>>> On 01.06.16 at 21:16, wrote:
> On Wed, Jun 01, 2016 at 08:44:31AM -0600, Jan Beulich wrote:
>> >>> On 01.06.16 at 15:35, wrote:
>> > On Wed, May 25, 2016 at 05:03:20AM -0600, Jan Beulich wrote:
>> >> >>> On 15.04.16 at 14:33, wrote:
>> >> > @@ -178,30 +185,39 @@ efi_multiboot2_proto:
>> >> >
>>> On 02.06.16 at 00:31, wrote:
> On 01/06/2016 23:24, Julien Grall wrote:
>> free_xenheap_pages already tolerates NULL (even if an order != 0). Is
>> there any reason to not do the same for free_domheap_pages?
>
> The xenheap allocation functions deal in terms of plain virtual
> addresses, whil
>>> On 02.06.16 at 03:32, wrote:
> The test in this case creates a domain, waits a minute, then
> deletes/creates the next domain, waits a minute, and so on. So I
> wouldn't be surprised to see the VMID occasionally indicate there are 2
> active domains since there could be one being created a
On 02/06/16 09:47, Jan Beulich wrote:
On 02.06.16 at 00:31, wrote:
>> On 01/06/2016 23:24, Julien Grall wrote:
>>> free_xenheap_pages already tolerates NULL (even if an order != 0). Is
>>> there any reason to not do the same for free_domheap_pages?
>> The xenheap allocation functions deal in
>>> On 02.06.16 at 09:31, wrote:
> On May 27, 2016 10:06 PM, Jan Beulich wrote:
>> >>> On 27.05.16 at 15:34, wrote:
>> > On Fri, May 27, 2016 at 06:16:30AM -0600, Jan Beulich wrote:
>> >> >>> On 27.05.16 at 12:39, wrote:
>> >> > Is this a regression? Does it work on previous versions of Xen?
>>
Hello Aaron,
On 02/06/2016 02:32, Aaron Cornelius wrote:
This is with a custom application, we use the libxl APIs to interact
with Xen. Domains are created using the libxl_domain_create_new()
function, and domains are destroyed using the libxl_domain_destroy()
function.
The test in this case c
>>> On 02.06.16 at 10:53, wrote:
> On 02/06/16 09:47, Jan Beulich wrote:
> On 02.06.16 at 00:31, wrote:
>>> On 01/06/2016 23:24, Julien Grall wrote:
free_xenheap_pages already tolerates NULL (even if an order != 0). Is
there any reason to not do the same for free_domheap_pages?
>>>
>>> On 02.06.16 at 08:00, wrote:
> On June 01, 2016 6:05 PM, Jan Beulich wrote:
>> >>> On 31.05.16 at 15:57, wrote:
>> > @@ -680,11 +682,27 @@ p2m_pt_set_entry(struct p2m_domain *p2m,
>> unsigned long gfn, mfn_t mfn,
>> > }
>> > else if ( iommu_pte_flags )
>> > for
>>> On 02.06.16 at 09:25, wrote:
> On June 01, 2016 6:24 PM, Jan Beulich wrote:
>> >>> On 31.05.16 at 15:57, wrote:
> As would a respective change to vtd_set_hwdom_mapping(), which
>> I'm not sure which patch you've put that in.
>>
>
> Sorry, I missed it. I indeed it need to fix it as simila
>>> On 02.06.16 at 04:58, wrote:
> On June 01, 2016 6:39 PM, Jan Beulich wrote:
>> >>> On 31.05.16 at 15:57, wrote:
>> > @@ -2389,16 +2393,25 @@ static int intel_iommu_group_id(u16 seg, u8
>> > bus, u8 devfn) }
>> >
>> > static u32 iommu_state[MAX_IOMMUS][MAX_IOMMU_REGS];
>> > -static void vtd
>>> On 02.06.16 at 10:26, wrote:
> On 06/02/2016 10:35 AM, Jan Beulich wrote:
>> The criteria for inclusion or exclusion should
>> follow a predictable model. I.e. if someone comes along and says
>> "I need register Y", then there should be rules that (s)he can apply
>> up front to determine what
On Tue, May 31, 2016 at 06:44:55AM +0200, Paulina Szubarczyk wrote:
> Implentation of interface to grant copy operation called through
> libxc. An ioctl(gntdev, IOCTL_GNTDEV_GRANT_COPY, ..) system call is
> invoked for linux. In the mini-os the operation is yet not
> implemented.
Thanks for the pa
On 06/02/2016 12:38 PM, Jan Beulich wrote:
On 02.06.16 at 10:26, wrote:
>> On 06/02/2016 10:35 AM, Jan Beulich wrote:
>>> The criteria for inclusion or exclusion should
>>> follow a predictable model. I.e. if someone comes along and says
>>> "I need register Y", then there should be rules tha
On Tue, May 31, 2016 at 06:44:56AM +0200, Paulina Szubarczyk wrote:
> Grant mapping related functions and variables are removed
> on behalf of grant copy operation introduced in following commits.
As David says, you should not remove this before adding a suitable
replacement, or else you are brea
On 02/06/16 01:43, Ed Swierk wrote:
> I'm seeing the xenwatch kernel thread hang intermittently when
> destroying a domU on recent stable xen 4.5, with Linux 4.4.11 + grsec
> dom0.
>
> The domU is created with a virtual network interface connected to a
> physical interface (ixgbevf) via an openvsw
On 01/06/16 17:12, Martin Cerveny wrote:
> Hello.
>
> I hit probably the same error with released "XenServer 7.0".
> - I have Xen4.6.1 (commit d77bac5c064ffb9dbb5b89b55b89853f1b784ebf -
> update Xen version to 4.6.1)
> - XS7 (Dundee) beta3 (kernel-3.10.96-479.383024.x86_64.rpm) work OK
> - XS7 rel
>>> On 01.06.16 at 21:52, wrote:
> From: Suravee Suthikulpanit
>
> The guest IOMMU feature is currently not functioning. However,
> the current guest_iommu_init() is causing issue when it tries to
> register mmio handler because the it is currently called by the
> following code path:
>
> arc
flight 95182 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95182/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 3 host-install(3) broken REG
On Thu, 2016-06-02 at 11:41 +0200, Roger Pau Monné wrote:
> On Tue, May 31, 2016 at 06:44:56AM +0200, Paulina Szubarczyk wrote:
> > Grant mapping related functions and variables are removed
> > on behalf of grant copy operation introduced in following commits.
>
> As David says, you should not rem
Chris Patterson writes ("[[PATCH v2 2/2] libxl: replace deprecated readdir_r()
with readdir()"):
> -for (;;) {
> +while ((de = readdir(dir)) != NULL) {
...
> -int r = readdir_r(dir, de_buf, &de);
> -if (r) {
> -LOGE(ERROR, "failed to readdir %s", SYSFS_USB_DEV);
flight 95187 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95187/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
>>> On 31.05.16 at 15:57, wrote:
> @@ -1455,7 +1455,7 @@ int domain_context_mapping_one(
> */
> if ( rc <= 0 )
> {
> -int flush_dev_iotlb = find_ats_dev_drhd(iommu) ? 1 : 0;
> +bool_t flush_dev_iotlb = find_ats_dev_drhd(iommu) ? 1 : 0;
Please convert all of these t
Jan Beulich writes ("Re: [PATCH for 4.7] xen: Rename of xSplice to livepatch."):
> Perhaps, as I think you had suggested
> elsewhere, separating file name changes from symbols names
> ones would eliminate that issue altogether.
I endorse this product and/or service.
Ian.
__
On Thu, Jun 02, 2016 at 07:31:06AM +, Xu, Quan wrote:
> On May 27, 2016 10:06 PM, Jan Beulich wrote:
> > >>> On 27.05.16 at 15:34, wrote:
> > > On Fri, May 27, 2016 at 06:16:30AM -0600, Jan Beulich wrote:
> > >> >>> On 27.05.16 at 12:39, wrote:
> > >> > Is this a regression? Does it work on
On 02/06/16 10:57, Paulina Szubarczyk wrote:
> On Thu, 2016-06-02 at 11:41 +0200, Roger Pau Monné wrote:
>> On Tue, May 31, 2016 at 06:44:56AM +0200, Paulina Szubarczyk wrote:
>>> Grant mapping related functions and variables are removed
>>> on behalf of grant copy operation introduced in following
>>> On 01.06.16 at 11:05, wrote:
> From: Quan Xu
>
> The parameter 'iommu_dev_iotlb_timeout' specifies the timeout of
> the device IOTLB invalidation in milliseconds. By default, the
> timeout is 1ms, which can be boot-time changed.
>
> Add a __must_check annotation. The followup patch titled
>
On Thu, Jun 02, 2016 at 03:55:41AM -0600, Jan Beulich wrote:
> >>> On 01.06.16 at 21:52, wrote:
> > From: Suravee Suthikulpanit
> >
> > The guest IOMMU feature is currently not functioning. However,
> > the current guest_iommu_init() is causing issue when it tries to
> > register mmio handler be
>>> On 02.06.16 at 12:22, wrote:
> On Thu, Jun 02, 2016 at 07:31:06AM +, Xu, Quan wrote:
>> On May 27, 2016 10:06 PM, Jan Beulich wrote:
>> > >>> On 27.05.16 at 15:34, wrote:
>> > > On Fri, May 27, 2016 at 06:16:30AM -0600, Jan Beulich wrote:
>> > >> >>> On 27.05.16 at 12:39, wrote:
>> > >>
>>> On 02.06.16 at 12:26, wrote:
> On Thu, Jun 02, 2016 at 03:55:41AM -0600, Jan Beulich wrote:
>> >>> On 01.06.16 at 21:52, wrote:
>> > From: Suravee Suthikulpanit
>> >
>> > The guest IOMMU feature is currently not functioning. However,
>> > the current guest_iommu_init() is causing issue when
On Thu, Jun 02, 2016 at 02:11:32AM -0600, Jan Beulich wrote:
> >>> On 01.06.16 at 21:53, wrote:
> > On Wed, Jun 01, 2016 at 10:02:51AM -0600, Jan Beulich wrote:
> >> >>> On 01.06.16 at 17:58, wrote:
> >> > On Fri, May 27, 2016 at 02:37:06AM -0600, Jan Beulich wrote:
> >> >> >>> On 25.05.16 at 21:
>>> On 01.06.16 at 11:05, wrote:
> From: Quan Xu
>
> Today we do Device-TLB flush synchronization after issuing flush
> requests for all ATS devices belonging to a VM. Doing so however
> imposes a limitation, i.e. that we can not figure out which flush
> request is blocked in the flush queue lis
On Thu, Jun 02, 2016 at 04:43:32AM -0600, Jan Beulich wrote:
> >>> On 02.06.16 at 12:26, wrote:
> > On Thu, Jun 02, 2016 at 03:55:41AM -0600, Jan Beulich wrote:
> >> >>> On 01.06.16 at 21:52, wrote:
> >> > From: Suravee Suthikulpanit
> >> >
> >> > The guest IOMMU feature is currently not functi
On Thu, Jun 02, 2016 at 04:38:47AM -0600, Jan Beulich wrote:
> >>> On 02.06.16 at 12:22, wrote:
> > On Thu, Jun 02, 2016 at 07:31:06AM +, Xu, Quan wrote:
> >> On May 27, 2016 10:06 PM, Jan Beulich wrote:
> >> > >>> On 27.05.16 at 15:34, wrote:
> >> > > On Fri, May 27, 2016 at 06:16:30AM -060
>>> On 01.06.16 at 11:05, wrote:
> --- a/xen/drivers/passthrough/vtd/extern.h
> +++ b/xen/drivers/passthrough/vtd/extern.h
> @@ -21,6 +21,7 @@
> #define _VTD_EXTERN_H_
>
> #include "dmar.h"
> +#include "../ats.h"
Why? You don't de-reference struct pci_ats_dev * in this file, so
all you'd need
>>> On 02.06.16 at 12:43, wrote:
> I have checked the code once again. On ARM we allocate memory using
> EfiLoaderData (not only for memory map) and later deliberately do not
> take over these regions. This means that memory map persists. However,
> this also means that we are not able to use a lo
On 01/06/16 14:28, Jan Beulich wrote:
On 01.06.16 at 15:03, wrote:
>> On 01/06/16 13:01, Jan Beulich wrote:
>> I want to adjust the representation of cpuid information in struct
>> domain. The current loop in domain_cpuid() causes an O(N) overhead for
>> every query, which is very
Hi Tamas,
On 02/06/16 02:09, Tamas K Lengyel wrote:
On Wed, Jun 1, 2016 at 3:49 PM, Julien Grall wrote:
On 01/06/2016 18:10, Tamas K Lengyel wrote:
Hi all,
following the steps from http://wiki.xen.org/wiki/HiKey I'm unable to
get the board to boot Xen. I'm using the Debian reference image fr
>>> On 02.06.16 at 13:12, wrote:
> On 01/06/16 14:28, Jan Beulich wrote:
> On 01.06.16 at 15:03, wrote:
>>> On 01/06/16 13:01, Jan Beulich wrote:
>>> I want to adjust the representation of cpuid information in struct
>>> domain. The current loop in domain_cpuid() causes an O(N) overhe
On 01/06/16 21:06, Ivan Pavic wrote:
On Tue, May 31, 2016 at 10:53:06AM +0100, Julien Grall wrote:
Hello Julien,
Hello Ivan,
thank you very much, I succeded with debug console and pin toggle (iomem).
It's actually good that you answered late, because it made me look through xen
traps.c and
On 01/06/16 13:47, Julien Grall wrote:
diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
index 7a1b56b..088625b 100644
--- a/xen/arch/arm/cpufeature.c
+++ b/xen/arch/arm/cpufeature.c
@@ -24,6 +24,22 @@
DECLARE_BITMAP(cpu_hwcaps, ARM_NCAPS);
+void update_cpu_capabilities(co
On 02/06/16 12:34, Jan Beulich wrote:
On 02.06.16 at 13:12, wrote:
>> On 01/06/16 14:28, Jan Beulich wrote:
>> On 01.06.16 at 15:03, wrote:
On 01/06/16 13:01, Jan Beulich wrote:
I want to adjust the representation of cpuid information in struct
domain. The current
On 01/06/16 13:47, Julien Grall wrote:
diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
index 7a1b56b..088625b 100644
--- a/xen/arch/arm/cpufeature.c
+++ b/xen/arch/arm/cpufeature.c
@@ -24,6 +24,22 @@
DECLARE_BITMAP(cpu_hwcaps, ARM_NCAPS);
+void update_cpu_capabilities(co
Hi Peng,
On 01/06/16 08:51, Peng Fan wrote:
The vmap initialization code (vm_init_type) will round down
the end of the region to a page-aligned address.
On ARM64, the default vmap region is located between 1G and 2G.
Based on the initialization code, the end address is excluded
of the region.
On Wed, Jun 01, 2016 at 11:40:51PM +0200, Olaf Hering wrote:
> On Wed, Jun 01, Olaf Hering wrote:
>
> > Here is a list. Essentially it means that upgrading dom0 to xen-4.7
> > might break existing domU if they happen to use xvd* in domU.cfg:
>
> Actually the list goes like shown below after some
On Thu, Jun 02, Wei Liu wrote:
> On Wed, Jun 01, 2016 at 11:40:51PM +0200, Olaf Hering wrote:
> > tool_ver vdev_str qemu format usable bootable
> > xen-4.5 xvd qmain qcow2 yes SUSE:no, staging:yes
> What does "staging" mean?
That should have been staging-4.5.
Some change bet
>>> On 02.06.16 at 13:03, wrote:
> On Thu, Jun 02, 2016 at 04:38:47AM -0600, Jan Beulich wrote:
>> >>> On 02.06.16 at 12:22, wrote:
>> > On Thu, Jun 02, 2016 at 07:31:06AM +, Xu, Quan wrote:
>> >> On May 27, 2016 10:06 PM, Jan Beulich wrote:
>> >> > >>> On 27.05.16 at 15:34, wrote:
>> >> >
>>> On 02.06.16 at 13:44, wrote:
> On 02/06/16 12:34, Jan Beulich wrote:
> On 02.06.16 at 13:12, wrote:
>>> and a
>>> preemptive fix on the HVM side to avoid advertising any XSS states, as
>>> we don't support any yet.
>> I don't think I really like this part. What's wrong with keeping
>> thi
Hello,
On 01/06/16 01:28, Chenxiao Zhao wrote:
On 5/30/2016 4:40 AM, Stefano Stabellini wrote:
On Fri, 27 May 2016, Chenxiao Zhao wrote:
Hi,
My board is Hikey on which have octa-core of arm cortex-a53. I have
applied patches [1] to try vm save/restore on arm.
These patches originally do not
>>> On 06.04.16 at 03:25, wrote:
> This is an RFC for making hvmloader's ACPI builder available to both the
> toolstack and the hypervisor, as discussed in
> http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01228.html
>
> The series
> * Removes dependency of today's builder on hvml
>>> On 06.04.16 at 03:25, wrote:
> @@ -856,6 +857,12 @@ int hpet_exists(unsigned long hpet_base)
> return ((hpet_id >> 16) == 0x8086);
> }
>
> +void hvmloader_acpi_build_tables(struct acpi_config *config,
> + unsigned int physical)
> +{
> +acpi_build_tab
On June 02, 2016 5:21 PM, Jan Beulich wrote:
> I really don't know what else I
> could have done to make clear what exceptions are to be expected.
Sorry, it may make you frustrated, but what you said is very clear. I really
need to slow down and read your email along with code context carefully
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2016-4963 / XSA-178
version 3
Unsanitised driver domain input in libxl device handling
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
==
>>> On 06.04.16 at 03:25, wrote:
> acpi_info can be initialized by hvmloader itself. Now ACPI code
> doesn't need to use hvmloader-private variables/routines such as
> uart_exists(), lpt_exists() etc.
So from a mechanical pov the patch looks fine (one remark below),
but if you move this out from
>>> On 06.04.16 at 03:25, wrote:
> --- a/tools/firmware/hvmloader/acpi/build.c
> +++ b/tools/firmware/hvmloader/acpi/build.c
> @@ -448,32 +448,24 @@ static int construct_secondary_tables(unsigned long
> *table_ptrs,
> *
> * Return 0 if memory failure, != 0 if success
> */
> -static int new_
On June 02, 2016 8:09 PM, Jan Beulich wrote:
> >>> On 02.06.16 at 13:03, wrote:
> > On Thu, Jun 02, 2016 at 04:38:47AM -0600, Jan Beulich wrote:
> >> >>> On 02.06.16 at 12:22, wrote:
> >> > On Thu, Jun 02, 2016 at 07:31:06AM +, Xu, Quan wrote:
> >> >> On May 27, 2016 10:06 PM, Jan Beulich w
>>> On 06.04.16 at 03:25, wrote:
> With that, xenstore_read() won't need to be done in ACPI code
Except for maybe s/build/install/ in the title, this patch looks fine.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-de
On Thu, 2 Jun 2016, Martin Cerveny wrote:
On Wed, 1 Jun 2016, Boris Ostrovsky wrote:
On 06/01/2016 05:01 PM, Martin Cerveny wrote:
Hello.
On Wed, 1 Jun 2016, Boris Ostrovsky wrote:
On 06/01/2016 12:23 PM, Martin Cerveny wrote:
:-(
On Wed, 1 Jun 2016, Martin Cerveny wrote:
I hit proba
On Thu, Jun 2, 2016 at 6:11 AM, Ian Jackson wrote:
> Chris Patterson writes ("[[PATCH v2 2/2] libxl: replace deprecated
> readdir_r() with readdir()"):
>> -for (;;) {
>> +while ((de = readdir(dir)) != NULL) {
> ...
>> -int r = readdir_r(dir, de_buf, &de);
>> -if (r) {
>> -
>>> On 02.06.16 at 15:05, wrote:
> On June 02, 2016 8:09 PM, Jan Beulich wrote:
>> >>> On 02.06.16 at 13:03, wrote:
>> > On Thu, Jun 02, 2016 at 04:38:47AM -0600, Jan Beulich wrote:
>> >> >>> On 02.06.16 at 12:22, wrote:
>> >> > On Thu, Jun 02, 2016 at 07:31:06AM +, Xu, Quan wrote:
>> >> >>
On Tue, May 31, 2016 at 06:44:57AM +0200, Paulina Szubarczyk wrote:
> Grant copy operation is divided into two phases different for
> 'read' and 'write' operation.
>
> For a 'read' operation the flow is as follow:
> 1. allocate local buffers for all the segments contained in
>a request
>>> On 06.04.16 at 03:25, wrote:
> --- a/tools/firmware/hvmloader/acpi/acpi2_0.h
> +++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
> @@ -481,6 +481,10 @@ struct acpi_config {
> struct acpi_info acpi_info;
> uint64_t vm_gid[2];
> uint32_t table_flags;
> +struct {
> +unsigne
On June 02, 2016 9:30 PM, Jan Beulich wrote:
> >>> On 02.06.16 at 15:05, wrote:
> > On June 02, 2016 8:09 PM, Jan Beulich wrote:
> >> >>> On 02.06.16 at 13:03, wrote:
> >> > On Thu, Jun 02, 2016 at 04:38:47AM -0600, Jan Beulich wrote:
> >> >> >>> On 02.06.16 at 12:22, wrote:
> >> >> > On Thu
>>> On 06.04.16 at 03:25, wrote:
> @@ -485,6 +494,10 @@ struct acpi_config {
> unsigned long acpi_pt_addr;
> uint32_t acpi_pt_length;
> } pt;
> +uint32_t nr_vcpus;
> +uint8_t *vcpu_online;
> +int apic_mode;
Instead of copying those fields, how about simply addi
>>> On 06.04.16 at 03:25, wrote:
> @@ -371,41 +370,43 @@ static int construct_secondary_tables(unsigned long
> *table_ptrs,
> printf("S4 disabled\n");
> }
>
> -/* TPM TCPA and SSDT. */
> -tis_hdr = (uint16_t *)0xFED40F00;
> -if ( (tis_hdr[0] == tis_signature[0]) &&
> -
On Tue, May 31, 2016 at 06:44:58AM +0200, Paulina Szubarczyk wrote:
> If there are still pending requests the buffers are not free() but
> cached in an array of a size max_request*BLKIF_MAX_SEGMENTS_PER_REQUEST
>
> ---
> hw/block/xen_disk.c | 60
> +---
Hello Tamas,
On 01/06/16 16:41, Tamas K Lengyel wrote:
On Jun 1, 2016 05:37, "Julien Grall" mailto:julien.gr...@arm.com>> wrote:
> On 29/05/16 23:37, Tamas K Lengyel wrote:
>>
>> Add support for monitoring ARM SMC events. This patch only adds the
required
>> bits to enable/disable monitori
On Wed, Jun 01, 2016 at 01:49:23PM +0800, Bob Liu wrote:
>
> On 06/01/2016 04:33 AM, Konrad Rzeszutek Wilk wrote:
> > On Tue, May 31, 2016 at 04:59:16PM +0800, Bob Liu wrote:
> >> Sometimes blkfont may receive twice blkback_changed() notification after
> >> migration, then talk_to_blkback() will b
>>> On 06.04.16 at 03:25, wrote:
> --- a/tools/firmware/hvmloader/acpi/build.c
> +++ b/tools/firmware/hvmloader/acpi/build.c
> @@ -344,9 +344,12 @@ static int construct_secondary_tables(unsigned long
> *table_ptrs,
> }
>
> /* WAET. */
> -waet = construct_waet();
> -if (!waet)
flight 95193 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95193/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
On Tue, May 31, 2016 at 11:24:10AM +0100, Julien Grall wrote:
> Hi Stefano,
>
> On 31/05/16 10:21, Stefano Stabellini wrote:
> >On Mon, 30 May 2016, Julien Grall wrote:
> >>Hi Stefano,
> >>
> >>On 30/05/2016 15:45, Stefano Stabellini wrote:
> >>>On Mon, 23 May 2016, Julien Grall wrote:
> Hi St
>>> On 02.06.16 at 16:05, wrote:
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -470,15 +470,15 @@ F: xen/include/xsm/
> F: xen/xsm/
> F: docs/misc/xsm-flask.txt
>
> -XSPLICE
> +LIVEPATCH
> M: Konrad Rzeszutek Wilk
> M: Ross Lagerwall
> S: Supported
> -F: docs/misc/xsplice.markdown
>
On 06/01/2016 11:18 AM, Julien Grall wrote:
> Hi Andre,
>
> On 01/06/16 16:56, Andre Przywara wrote:
I would like to support both the interfaces
(ACPI_DBG2_SBSA_32/ACPI_DBG2_SBSA) If you are okay.
>>>
>>> I am a bit puzzled, so your UART is only supporting 32-bit access (i.e
>>> no 16-b
On Thu, 2 Jun 2016, Julien Grall wrote:
> Hi Peng,
>
> On 01/06/16 08:51, Peng Fan wrote:
> > The vmap initialization code (vm_init_type) will round down
> > the end of the region to a page-aligned address.
> >
> > On ARM64, the default vmap region is located between 1G and 2G.
> > Based on the i
On 02/06/16 15:50, Jan Beulich wrote:
>
>> --- a/xen/arch/arm/xsplice.c
>> +++ b/xen/arch/arm/livepatch.c
>> @@ -4,67 +4,67 @@
>> #include
>> #include
>> #include
>> -#include
>> -#include
>> +#include
>> +#include
>>
>> -void arch_xsplice_patching_enter(void)
>> +void arch_livepatching
flight 95185 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95185/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken
REGR. v
On 5/27/2016 4:19 PM, Lan Tianyu wrote:
On 2016年05月26日 19:35, Andrew Cooper wrote:
On 26/05/16 09:29, Lan Tianyu wrote:
To be viable going forwards, any solution must work with PVH/HVMLite as
much as HVM. This alone negates qemu as a viable option.
From a design point of view, having Xen need
The macros: atomic_inc_and_max and atomic_dec_and_assert
use also the 'stats' to access them. Had to open-code
access to pool->pgp_count as it would not work anymore.
No functional change.
Signed-off-by: Konrad Rzeszutek Wilk
Reviewed-by: Doug Goldstein
---
Cc: Andrew Cooper
Cc: Jan Beulich
Hey!
Since RFC [http://www.gossamer-threads.com/lists/xen/devel/431812]
- Added Reviewed-by from Doug
- Dropped the RFC
These four little cleanups move the bulk of tmem control ops
from tmem.c to tmem_control.c.
Last release I moved the control tmem ops from being part of tmem
hypercall to be
Hi Konrad,
On 02/06/16 15:46, Konrad Rzeszutek Wilk wrote:
On Tue, May 31, 2016 at 11:24:10AM +0100, Julien Grall wrote:
On 31/05/16 10:21, Stefano Stabellini wrote:
On Mon, 30 May 2016, Julien Grall wrote:
By spinning in __apply_alternatives_multi_stop we protect us against
modification in t
The functionality that is related to migration is left inside
tmem.c. The list of control operations that are in tmem_control
with XEN_SYSCTL_TMEM_OP prefix are:
DESTROY, FLUSH, FREEZE, THAW, LIST, QUERY_FREEABLE_MB
SAVE_GET_CLIENT_CAP, SAVE_GET_CLIENT_FLAGS,
SAVE_GET_CLIENT_WEIGHT, SAVE_GET_MAXPO
These three patches came out of my development of the XSA-175/XSA-178
fixes.
The rest of the XSA-175/XSA-178 patches, as sent out in the advisory,
have just been applied to staging. These three patches have not, yet.
___
Xen-devel mailing list
Xen-dev
Rather than an open-coded sscanf. No functional change with correct
input.
This is a followup to XSA-175 and XSA-178.
Signed-off-by: Ian Jackson
Reviewed-by: Wei Liu
---
tools/libxl/libxl.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl.c b/tool
xenstore-paths.markdown talked about ~/device/serial/, but that's not
used.
(It is very wrong for this value, which contains a driver domain
filesystem path, to be in the guest's area of xenstore. However, it
is only ever created by libxl and ready by xenconsoled. When it is
created, it inherits
When allocating a vdev for a new disk, look in /libxl/device, rather
than the frontends directory in xenstore.
This is more in line with the other parts of libxl, which ought not to
trust frontends. In this case, though, there is no security bug prior
to this patch because the frontend is the too
Put them all in one structure to make it easier to
figure out what can be removed. The structure is called
'tmem_global' as it will be eventually non-static.
Signed-off-by: Konrad Rzeszutek Wilk
Reviewed-by: Doug Goldstein
---
Cc: Andrew Cooper
Cc: Jan Beulich
Cc: Wei Liu
Cc: Doug Goldst
And adjust the macro: atomic_inc_and_max to update the structure.
Sadly one entry: pool->pgp_count cannot use this macro anymore
so unroll the macro for this instance.
No functional change. The name has the 'tmem_stats' as it will
be eventually non-local.
Signed-off-by: Konrad Rzeszutek Wilk
Re
On Thu, Jun 02, 2016 at 04:10:29PM +0100, Ian Jackson wrote:
> These three patches came out of my development of the XSA-175/XSA-178
> fixes.
>
> The rest of the XSA-175/XSA-178 patches, as sent out in the advisory,
> have just been applied to staging. These three patches have not, yet.
>
Pleas
On 02/06/16 16:04, Julien Grall wrote:
Hi Konrad,
On 02/06/16 15:46, Konrad Rzeszutek Wilk wrote:
On Tue, May 31, 2016 at 11:24:10AM +0100, Julien Grall wrote:
On 31/05/16 10:21, Stefano Stabellini wrote:
On Mon, 30 May 2016, Julien Grall wrote:
By spinning in __apply_alternatives_multi_st
1 - 100 of 214 matches
Mail list logo
