On Wed, Mar 22, 2017 at 06:47:33AM -0600, Jan Beulich wrote:
On 22.03.17 at 05:53, wrote:
>> I have written a xtf test case (many codes are from hvmloader) to
>> trigger this assertion. The test case is in attachments.
>
>Thanks for doing this.
>
>> Bottom is the output
>> of this test. This
>>> On 04.04.17 at 20:45, wrote:
> On 04/04/17 14:13, Jan Beulich wrote:
>> I'm additionally surprised we don't require input GFNs to be order
>> aligned for both IN- and OUT-chunks (similarly for populate-physmap
>> and decrease-reservation).
>
> This sounds like a bug, rather than being intenti
On 4/3/2017 5:28 PM, Wei Liu wrote:
On Mon, Apr 03, 2017 at 09:13:20AM +0100, Paul Durrant wrote:
-Original Message-
From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 02 April 2017 13:24
To: xen-devel@lists.xen.org
Cc: zhiyuan...@intel.com; Paul Durrant ; Ian
Jackson ; Wei Liu
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Saturday, April 1, 2017 3:51 AM
>
> hvm_long_mode_enabled() tests for EFER.LMA, which is specifically different
> to
> EFER.LME.
>
> Rename it to match its behaviour, and have it strictly return a boolean value
> (although all its c
> From: Mohit Gambhir [mailto:mohit.gamb...@oracle.com]
> Sent: Friday, March 31, 2017 10:46 PM
>
> This patch masks .AnyThread bits in IA32_FIXED_CTR_CTRL MSR for all
> versions of Intel Arhcitectural Performance Monitoring. Note that
> .AnyThread bit (21) is already masked in IA32_PERFEVTSELx MS
> From: Adrian Pop [mailto:a...@bitdefender.com]
> Sent: Tuesday, April 4, 2017 5:58 PM
>
> Adds monitor support for descriptor access events (reads & writes of
> IDTR/GDTR/LDTR/TR) for the x86 architecture (VMX and SVM).
>
> Signed-off-by: Adrian Pop
Reviewed-by: Kevin Tian
_
Hi Julien,
On 2017/3/31 22:33, Julien Grall wrote:
Hi Wei,
On 31/03/17 14:07, Wei Chen wrote:
In previous patches, we have provided the ability to synchronize
SErrors in exception entries. But we haven't synchronized SErrors
while returning to guest and doing context switch.
So we still have
On 2017/4/1 2:43, Julien Grall wrote:
Hi Stefano,
On 03/31/2017 07:42 PM, Stefano Stabellini wrote:
On Fri, 31 Mar 2017, Julien Grall wrote:
Hi Wei,
On 31/03/17 14:07, Wei Chen wrote:
If there is a pending SError while we're returning from trap. If the
SError handle option is "DIVERSE", we h
On Fri, Mar 31, 2017 at 04:38:02AM -0600, Jan Beulich wrote:
On 31.03.17 at 05:27, wrote:
>This then also raises the question whether the call to
>hvm_girq_dest_2_vcpu_id() is actually legitimate for lowest
>priority delivery mode.
For lowest priority delivery mode, if
On 4/3/2017 10:36 PM, Jan Beulich wrote:
So this produces the same -EINVAL as the earlier check in context
above. I think it would be nice if neither did - -EINUSE for the first
(which we don't have, so -EOPNOTSUPP would seem the second
bets option there) and -EBUSY for the second would seem mo
On 05/04/2017 08:14, Wei Chen wrote:
Because the ASSERT I suggested was wrong, sorry for that. It should have
been:
ASSERT(!cpus_have_cap(feat) && local_abort_is_enabled());
This is because we want abort enabled when the "feature" is not present.
This series looks good so far, so I would be
On 2017/4/5 15:29, Julien Grall wrote:
On 05/04/2017 08:14, Wei Chen wrote:
Because the ASSERT I suggested was wrong, sorry for that. It should have
been:
ASSERT(!cpus_have_cap(feat) && local_abort_is_enabled());
This is because we want abort enabled when the "feature" is not present.
This
>>> On 04.04.17 at 21:12, wrote:
> On Fri, Mar 31, 2017 at 04:01:31AM -0600, Jan Beulich wrote:
> On 29.03.17 at 07:11, wrote:
>>> +static void update_irte(struct iremap_entry *entry,
>>> +const struct iremap_entry *new_ire,
>>> +bool atomic)
>>
On Tue, 4 Apr 2017, Ian Jackson wrote:
> Ian Jackson writes ("Re: [Xen-devel] Xen Security Advisory 206 - xenstore
> denial of service via repeated update"):
> > > [-Werror=bool-operation]
> > > if (!domain->wrl_delay_logged++) {
> >
> > I think this warning is wrong.
> ...
> > It's a shame
>>> On 05.04.17 at 01:57, wrote:
> On Wed, Mar 22, 2017 at 06:47:33AM -0600, Jan Beulich wrote:
> On 22.03.17 at 05:53, wrote:
>>> I have written a xtf test case (many codes are from hvmloader) to
>>> trigger this assertion. The test case is in attachments.
>>
>>Thanks for doing this.
>>
>>>
>>> On 05.04.17 at 02:20, wrote:
> On Fri, Mar 31, 2017 at 04:38:02AM -0600, Jan Beulich wrote:
> On 31.03.17 at 05:27, wrote:
>>This then also raises the question whether the call to
>>hvm_girq_dest_2_vcpu_id() is actually legitimate for lowest
>>priority delivery mode.
>
>>
Hi Wei,
On 05/04/2017 08:35, Wei Chen wrote:
On 2017/4/5 15:29, Julien Grall wrote:
On 05/04/2017 08:14, Wei Chen wrote:
Because the ASSERT I suggested was wrong, sorry for that. It should
have
been:
ASSERT(!cpus_have_cap(feat) && local_abort_is_enabled());
This is because we want abort en
flight 107188 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107188/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail REGR. vs.
106822
test-amd64-i
Hi Julien,
On 2017/4/5 15:29, Julien Grall wrote:
On 05/04/2017 08:14, Wei Chen wrote:
Because the ASSERT I suggested was wrong, sorry for that. It should have
been:
ASSERT(!cpus_have_cap(feat) && local_abort_is_enabled());
This is because we want abort enabled when the "feature" is not pre
>>> On 05.04.17 at 09:18, wrote:
> On 4/3/2017 10:36 PM, Jan Beulich wrote:
>> So this produces the same -EINVAL as the earlier check in context
>> above. I think it would be nice if neither did - -EINUSE for the first
>> (which we don't have, so -EOPNOTSUPP would seem the second
>> bets option th
flight 71149 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71149/
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
71117
test-amd64-i
On 23/03/17 13:52, Juergen Gross wrote:
> Connecting to the backend isn't working reliably in xen-fbfront: in
> case XenbusStateInitWait of the backend has been missed the backend
> transition to XenbusStateConnected will trigger the connected state
> only without doing the actions required when th
On 23/03/17 13:53, Juergen Gross wrote:
> Today xen-fbfront supports specifying the display size via module
> parameters only. Add support for specifying the size via Xenstore in
> order to enable doing this easily via the domain's Xen configuration.
>
> Add an error message in case the configured
On 05/04/2017 09:08, Wei Chen wrote:
Hi Julien,
On 2017/4/5 15:29, Julien Grall wrote:
On 05/04/2017 08:14, Wei Chen wrote:
Because the ASSERT I suggested was wrong, sorry for that. It should
have
been:
ASSERT(!cpus_have_cap(feat) && local_abort_is_enabled());
This is because we want abo
>>> On 05.04.17 at 05:12, wrote:
> On 17-04-03 09:50:34, Jan Beulich wrote:
>> >>> On 01.04.17 at 15:53, wrote:
>>
>> I was about to ack this, but there are a few more things which bother
>> me.
>>
> Do you mean ack to this patch 3 or whole patch set? Thanks!
Well, this one patch only - I didn
On Wed, 5 Apr 2017, Richard W.M. Jones wrote:
> On Tue, Apr 04, 2017 at 05:41:08PM -0500, Eric Blake wrote:
> > On 01/19/2017 08:38 AM, Eric Blake wrote:
> > > On 01/19/2017 03:25 AM, Markus Armbruster wrote:
> > >> Eric Blake writes:
> > >>
> > >>> Quite a few users of qdict_put() were manuall
On Wed, Apr 05, 2017 at 10:21:13AM +0200, Julia Lawall wrote:
>
>
> On Wed, 5 Apr 2017, Richard W.M. Jones wrote:
>
> > On Tue, Apr 04, 2017 at 05:41:08PM -0500, Eric Blake wrote:
> > > On 01/19/2017 08:38 AM, Eric Blake wrote:
> > > > On 01/19/2017 03:25 AM, Markus Armbruster wrote:
> > > >> Er
On Tue, Apr 04, 2017 at 05:41:08PM -0500, Eric Blake wrote:
> On 01/19/2017 08:38 AM, Eric Blake wrote:
> > On 01/19/2017 03:25 AM, Markus Armbruster wrote:
> >> Eric Blake writes:
> >>
> >>> Quite a few users of qdict_put() were manually wrapping a
> >>> non-QObject. We can make such call-sites s
Hi Julien,
On 2017/4/5 16:20, Julien Grall wrote:
On 05/04/2017 09:08, Wei Chen wrote:
Hi Julien,
On 2017/4/5 15:29, Julien Grall wrote:
On 05/04/2017 08:14, Wei Chen wrote:
Because the ASSERT I suggested was wrong, sorry for that. It should
have
been:
ASSERT(!cpus_have_cap(feat) && loc
On Wed, 5 Apr 2017, Richard W.M. Jones wrote:
> On Wed, Apr 05, 2017 at 10:21:13AM +0200, Julia Lawall wrote:
> >
> >
> > On Wed, 5 Apr 2017, Richard W.M. Jones wrote:
> >
> > > On Tue, Apr 04, 2017 at 05:41:08PM -0500, Eric Blake wrote:
> > > > On 01/19/2017 08:38 AM, Eric Blake wrote:
> > > >
On 17-04-05 02:20:53, Jan Beulich wrote:
> >>> On 05.04.17 at 05:12, wrote:
> > On 17-04-03 09:50:34, Jan Beulich wrote:
> >> >>> On 01.04.17 at 15:53, wrote:
> >> > +enum psr_feat_type {
> >> > +PSR_SOCKET_L3_CAT,
> >> > +PSR_SOCKET_L3_CDP,
> >> > +PSR_SOCKET_L2_CAT,
> >> > +PSR_
On Wed, Apr 05, 2017 at 01:48:22AM -0600, Jan Beulich wrote:
On 05.04.17 at 01:57, wrote:
>> On Wed, Mar 22, 2017 at 06:47:33AM -0600, Jan Beulich wrote:
>>
>> Hi, Jan.
>>
>> I plan to do the following changes:
>> 1. get the vector set in vIRR to avoid getting a wrong interrupt vector
>> I
There's no reason to store that list inside of the domain_iommu struct, the
forwarding of guest IO ports into machine IO ports is not tied to the presence
of an IOMMU.
Move it inside of the hvm_domain struct instead.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Paul
Hello,
The following series contain two mostly cosmetic fixes for the g2m IO port
handlers.
The first one renames them to use the g2m_ prefix instead of the dpci_ one,
since those handlers are not trapping the PCI config space in any way. The
second fix moves the list of ports from the domain_iom
The dpci_ prefix used on those IO handlers is misleading, there's nothing PCI
specific in them, they simply map a guest IO port into a machine (physical) IO
port. They don't specifically trap the PCI IO port range in any way
(0xcf8/0xcfc).
Rename them to use the g2m_ prefix in order to avoid this
On Wed, Apr 05, 2017 at 10:38:37AM +0200, Julia Lawall wrote:
> OK, there is nothing special about g_assert_cmpint, but Coccinelle expects
> expressions or types in function argument lists, so it gives a parse error
> on finding an ==.
I should have checked the coccinelle mailing list before askin
When guest triggers async aborts, in most platform, such aborts
will be routed to hypervisor. But we don't want the hypervisor
to handle such aborts, so we have to route such aborts back to
the guest.
This helper is using the HCR_EL2.VSE (HCR.VA for aarch32) bit to
route such aborts back to the gu
The HCR_EL2.VSE (HCR.VA for aarch32) bit can be used to generate a
virtual abort to guest. The HCR_EL2.VSE bit has a peculiar feature
of getting cleared when the guest has taken the abort (this is the
only bit that behaves as such in HCR_EL2 register).
This means that if we set the HCR_EL2.VSE bit
Different domains may have different HCR_EL2 flags. For example, the
64-bit domain needs HCR_RW flag but the 32-bit does not need it. So
we give each domain a default HCR_EL2 value and save it in the vCPU's
context.
HCR_EL2 register has only one bit can be updated automatically without
explicit wr
From XSA-201, we know that, a guest could trigger SErrors when accessing
memory mapped HW in a non-conventional way. In the patches for XSA-201,
we crash the guest when we captured such asynchronous aborts to avoid data
corruption.
In order to distinguish guest-generated SErrors from hypervisor-ge
Currently, we masked the Abort/SError bit in Xen exception entries.
So Xen could not capture any Abort/SError while it's running.
Now, Xen has the ability to handle the Abort/SError, we should unmask
the Abort/SError bit by default to let Xen capture Abort/SError while
it's running.
But in order t
The HCR_EL2 flags for 64-bit and 32-bit domains are different. But
when we initialized the HCR_EL2 for vcpu0 of Dom0 and all vcpus of
DomU in vcpu_initialise, we didn't know the domain's address size
information. We had to use compatible flags to initialize HCR_EL2,
and set HCR_RW for 64-bit domain
We want to move part of SErrors checking code from hyp_error assembly code
to a function. This new function will use this macro to distinguish the
guest SErrors from hypervisor SErrors. So we have to move this macro to
common header.
The VABORT_GEN_BY_GUEST macro uses the symbols abort_guest_exit_
We have provided an option to administrator to determine how to
handle the SErrors. In order to skip the check of pending SError,
in conventional way, we have to read the option every time before
we try to check the pending SError. This will add overhead to check
the option at every trap.
The ARM6
We have introduced two helpers to handle the guest/hyp SErrors:
do_trap_guest_serror and do_trap_guest_hyp_serror. These handlers
can take the role of do_trap_guest_serror and reduce the assembly
code in the same time. So we use these two helpers to replace it
and drop it now.
Signed-off-by: Wei C
In the later patches of this series, we want to use the alternative
patching framework to avoid synchronizing serror_op in every entries
and exits. So we define a new cpu feature "SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT"
for serror_op. When serror_op is not equal to SERROR_DIVERSE, this
feature will be
We want to add HCR_EL2 register to Xen context switch. And each copy
of HCR_EL2 in vcpu structure will be initialized with the same set
of trap flags as the HCR_EL2 register. We introduce a helper here to
represent these flags to be reused easily.
Signed-off-by: Wei Chen
Reviewed-by: Julien Grall
We have provided an option to administrator to determine how to
handle the SErrors. In order to skip the check of pending SError,
in conventional way, we have to read the option every time before
we try to check the pending SError. This will add overhead to check
the option at every trap.
The ARM3
In order to distinguish guest-generated SErrors from hypervisor-generated
SErrors we have to place SError checking code in every EL1 <-> EL2 paths.
That will cause overhead on entries and exits due to dsb/isb.
However, not all platforms want to categorize SErrors. For example, a host
that is runni
Currently, ARM32 and ARM64 has different SError exception handlers.
These handlers include lots of code to check SError handle options
and code to distinguish guest-generated SErrors from hypervisor
SErrors.
The new helpers: do_trap_guest_serror and do_trap_hyp_serror are
wrappers of __do_trap_ser
In previous patches, we have provided the ability to synchronize
SErrors in exception entries. But we haven't synchronized SErrors
while returning to guest and doing context switch.
So we still have two risks:
1. Slipping hypervisor SErrors to guest. For example, hypervisor
triggers a SError wh
If there is a pending SError while we're returning from trap. If the
SError handle option is "DIVERSE", we have to prevent slipping this
hypervisor SError to guest. So we have to use the dsb/isb to guarantee
that the pending hypervisor SError would be caught in hypervisor before
return to guest.
I
In previous patch, we have umasked the Abort/SError bit for Xen
in most of its running time. So in some use-cases, we have to
check whether the abort is enabled in current context. For example,
while we want to synchronize SErrors, we have to confirm the abort
is enabled. Otherwise synchronize SErr
On 4/3/2017 11:23 PM, Jan Beulich wrote:
On 02.04.17 at 14:24, wrote:
After an ioreq server has unmapped, the remaining p2m_ioreq_server
entries need to be reset back to p2m_ram_rw. This patch does this
synchronously by iterating the p2m table.
The synchronous resetting is necessary because
Xen will do exception syndrome check while some types of exception
take place in EL2. The syndrome check code read the ESR_EL2 register
directly, but in some situation this register maybe overridden by
nested exception.
For example, if we re-enable IRQ before reading ESR_EL2 which means
Xen may en
The guest generated external data/instruction aborts can be treated
as guest SErrors. We already have a handler to handle the SErrors,
so we can reuse this handler to handle guest external aborts.
Signed-off-by: Wei Chen
Reviewed-by: Stefano Stabellini
---
xen/arch/arm/traps.c | 14 ++--
If there is a pending SError while we are doing context switch, if the
SError handle option is "FORWARD", We have to guarantee this SError to
be caught by current vCPU, otherwise it will be caught by next vCPU and
be forwarded to this wrong vCPU.
So we have to synchronize SError before switch to n
>>> On 05.04.17 at 06:27, wrote:
> flight 107186 xen-4.6-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/107186/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-freebsd10-amd64 3 host-inst
>>> On 05.04.17 at 11:00, wrote:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -721,14 +721,20 @@ long arch_do_domctl(
>
> case XEN_DOMCTL_ioport_mapping:
> {
> -struct domain_iommu *hd;
> unsigned int fgp = domctl->u.ioport_mapping.first_gport;
>
Previously, p2m_finish_type_change() is triggered to iterate and
clean up the p2m table when an ioreq server unmaps from memory type
HVMMEM_ioreq_server. And the current iteration number is set to 256
And after these iterations, hypercall pre-emption is checked.
But it is likely that no p2m change
>>> On 05.04.17 at 08:53, wrote:
> Or with other patches received "Reviewed by", we can just drop the
> useless code of this patch.
> Any suggestions?
Without the libxc wrapper, the new DMOP is effectively dead code
too. All or nothing, imo.
Jan
___
Add support for multiple vIO APICs on the same domain, thus turning
d->arch.hvm_domain.vioapic into an array of vIO APIC control structures.
Note that this functionality is not exposed to unprivileged guests, and will
only be used by PVHv2 Dom0.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Hello,
Those are the remaining two patches in order to enable multiple vIO APIC
support for a PVH Dom0. The only patch missing an Ack is #1.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
The base address, id and number of pins of the vIO APICs exposed to PVHv2 Dom0
is the same as the values found on bare metal.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/dom0_build.c | 33 -
>>> On 04.04.17 at 21:10, wrote:
> This used to be done under TMEM_RESTORE_NEW which was an hypercall
> accessible by the guest. However there are couple of reasons
> not to do it:
> - No checking of domid on TMEM_RESTORE_NEW which meant that
>any guest could create TMEM pools for other guest
>>> On 04.04.17 at 21:10, wrote:
> which surprisingly (or maybe not) looks like
> XEN_SYSCTL_TMEM_OP_SET_POOLS.
>
> This hypercall came about, as explained in docs/misc/tmem-internals.html:
>
> When tmem was first proposed to the linux kernel mailing list
> (LKML), there was concern expressed ab
On 4/5/2017 5:21 PM, Jan Beulich wrote:
On 05.04.17 at 08:53, wrote:
Or with other patches received "Reviewed by", we can just drop the
useless code of this patch.
Any suggestions?
Without the libxc wrapper, the new DMOP is effectively dead code
too. All or nothing, imo.
Thanks Jan. But I
>>> On 05.04.17 at 11:22, wrote:
>
> On 4/5/2017 5:21 PM, Jan Beulich wrote:
> On 05.04.17 at 08:53, wrote:
>>> Or with other patches received "Reviewed by", we can just drop the
>>> useless code of this patch.
>>> Any suggestions?
>> Without the libxc wrapper, the new DMOP is effectively d
On Wed, Apr 05, 2017 at 03:17:17AM -0600, Jan Beulich wrote:
> >>> On 05.04.17 at 11:00, wrote:
> > --- a/xen/arch/x86/domctl.c
> > +++ b/xen/arch/x86/domctl.c
> > @@ -721,14 +721,20 @@ long arch_do_domctl(
> >
> > case XEN_DOMCTL_ioport_mapping:
> > {
> > -struct domain_iommu
>>> On 04.04.17 at 21:10, wrote:
> @@ -1530,7 +1529,8 @@ int do_tmem_new_pool(domid_t this_cli_id,
> pool->shared = 0;
> goto out;
> }
> -if ( client->shared_auth_required && !tmem_global.shared_auth )
> +/* By default only join domains that are a
>>> On 05.04.17 at 11:11, wrote:
>
> On 4/3/2017 11:23 PM, Jan Beulich wrote:
> On 02.04.17 at 14:24, wrote:
>>> After an ioreq server has unmapped, the remaining p2m_ioreq_server
>>> entries need to be reset back to p2m_ram_rw. This patch does this
>>> synchronously by iterating the p2m ta
On Wed, Apr 05, 2017 at 01:39:13AM +, Duncan X. Simpson wrote:
> Does anybody have advice as to what to do? Am I in the wrong place? Am I
> missing something obvious?
Could you send email in plain text only (no html)?
Have you build Xen from a package in AUR? In that case, reading/writing
com
On Tue, Apr 04, 2017 at 03:10:14PM -0400, Konrad Rzeszutek Wilk wrote:
> which surprisingly (or maybe not) looks like
> XEN_SYSCTL_TMEM_OP_SET_POOLS.
>
> This hypercall came about, as explained in docs/misc/tmem-internals.html:
>
> When tmem was first proposed to the linux kernel mailing list
> (
From: Oleksandr Grytsov
These patches add PV display device to libxl and xl.
Changes since initial:
* re-work libxl displ related functions to use libxl_device_type
Oleksandr Grytsov (2):
libxl: add PV display device driver interface
xl: add PV display device commands
tools/libxl/Makefil
From: Oleksandr Grytsov
Signed-off-by: Oleksandr Grytsov
---
tools/xl/Makefile | 1 +
tools/xl/xl.h | 3 +
tools/xl/xl_cmdtable.c | 16 +
tools/xl/xl_parse.c| 43 -
tools/xl/xl_parse.h| 2 +-
tools/xl/xl_vdispl.c | 162
flight 107214 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107214/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
coverity-amd646 coverity-upload fail REGR. vs. 106549
version t
From: Oleksandr Grytsov
Signed-off-by: Oleksandr Grytsov
---
tools/libxl/Makefile | 2 +-
tools/libxl/libxl.h | 21
tools/libxl/libxl_create.c | 3 +
tools/libxl/libxl_device.c | 206 ++
tools/libxl/l
On Wed, Apr 05, 2017 at 02:53:42PM +0800, Yu Zhang wrote:
>
>
> On 4/3/2017 5:28 PM, Wei Liu wrote:
> > On Mon, Apr 03, 2017 at 09:13:20AM +0100, Paul Durrant wrote:
> > > > -Original Message-
> > > > From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
> > > > Sent: 02 April 2017 13:24
> >
On Wed, Apr 05, 2017 at 11:08:46AM +0100, Wei Liu wrote:
> On Wed, Apr 05, 2017 at 02:53:42PM +0800, Yu Zhang wrote:
> >
> >
> > On 4/3/2017 5:28 PM, Wei Liu wrote:
> > > On Mon, Apr 03, 2017 at 09:13:20AM +0100, Paul Durrant wrote:
> > > > > -Original Message-
> > > > > From: Yu Zhang [m
On Thu, Mar 16, 2017 at 7:08 PM, Ronald Rojas wrote:
> Add calls for the following Domain related functionality
> - libxl_domain_pause
> - libxl_domain_shutdown
> - libxl_domain_reboot
> - libxl_list_domain
>
> Signed-off-by: Ronald Rojas
Reviewed-by: George Dunlap
___
On 4/5/2017 6:08 PM, Wei Liu wrote:
On Wed, Apr 05, 2017 at 02:53:42PM +0800, Yu Zhang wrote:
On 4/3/2017 5:28 PM, Wei Liu wrote:
On Mon, Apr 03, 2017 at 09:13:20AM +0100, Paul Durrant wrote:
-Original Message-
From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 02 April 2017 1
On 4/5/2017 6:20 PM, Wei Liu wrote:
On Wed, Apr 05, 2017 at 11:08:46AM +0100, Wei Liu wrote:
On Wed, Apr 05, 2017 at 02:53:42PM +0800, Yu Zhang wrote:
On 4/3/2017 5:28 PM, Wei Liu wrote:
On Mon, Apr 03, 2017 at 09:13:20AM +0100, Paul Durrant wrote:
-Original Message-
From: Yu Zhang
On Wed, Apr 05, 2017 at 06:21:16PM +0800, Yu Zhang wrote:
>
>
> On 4/5/2017 6:08 PM, Wei Liu wrote:
> > On Wed, Apr 05, 2017 at 02:53:42PM +0800, Yu Zhang wrote:
> > >
> > > On 4/3/2017 5:28 PM, Wei Liu wrote:
> > > > On Mon, Apr 03, 2017 at 09:13:20AM +0100, Paul Durrant wrote:
> > > > > >
flight 107192 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107192/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 83ae7589b08a0d11592527cf45fd1ad8d62118ab
baseline version:
ovmf 12b04866af2c348bf7e28
Thanks All
I will try the patch suggested by Julien and update you.
As of now I am running dom0(Linux 4.11-rc5) without early printk enabled in
xen which is working absolutely fine.
On Wed, Apr 5, 2017 at 2:32 AM, Julien Grall wrote:
> Hi,
>
> On 04/04/2017 21:45, Stefano Stabellini wrote:
>
On 4/5/2017 6:33 PM, Wei Liu wrote:
On Wed, Apr 05, 2017 at 06:21:16PM +0800, Yu Zhang wrote:
On 4/5/2017 6:08 PM, Wei Liu wrote:
On Wed, Apr 05, 2017 at 02:53:42PM +0800, Yu Zhang wrote:
On 4/3/2017 5:28 PM, Wei Liu wrote:
On Mon, Apr 03, 2017 at 09:13:20AM +0100, Paul Durrant wrote:
---
>>> On 05.04.17 at 12:26, wrote:
> On 4/5/2017 6:33 PM, Wei Liu wrote:
>> On Wed, Apr 05, 2017 at 06:21:16PM +0800, Yu Zhang wrote:
>>> So this series is OK for merge. And with compat wrapper dropped while
>>> committing,
>>> we do not need send the V11, right?
>>>
>> Assuming Jan is happy with th
On 4/5/2017 6:46 PM, Jan Beulich wrote:
On 05.04.17 at 12:26, wrote:
On 4/5/2017 6:33 PM, Wei Liu wrote:
On Wed, Apr 05, 2017 at 06:21:16PM +0800, Yu Zhang wrote:
So this series is OK for merge. And with compat wrapper dropped while
committing,
we do not need send the V11, right?
Assuming
On Thu, Mar 16, 2017 at 7:08 PM, Ronald Rojas wrote:
> Implement Golang enumeration of libxl_console_type
> as ConsoleType
>
> Implement the following libxl functions:
> - libxl_console_get_tty
> - libxl_primary_console_get_tty
>
> Signed-off-by: Ronald Rojas
> ---
> CC: xen-devel@lists.xen.org
>
Oleksandr Grytsov writes ("[PATCH v1 0/2] libxl: add PV display device driver
interface"):
> From: Oleksandr Grytsov
>
> These patches add PV display device to libxl and xl.
>
> Changes since initial:
> * re-work libxl displ related functions to use libxl_device_type
>
> Oleksandr Grytsov (2)
On Thu, Mar 16, 2017 at 7:08 PM, Ronald Rojas wrote:
> Created boilerplate struct and toC methods for the
> following structs:
> - KeyValueList
> - DomainBuildInfo
> - DeviceNic
> - DevicePci
> - DeviceRdm
> - DeviceDtdev
> - DeviceVfb
> - DeviceVkb
> - DeviceVtpm
> - DeviceChannel
> - DeviceUsbct
On Tue, 4 Apr 2017 12:42:53 -0700 (PDT)
Daniel Kiper wrote:
> > On 03/04/17 14:42, Daniel Kiper wrote:
> > > On Fri, Mar 31, 2017 at 12:14:38PM +0200, Juergen Gross wrote:
> > >> For kdump to work correctly it needs the physical address of
> > >> vmcoreinfo_note. When running as dom0 this means t
Hi Wei,
On 05/04/17 10:09, Wei Chen wrote:
In previous patch, we have umasked the Abort/SError bit for Xen
in most of its running time. So in some use-cases, we have to
check whether the abort is enabled in current context. For example,
while we want to synchronize SErrors, we have to confirm th
Hi Wei,
On 05/04/17 10:09, Wei Chen wrote:
In previous patches, we have provided the ability to synchronize
SErrors in exception entries. But we haven't synchronized SErrors
while returning to guest and doing context switch.
So we still have two risks:
1. Slipping hypervisor SErrors to guest. F
Hi Wei,
On 05/04/17 10:09, Wei Chen wrote:
If there is a pending SError while we're returning from trap. If the
SError handle option is "DIVERSE", we have to prevent slipping this
hypervisor SError to guest. So we have to use the dsb/isb to guarantee
that the pending hypervisor SError would be c
On Tue, Apr 04, 2017 at 07:31:59PM +0200, Seraphime Kirkovski wrote:
> GCC7 complains about a possible overflow/truncation in xenlockprof.
>
> xenlockprof.c: In function ‘main’:
> xenlockprof.c:100:53: error: ‘%s’ directive writing up to 39 bytes into a
> region of size be
Hi Andrew,
Thank you for resending the series.
On 30/03/17 17:32, Andrew Cooper wrote:
This series fixes https://xenproject.atlassian.net/browse/XEN-5
This is a blocker for Xen 4.9. Wei, Ian, would you have time to review
this series?
Cheers,
Andrew Cooper (4):
tools/libxc: Tolerate s
On Wed, Apr 05, 2017 at 12:23:58PM +0100, Julien Grall wrote:
> Hi Andrew,
>
> Thank you for resending the series.
>
> On 30/03/17 17:32, Andrew Cooper wrote:
> > This series fixes https://xenproject.atlassian.net/browse/XEN-5
>
> This is a blocker for Xen 4.9. Wei, Ian, would you have time to r
Hi Stefano and Julien,
This is Tejaswini. I had been working as a Senior Software developer in
Samsung and Cavium networks in linux kernel domain previously. I took a
break for one year for personal reasons. I am looking forward to restart my
career as a Linux engineer again with outreachy 2017 in
On Wed, Apr 05, 2017 at 05:04:00PM +0530, Tejaswini Poluri wrote:
> Hi Stefano and Julien,
>
> This is Tejaswini. I had been working as a Senior Software developer in
> Samsung and Cavium networks in linux kernel domain previously. I took a
> break for one year for personal reasons. I am looking f
1 - 100 of 308 matches
Mail list logo
