>>> On 18.02.15 at 01:31, wrote:
> On 2/17/2015 4:35 PM, Suravee Suthikulanit wrote:
>> Ok, now that I look at the arch/arm/physdev.c, I don't think the code
>> for supporting any of the PHYSDEVOP_xxx is there. That's probably why
>> Xen complains. In contrast, arch/x86/physdev.c has most PHYSDEV
>>> On 17.02.15 at 19:25, wrote:
> On Tue, Feb 17, 2015 at 12:33:12PM +, Jan Beulich wrote:
>> For all further changes done here, I'd really like to first understand
>> why you don't simply add extra RMRRs based on the command line
>> option introduced in the next patch, as that would appear t
Instead of using a function local static e820 map in xen_memory_setup()
and calling various functions in the same source with the map as a
parameter use a map directly accessible by all functions in the source.
Signed-off-by: Juergen Gross
---
arch/x86/xen/setup.c | 96 ++
Direct Xen to place the initial P->M table outside of the initial
mapping, as otherwise the 1G (implementation) / 2G (theoretical)
restriction on the size of the initial mapping limits the amount
of memory a domain can be handed initially.
As the initial P->M table is copied rather early during bo
Check whether the page tables built by the domain builder are at
memory addresses which are in conflict with the target memory map.
If this is the case just panic instead of running into problems
later.
Signed-off-by: Juergen Gross
---
arch/x86/xen/mmu.c | 15 ---
1 file changed, 12
Support 64 bit pv-domains with more than 512GB of memory.
Tested with 64 bit dom0 on machines with 8GB and 1TB and 32 bit dom0 on a
8GB machine. Conflicts between E820 map and different hypervisor populated
memory areas have been tested via a fake E820 map reserved area on the
8GB machine.
Juerge
With adapting the memory layout of dom0 to that of the host care must
be taken not to remap the initial p2m list supported by the hypervisor.
If the p2m map is detected to be in a region which is going to be
remapped, delay the remapping of that area. Not doing so can either
crash the system very
Currently especially for dom0 guest memory with guest pfns not
matching host areas populated with RAM are remapped to areas which
are RAM native as well. This is done to be able to use identity
mappings (pfn == mfn) for I/O areas.
Up to now it is not checked whether the remapped memory is already
64 bit pv-domains under Xen are limited to 512 GB of RAM today. The
main reason has been the 3 level p2m tree, which was replaced by the
virtual mapped linear p2m list. Parallel to the p2m list which is
being used by the kernel itself there is a 3 level mfn tree for usage
by the Xen tools and event
The linear p2m list should be anchored in the shared info structure
read by the Xen tools to be able to support 64 bit pv-domains larger
than 512 MB. Additionally the linear p2m list interface includes a
generation count which is changed prior to and after each mapping
change of the p2m list. Readi
xen_set_identity_and_remap() is used to prepare remapping of memory
conflicting with the E820 map. It is tracking the pfn where to remap
new memory via a local variable which is passed to a subfunction
which in turn returns the new value for that variable.
Additionally the targeted maximum pfn is
For being able to relocate pre-allocated data areas like initrd or
p2m list it is mandatory to find a contiguous memory area which is
not yet in use and doesn't conflict with the memory map we want to
be in effect.
In case such an area is found reserve it at once as this will be
required to be don
When adapting the dom0 memory layout to that of the host make sure
the initrd isn't moved to another pfn range, as it won't be found
there any more.
The easiest way to accomplish that is by copying the initrd to an
area which is RAM according to the E820 map.
Signed-off-by: Juergen Gross
---
ar
In case a pre-allocated memory area is to be moved in order to avoid
a conflict with the target E820 map we need a way to copy data between
physical addresses.
Add a function doing this via early_memremap().
Signed-off-by: Juergen Gross
---
arch/x86/xen/setup.c | 29 ++
Use the newest header from the xen tree to get some new structure
layouts.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/xen/interface.h | 96
1 file changed, 87 insertions(+), 9 deletions(-)
diff --git a/arch/x86/include/asm/xen/interface.h
b/arch/
Checks whether the pre-allocated memory of the loaded kernel is in
conflict with the target memory map. If this is the case, just panic
instead of run into problems later.
Signed-off-by: Juergen Gross
---
arch/x86/xen/setup.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/x
On 2/17/2015 6:31 PM, Suravee Suthikulanit wrote:
On 2/17/2015 4:35 PM, Suravee Suthikulanit wrote:
On 2/17/2015 7:50 AM, Andrew Cooper wrote:
On 17/02/15 13:43, Julien Grall wrote:
(CC Jan and Andrew)
Hi Suravee,
On 17/02/15 03:04, Suravee Suthikulanit wrote:
By the way, looking at the out
Jim Fehlig wrote:
> Anthony PERARD wrote:
>
>> On Mon, Feb 02, 2015 at 05:00:34PM -0700, Jim Fehlig wrote:
>>
>>
>>> This small series fixes some assertions we occasionally see in the
>>> libxl driver when running libvirt-TCK. The assertions were due to
>>> races between destroying per-
Change the domain event handler code to use the driver-wide
libxl_ctx instead of the domain-specific one.
Signed-off-by: Jim Fehlig
---
src/libxl/libxl_domain.c | 37 +
1 file changed, 25 insertions(+), 12 deletions(-)
diff --git a/src/libxl/libxl_domain.c b/
Informing libxl how to handle its child proceses should be done once
during driver initialization, not once for each domain-specific
libxl_ctx object. The related libxl documentation in
$xen-src/tools/libxl/libxl_event.h even mentions that "it is best to
call this at initialisation".
Signed-off-b
Register a domain event handler with the driver-wide libxl_ctx
during driver initialization.
Signed-off-by: Jim Fehlig
---
src/libxl/libxl_domain.c | 21 ++---
src/libxl/libxl_domain.h | 15 +++
src/libxl/libxl_driver.c | 9 +
3 files changed, 26 insertions(+
This function now only enables domain death events. Simply call
libxl_evenable_domain_death() instead of an unnecessary wrapper.
Signed-off-by: Jim Fehlig
---
src/libxl/libxl_domain.c | 32 +++-
src/libxl/libxl_domain.h | 5 -
src/libxl/libxl_driver.c | 5 +++--
This series is a follow up to
https://www.redhat.com/archives/libvir-list/2015-February/msg00024.html
It goes a step further and changes the libxl driver to use one,
driver-wide libxl_ctx. Currently the libxl driver has one driver-wide
ctx for operations that are not domain-specific and a ctx fo
Although needed in the Xen 4.1 libxl days, there is no longer any
benefit to having per-domain libxl_ctx. On the contrary, their use
makes the code unecessarily complicated and prone to deadlocks under
load. As suggested by the libxl maintainers, use a single libxl_ctx
as a handle to libxl instea
libxlDomainFreeMem() is only used in libxl_domain.c and thus should
be declared static. While at it, change the signature to take a
libxl_ctx instead of libxlDomainObjPrivatePtr, since only the
libxl_ctx is needed.
Signed-off-by: Jim Fehlig
---
src/libxl/libxl_domain.c | 16
sr
Long ago I incorrectly associated libxl fd and timer registrations
with per-domain libxl_ctx objects. When creating a libxlDomainObjPrivate,
a libxl_ctx is allocated, and libxl_osevent_register_hooks is called
passing a pointer to the libxlDomainObjPrivate. When an fd or timer
registration occurr
Instead of using the libxl_ctx in the libxlDomainObjPrivatePtr,
use the ctx passed to the callback.
Signed-off-by: Jim Fehlig
---
src/libxl/libxl_domain.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index e186c53..9
The DEBUG log level is very verbose and can quickly fill a
filesystem hosting /var/log/libvirt/libxl/
Signed-off-by: Jim Fehlig
---
Ideally, the log level should match what is configured in libvirtd.conf.
Are the logging knob settings available in the drivers? If not, this
would be a good optio
Domain death watch is already disabled in libxlDomainCleanup. No
need to disable it a second and third time.
Signed-off-by: Jim Fehlig
---
src/libxl/libxl_domain.c | 8
1 file changed, 8 deletions(-)
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 21c41d7..e186c
flight 34629 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34629/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels
fail pass in 34574
Regressions whic
On 02/17/15 09:11, Andrew Cooper wrote:
> On 16/02/15 23:05, Don Slutz wrote:
>> A tool to get and set hvm param.
>>
>> Signed-off-by: Don Slutz
>
> I had completely forgotten that you did a tool like this before.
>
> Here is one I implemented myself,
>
> https://github.com/xenserver/xen-4.5.pg
flight 34663 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34663/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 33866
build-amd64-rumpuserx
On 02/17/15 05:08, Paul Durrant wrote:
>> -Original Message-
>> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
>> boun...@lists.xen.org] On Behalf Of Don Slutz
>> Sent: 16 February 2015 23:05
>> -static void hvm_unmap_ioreq_page(struct hvm_ioreq_server *s, bool_t
>> buf)
>> +sta
On Tue, Feb 17, 2015 at 12:12 PM, Luis R. Rodriguez
wrote:
> OK I'll keep xen_memory_setup() and its requirements then only if
> XEN_PV is enabled but not XEN_PVH. As for the rest of enlighten.c and
> friends -- this is just collateral. What files should we just need for
> just XEN_PVHVM when XEN_
On 02/17/15 05:30, Andrew Cooper wrote:
> On 16/02/15 23:05, Don Slutz wrote:
>> This includes adding is_vmware_port_enabled
...
>> @@ -5859,6 +5863,12 @@ long do_hvm_op(unsigned long op,
>> XEN_GUEST_HANDLE_PARAM(void) arg)
>> break;
>> if ( a.value > 1 )
>
On 17/12/14 1:38 am, Julien Grall wrote:
The main goal is to modify as little the Linux code to be able to port
easily new feature added in Linux repo for the driver.
To achieve that we:
- Add helpers to Linux function not implemented on Xen
- Add callbacks used by Xen to do our own s
branch xen-4.4-testing
xen branch xen-4.4-testing
job build-amd64
test xen-build
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-4.4-testing.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
B
flight 34628 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34628/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 5 xen-boot fail REGR. vs. 34568
test-amd64-i386-xl-qem
On 2/17/2015 4:35 PM, Suravee Suthikulanit wrote:
On 2/17/2015 7:50 AM, Andrew Cooper wrote:
On 17/02/15 13:43, Julien Grall wrote:
(CC Jan and Andrew)
Hi Suravee,
On 17/02/15 03:04, Suravee Suthikulanit wrote:
By the way, looking at the output of "xl dmesg", I saw the following
message:
(X
In preparation for allowing for introspecting ARM and PV domains the old
control interface via the hvm_op hypercall is retired. A new control mechanism
is introduced via the domctl hypercall: monitor_op.
This patch aims to establish a base API on which future applications can build
on.
Suggested-
In this patch we mechanically rename mem_event to vm_event. This patch
introduces no logic changes to the code. Using the name vm_event better
describes the intended use of this subsystem, which is not limited to memory
events. It can be used for off-loading the decision making logic into helper
ap
The memop handler function for paging/sharing responsible for calling XSM
doesn't really have anything to do with vm_event, thus in this patch we
relocate it into mem_paging_memop and mem_sharing_memop. This has already
been the approach in mem_access_memop, so in this patch we just make it
consist
Fix style issues left over from the renaming to vm_event and other minor
alignment issues.
Signed-off-by: Tamas K Lengyel
---
xen/common/vm_event.c | 36 +++-
xen/include/xen/vm_event.h | 18 +-
2 files changed, 20 insertions(+), 34 deletions(
The XSM label vm_event_op has been used to control the three memops
controlling mem_access, mem_paging and mem_sharing. While these systems
rely on vm_event, these are not vm_event operations themselves. Thus,
in this patch we introduce three separate labels for each of these memops.
Signed-off-by
To avoid growing hvm.c these functions can be stored separately. Minor style
changes are applied to the logic in the file.
Signed-off-by: Tamas K Lengyel
Acked-by: Kevin Tian
---
v6: Style fixes
v5: Style fixes
Fix hvm_event_msr input types to match the incoming variables
v4: Style fixes
v3:
The name of one of the mem_event rings still implies it is used only
for memory accesses, which is no longer the case. It is also used to
deliver various HVM events, thus the name "monitor" is more appropriate
in this setting.
Couple functions incorrectly labeled as part of mem_event is also renam
The spin-lock implementation in the xen-access test program is implemented
in a fashion that is actually incomplete. The x86 assembly that guarantees that
the lock is held by only one thread lacks the "lock;" instruction.
However, the spin-lock is not actually necessary in xen-access as it is not
The public mem_event structures used to communicate with helper applications via
shared rings have been used in different settings. However, the variable names
within this structure have not reflected this fact, resulting in the reuse of
variables to mean different things under different scenarios.
There are no use-cases for this flag.
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/mm/mem_sharing.c | 3 ---
xen/arch/x86/mm/p2m.c | 3 ---
xen/common/mem_access.c | 3 ---
xen/include/public/vm_event.h | 1 -
4 files changed, 10 deletions(-)
diff --git a/xen/arch/x86/mm/mem_sh
The vm_event subsystem has been artifically tied to the presence of mem_access.
While mem_access does depend on vm_event, vm_event is an entirely independent
subsystem that can be used for arbitrary function-offloading to helper apps in
domains. This patch removes the dependency that mem_access nee
The only use-case of the mem_event_op structure had been in mem_paging,
thus renaming the structure mem_paging_op and relocating its associated
functions clarifies its actual usage.
As part of this fix-up we also convert the gfn's in the toolstack to be
explicitely 64-bit wide and clean the code a
Thus far mem_access and mem_sharing memops had been able to signal
to Xen to start pulling responses off the corresponding rings. In this patch
we retire these memops and add them to the option to the vm_event_op domctl.
The vm_event_op domctl suboptions are the same for each ring thus we
consolid
This patch series aims to clean up the mem_event subsystem within Xen. The
original use-case for this system was to allow external helper applications
running in privileged domains to control various memory operations performed
by Xen. Amongs these were paging, sharing and access control. The subsy
On Tue, Feb 17, 2015 at 7:20 PM, Tamas K Lengyel
wrote:
> On Tue, Feb 17, 2015 at 3:02 PM, Jan Beulich wrote:
> On 13.02.15 at 17:33, wrote:
>>> --- a/xen/arch/x86/hvm/emulate.c
>>> +++ b/xen/arch/x86/hvm/emulate.c
>>> @@ -411,7 +411,8 @@ static int hvmemul_virtual_to_linear(
>>> * bei
On 02/17/15 09:44, Andrew Cooper wrote:
> On 16/02/15 23:05, Don Slutz wrote:
>> This is needed by me to build this test
>>
>> Signed-off-by: Don Slutz
>
> That is because you broke it with patch 6 by introducing do_vmport.
>
Sigh. Fixed it in patch #6... This patch will disappear in v10.
On 02/17/15 12:55, Andrew Cooper wrote:
> XenServer's VM density testing uncovered a regression when moving from
> sysvinit to systemd where the file descriptor limit dropped from 4096 to
> 1024. (XenServer had previously inserted a ulimit statement into its
> initscripts.)
>
> One solution is to
On 2/17/2015 7:50 AM, Andrew Cooper wrote:
On 17/02/15 13:43, Julien Grall wrote:
(CC Jan and Andrew)
Hi Suravee,
On 17/02/15 03:04, Suravee Suthikulanit wrote:
By the way, looking at the output of "xl dmesg", I saw the following
message:
(XEN) DOM0: PCI host bridge /smb/pcie@f000 ranges
On 02/17/15 04:52, Andrew Cooper wrote:
> On 16/02/15 23:05, Don Slutz wrote:
>> Change some hard coded 15 into MAX_INST_LEN
>>
>> Signed-off-by: Don Slutz
>
> One formatting suggestion.
>
>> ---
...
>> diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c
>> b/xen/arch/x86/x86_emulate/x86_emulat
flight 34627 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34627/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 11 guest-localmigrate fail REGR. vs. 33488
test-amd64
On Mon, Feb 16, 2015 at 11:39 PM, Juergen Gross wrote:
> On 02/17/2015 01:20 AM, Luis R. Rodriguez wrote:
>>
>> On Thu, Feb 12, 2015 at 3:07 AM, David Vrabel
>> wrote:
>>>
>>> On 12/02/15 06:03, Luis R. Rodriguez wrote:
From: "Luis R. Rodriguez"
Here's the first shot at the K
On Tue, Feb 17, 2015 at 12:46:40PM +, Jan Beulich wrote:
> >>> On 13.02.15 at 19:51, wrote:
> > Set need_iommu for dom0 early so pvh specific functions
> > in construct_dom0 can pass this check.
> > See example in p2m-ept.c ept_set_entry.
> >
> > Signed-off-by: Elena Ufimtseva
>
> Having go
On Mon, Feb 16, 2015 at 11:26 PM, Juergen Gross wrote:
> On 02/17/2015 01:25 AM, Luis R. Rodriguez wrote:
>>
>> On Mon, Feb 16, 2015 at 4:20 PM, Luis R. Rodriguez
>> wrote:
>>>
>>> As it is per our agreed upon changes we can in theory enable a
>>> XEN_PVHVM system without XEN_PV or XEN_PVH. If th
I didn't receive the original message, so I can't reply to it directly.
> Hi all
>
> We are now one month into 4.6 development window. This is an email to keep
> track of all the patch series I gathered. It is by no means complete and / or
> acurate. Feel free to reply this email with new project
On Tue, Feb 17, 2015 at 7:34 PM, Andrew Cooper
wrote:
> On 17/02/15 18:30, Tamas K Lengyel wrote:
>>> All these whitespace changes here and further down don't really
>>> belong in this patch - please again get this right when adding the
>>> code.
>> Same issue I mentioned in the other patch: git -
On Tue, Feb 17, 2015 at 7:37 PM, Andrew Cooper
wrote:
> On 17/02/15 18:20, Tamas K Lengyel wrote:
>> +//
>> +/*monitor event options */
>> +//
>> +struct mov_to_cr {
>> +uint
On Tue, Feb 17, 2015 at 3:25 PM, Jan Beulich wrote:
On 13.02.15 at 17:33, wrote:
>> -int mem_paging_memop(struct domain *d, xen_mem_paging_op_t *mpo)
>> +int mem_paging_memop(unsigned long cmd,
>> + XEN_GUEST_HANDLE_PARAM(xen_mem_paging_op_t) arg)
>> {
>> -int rc = -
On 17/02/15 18:20, Tamas K Lengyel wrote:
> +//
> +/*monitor event options */
> +//
> +struct mov_to_cr {
> +uint8_t enabled;
> +uint8_t sync;
> +uint8_t onchangeonly;
On Tue, Feb 17, 2015 at 3:17 PM, Jan Beulich wrote:
On 13.02.15 at 17:33, wrote:
>> @@ -1293,56 +1293,30 @@ int p2m_mem_paging_prep(struct domain *d, unsigned
>> long gfn, uint64_t buffer)
>> *
>> * If the gfn was dropped the vcpu needs to be unpaused.
>> */
>> -void p2m_mem_paging_re
On 17/02/15 18:30, Tamas K Lengyel wrote:
>> All these whitespace changes here and further down don't really
>> belong in this patch - please again get this right when adding the
>> code.
> Same issue I mentioned in the other patch: git -M can't track the
> files if indentation is fixed as part of
On Tue, Feb 17, 2015 at 3:31 PM, Jan Beulich wrote:
On 13.02.15 at 17:33, wrote:
>> @@ -611,13 +611,22 @@ int vm_event_domctl(struct domain *d,
>> xen_domctl_vm_event_op_t *vec,
>> }
>> break;
>>
>> -case XEN_VM_EVENT_PAGING_DISABLE:
>> +case XEN_VM_EVENT_D
On 02/15/2015 01:01 AM, Raghavendra K T wrote:
> On 02/15/2015 11:25 AM, Raghavendra K T wrote:
>> Paravirt spinlock clears slowpath flag after doing unlock.
>> As explained by Linus currently it does:
>> prev = *lock;
>> add_smp(&lock->tickets.head, TICKET_LOCK_IN
On Tue, Feb 17, 2015 at 12:33:12PM +, Jan Beulich wrote:
> >>> On 13.02.15 at 19:52, wrote:
> > --- a/xen/arch/x86/mm/p2m-ept.c
> > +++ b/xen/arch/x86/mm/p2m-ept.c
> > @@ -730,7 +730,7 @@ ept_set_entry(struct p2m_domain *p2m, unsigned long
> > gfn, mfn_t mfn,
> > }
> >
> > if ( mf
On 02/17/15 08:45, Andrew Cooper wrote:
> On 16/02/15 23:05, Don Slutz wrote:
>> Also added missing TRAP_DEBUG & VLAPIC.
>>
>> Signed-off-by: Don Slutz
>
> This patch doesn't actually add any trace points.
>
Sigh. They got lost in rebaseing. Will recover and add to v10.
Here is just the trac
On Tue, Feb 17, 2015 at 3:02 PM, Jan Beulich wrote:
On 13.02.15 at 17:33, wrote:
>> --- a/xen/arch/x86/hvm/emulate.c
>> +++ b/xen/arch/x86/hvm/emulate.c
>> @@ -411,7 +411,8 @@ static int hvmemul_virtual_to_linear(
>> * being triggered for repeated writes to a whole page.
>> */
>>
flight 34637 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34637/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build fail REGR. vs. 34190
build-i386
We are having persistent spurious "xen-boot" failures. Cursory
investigation revealed that this was due to problems with NTP startup,
so we put it down to infrastructure problems.
However, it turns out that the cause is that we are using the
Debian-default NTP servers from pool.ntp.org. We might
Dumper is used in some of the error reporting so we need to `use' it.
Signed-off-by: Ian Jackson
---
cs-adjust-flight |1 +
1 file changed, 1 insertion(+)
diff --git a/cs-adjust-flight b/cs-adjust-flight
index d6cab1a..9bd8757 100755
--- a/cs-adjust-flight
+++ b/cs-adjust-flight
@@ -40,6 +4
Allow the specification of NTP servers in a dedicated NtpServer host
property, which we honour in preseed_create.
Change the documentation to recommend this, rather than use of
ad-hoc text in DebianPreseed.
Signed-off-by: Ian Jackson
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index a044
* Default $c{DebianPreseed} to '' (previously, if it wasn't specified,
there would be undefined variable warnings).
* Cope with empty <
---
Osstest.pm |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Osstest.pm b/Osstest.pm
index fc9698b..6d7c083 100644
--- a/Osstest.pm
This is going to be useful soon.
Signed-off-by: Ian Jackson
---
Osstest/Debian.pm |6 +++---
ts-debian-hvm-install |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index e3e1c90..a044f8f 100644
--- a/Osstest/Debian.pm
+++ b/O
Setting clock-setup/ntp-server is not sufficient: it only takes effect
in the installer (!)
I have reported this as Debian #778564. In the meantime we should
work around it for current releases (including jessie, which is
frozen).
For later releases, the new ntp.conf editing code arranges to bom
Move the specification of NTP servers in the production-config from
the ad-hoc entry in DebianPreseed to a dedicated NtpServer host
property.
This results in no overall functional change, except that the order of
elements in the preseed file is slightly different.
Signed-off-by: Ian Jackson
dif
On Tue, Feb 17, 2015 at 05:31:19PM +, Andrew Cooper wrote:
> On 17/02/15 16:48, Wei Liu wrote:
> > On Tue, Feb 17, 2015 at 04:37:08PM +, Andrew Cooper wrote:
> >
> >> I am not sure what an admin could usefully do with a logged failure
> >> message here. Xenconsoled will most likely not fun
This looks in the supplied $ho, but if that's a $gho (ie it has a
$gho->{Host}) it also looks in its host.
This is going to be useful for a fair variety of host-specific or
infrastructure-determined properties.
It seems to me that whether a property ought to be looked up in the
host if not found
We are putting through a lot more jobs and branches. Older history is
still interesting.
Signed-off-by: Ian Jackson
---
sg-report-job-history |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sg-report-job-history b/sg-report-job-history
index 3e4b0ef..e7052a3 100755
--- a/
XenServer's VM density testing uncovered a regression when moving from
sysvinit to systemd where the file descriptor limit dropped from 4096 to
1024. (XenServer had previously inserted a ulimit statement into its
initscripts.)
One solution is to use LimitNOFILE=4096 in xenconsoled.service to match
Arrange for preseed_base to accumulate its result in a variable. This
is going to make it easier to add entries which are determined
programatically.
No functional change.
Signed-off-by: Ian Jackson
---
Osstest/Debian.pm | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff
On 17/02/15 17:41, Boris Ostrovsky wrote:
> On 02/17/2015 10:44 AM, Andrew Cooper wrote:
>> On 16/02/15 22:26, Boris Ostrovsky wrote:
>>> diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
>>> index 1d5ae8d..cf4c70b 100644
>>> --- a/xen/arch/x86/hvm/vpmu.c
>>> +++ b/xen/arch/x86/hvm/vpm
On 17/02/15 17:38, Boris Ostrovsky wrote:
> On 02/17/2015 10:13 AM, Andrew Cooper wrote:
>> On 16/02/15 22:26, Boris Ostrovsky wrote:
>>> Changes in v18:
>>>
>>> * Return 1 (i.e. "handled") in vpmu_do_interrupt() if PMU_CACHED is
>>>set. This is needed since we can get an interrupt while this f
On 02/17/2015 10:44 AM, Andrew Cooper wrote:
On 16/02/15 22:26, Boris Ostrovsky wrote:
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 1d5ae8d..cf4c70b 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
+static struct vcpu *choose_hwdom_vcpu(void)
+{
+un
Ard,
For the subject, I think
MdePkg/BaseSynchronizationLib: Add InterlockedCompareExchange16
would be better.
Acked-by: Jordan Justen
Thanks for working to move this to a common location.
Mike,
I think Anthony tested the IA32 and X64 implementations with Xen. For
IPF, I don't think it has be
On 02/17/2015 10:13 AM, Andrew Cooper wrote:
On 16/02/15 22:26, Boris Ostrovsky wrote:
Changes in v18:
* Return 1 (i.e. "handled") in vpmu_do_interrupt() if PMU_CACHED is
set. This is needed since we can get an interrupt while this flag is
set on AMD processors when multiple counters are
On Tue, Feb 17, 2015 at 12:56 PM, Jan Beulich wrote:
On 13.02.15 at 17:33, wrote:
>> +static void hvm_event_cr(uint32_t reason, unsigned long value,
>> +unsigned long old)
>> +{
>> +vm_event_request_t req = {
>> +.reason = reason,
>> +.vcpu
On 17/02/15 16:48, Wei Liu wrote:
> On Tue, Feb 17, 2015 at 04:37:08PM +, Andrew Cooper wrote:
>
>> I am not sure what an admin could usefully do with a logged failure
>> message here. Xenconsoled will most likely not function in an
>> environment where it is not sufficiently privileged to mak
Hi Ian,
On 24/10/14 10:58, Ian Campbell wrote:
> These properties are defined in ePAPR and the OpenFirmware PCI Bus Binding
> Specification (IEEE Std 1275-1994).
>
> This replaces the xgene specific mapping. Tested on Mustang and on a model
> with
> a PCI virtio controller.
I'm wondering why yo
flight 34622 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34622/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 5 xen-boot fail REGR. vs. 34227
test-amd64-i386-qemuu
>>> On 17.02.15 at 18:02, wrote:
> flight 34639 xen-4.4-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/34639/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-amd64 5 xen-build
flight 34639 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34639/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build fail REGR. vs. 34151
build-i386-xend
On Tue, Feb 17, 2015 at 04:37:08PM +, Andrew Cooper wrote:
[...]
> >> +
> > This function looks Linux centric (/proc and CAP_SYSRESOURCE). Please be
> > considerate to other Unices. :-)
> >
> > Also you might want to log failures along the line.
> >
> > Wei.
>
> setrlimit() is posix. From the
On Fri, 2015-02-13 at 11:11 -0500, Elena Ufimtseva wrote:
> On Fri, Feb 13, 2015 at 11:06 AM, Wei Liu wrote:
> > On Fri, Feb 13, 2015 at 10:39:25AM -0500, Elena Ufimtseva wrote:
> >> Any sanity checks for distances?
> >>
> >
> > The same applies, what is a valid distance what is not? I guess zero
1 - 100 of 166 matches
Mail list logo
