flight 104113 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104113/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7c14bc8769fbe1670e3b3d09d6cd531713eb74a4
baseline version:
ovmf 1b3d5b0699cf6222698ed
flight 104104 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104104/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 104099
test-armhf-armhf-libvirt-xs
On 17-01-10 08:15:15, Jan Beulich wrote:
> >>> On 14.12.16 at 05:07, wrote:
> > --- a/xen/arch/x86/psr.c
> > +++ b/xen/arch/x86/psr.c
> > @@ -186,6 +186,9 @@ struct feat_ops {
> > unsigned int (*exceeds_cos_max)(const uint64_t val[],
> > const struct feat_
On 17-01-10 08:08:19, Jan Beulich wrote:
> >>> On 14.12.16 at 05:07, wrote:
> > --- a/xen/arch/x86/psr.c
> > +++ b/xen/arch/x86/psr.c
> > @@ -169,6 +169,23 @@ struct feat_ops {
> > */
> > int (*compare_val)(const uint64_t val[], const struct feat_node *feat,
> >
On 17-01-10 07:53:07, Jan Beulich wrote:
> >>> On 14.12.16 at 05:07, wrote:
> > Continue with previous patch, we can try to find if there is a
>
> Please take into consideration that a series may be applied in small
> steps. References such as "previous patch" are thus possibly
> meaningless. Ple
On 17-01-10 07:34:00, Jan Beulich wrote:
> >>> On 14.12.16 at 05:07, wrote:
> > --- a/xen/arch/x86/psr.c
> > +++ b/xen/arch/x86/psr.c
> > @@ -121,6 +121,35 @@ struct feat_ops {
> > /* get_val is used to get feature COS register value. */
> > bool (*get_val)(const struct feat_node *feat,
On 17-01-10 07:17:38, Jan Beulich wrote:
> > To make the set value flow be general and can support multiple features
> > at same time, it includes below steps:
> > 1. Get COS ID of current domain using.
> > 2. Assemble a value array to store all features current value
> >in it and replace the c
> From: Venu Busireddy
> Sent: Wednesday, January 11, 2017 6:58 AM
>
> From: Elena Ufimtseva
>
> Add Xen command line option rmrr to specify RMRR regions that are not
> defined in ACPI thus causing IO Page Faults and prevent dom0 from booting
> if "iommu=dom0-strict" option is specified on the X
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, January 10, 2017 10:42 PM
>
> >>> On 10.01.17 at 15:26, wrote:
> > On 10/01/17 14:15, Andrew Cooper wrote:
> >> On 10/01/17 14:03, Suravee Suthikulpanit wrote:
> >>> The order of destroy function calls in hvm_vcpu_destroy() should be
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, January 09, 2017 7:03 PM
>
> Longterm, pv_cpuid() and hvm_cpuid() will be merged into a single
> guest_cpuid(), which is also capable of working outside of current context.
>
> To aid this transtion, introduce guest_cpuid()
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, January 05, 2017 6:55 PM
>
> Most invocations of the instruction emulator are for VM exits where the
> set of legitimate instructions (i.e. ones capable of causing the
> respective exit) is rather small. Restrict the permitted sets v
> From: Anshul Makkar [mailto:anshul.mak...@citrix.com]
> Sent: Friday, January 06, 2017 2:42 AM
>
> Current codebase doesn't implement and use vmptrst. Implementing it as it may
> be required in future.
>
> Signed-off-by: Anshul Makkar
Then let's do it when it's really required. :-)
Thanks
Ke
flight 104109 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104109/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 104105
build-amd64-xsm
On 10/01/17 23:56, Boris Ostrovsky wrote:
>
>
>
>> diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
>> index ebc768f..ebdfbee 100644
>> --- a/drivers/xen/xenbus/xenbus_xs.c
>> +++ b/drivers/xen/xenbus/xenbus_xs.c
>
>
>> -
>> -static struct xs_handle xs_state;
>> +/*
On 17-01-10 06:50:36, Jan Beulich wrote:
> >>> On 14.12.16 at 05:07, wrote:
> > This patch implements get value flow including L3 CAT callback
> > function.
> >
> > It also changes domctl interface to make it more general.
> >
> > With this patch, 'psr-cat-show' can work for L3 CAT.
>
> How abo
On 17-01-10 06:46:03, Jan Beulich wrote:
> >>> On 14.12.16 at 05:07, wrote:
> > --- a/xen/arch/x86/psr.c
> > +++ b/xen/arch/x86/psr.c
> > @@ -115,6 +115,9 @@ struct feat_ops {
> > struct psr_socket_info *info);
> > /* get_max_cos_max is used to get feature's cos_max.
Most dma_map_ops structures are never modified. Constify these
structures such that these can be write-protected. This patch
has been generated as follows:
git grep -l 'struct dma_map_ops' |
xargs -d\\n sed -i \
-e 's/struct dma_map_ops/const struct dma_map_ops/g' \
-e 's/const struct dm
From: Elena Ufimtseva
Add Xen command line option rmrr to specify RMRR regions that are not
defined in ACPI thus causing IO Page Faults and prevent dom0 from booting
if "iommu=dom0-strict" option is specified on the Xen command line.
These additional regions will be added to the list of RMRR regi
From: Elena Ufimtseva
On some platforms firmware fails to specify RMRR regions in ACPI tables and
thus those regions will not be mapped in dom0 or guests and may cause IO
Page Faults and prevent dom0 from booting if "iommu=dom0-strict" option is
specified on the Xen command line.
New Xen command
From: Elena Ufimtseva
For sbdf's parsing in RMRR command line, add parse_pci_seg with additional
parameter def_seg. parse_pci_seg will help to identify if segment was
found in string being parsed or default segment was used.
Make a wrapper parse_pci so the rest of the callers are not affected.
S
From: Elena Ufimtseva
In preparation for auxiliary RMRR data provided on Xen command line,
make RMRR adding a separate function.
Also free memery for rmrr device scope in error path.
Signed-off-by: Elena Ufimtseva
Signed-off-by: Venu Busireddy
Acked-by: Kevin Tian
---
xen/drivers/passthrough
flight 104107 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104107/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 104105
build-amd64-xsm
flight 104105 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104105/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1b3d5b0699cf6222698ed8373026813b61e87637
baseline version:
ovmf f4d575b51bbdb61e9f634
On 17-01-10 06:34:50, Jan Beulich wrote:
> >>> On 14.12.16 at 05:07, wrote:
> > @@ -358,11 +366,32 @@ void psr_free_rmid(struct domain *d)
> > d->arch.psr_rmid = 0;
> > }
> >
> > +static inline unsigned int get_max_cos_max(const struct psr_socket_info
> > *info)
> > +{
> > +const stru
On 17-01-10 04:45:05, Jan Beulich wrote:
> >>> On 14.12.16 at 05:07, wrote:
> > @@ -141,11 +144,79 @@ struct psr_assoc {
> >
> > struct psr_cmt *__read_mostly psr_cmt;
> >
> > +static struct psr_socket_info *__read_mostly socket_info;
> > +
> > static unsigned int opt_psr;
> > static unsign
On Tue, 10 Jan 2017, Dan Streetman wrote:
> On Tue, Jan 10, 2017 at 2:03 PM, Stefano Stabellini
> wrote:
> > On Tue, 10 Jan 2017, Dan Streetman wrote:
> >> On Tue, Jan 10, 2017 at 10:57 AM, Dan Streetman wrote:
> >> > On Mon, Jan 9, 2017 at 2:30 PM, Stefano Stabellini
> >> > wrote:
> >> >> On Mo
flight 104100 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104100/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 104098
test-armhf-armhf-libvirt
This run is configured for baseline tests only.
flight 68352 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68352/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-ins
On Tue, 10 Jan 2017, Oleksandr Andrushchenko wrote:
> On 01/07/2017 12:37 AM, Stefano Stabellini wrote:
> > On Fri, 6 Jan 2017, Oleksandr Andrushchenko wrote:
> > > From: Oleksandr Andrushchenko
> > >
> > > Signed-off-by: Oleksandr Andrushchenko
> > > ---
> > > xen/include/public/io/kbdif.h |
On Tue, 10 Jan 2017, Bhupinder Thakur wrote:
> Hi Stefano,
>
>
>
> On 7 January 2017 at 03:24, Stefano Stabellini wrote:
> > Hello Bhupinder,
> >
> > it is good to hear that you are making progress.
> >
> >
> > On Fri, 6 Jan 2017, Bhupinder Thakur wrote:
> >> Hi,
> >>
> >> I am trying to alloca
Upon request from Konrad, I am attaching the output of pahole on the C
structs defined by PVCalls. As you can see, alignments and sizes of all
fields are the same, except for the padding at the end of many request
structs (they need to be multiple of 8 bytes on 64bit). However, struct
xen_pvcalls_d
flight 104103 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104103/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f4d575b51bbdb61e9f634dcabb84149ca836cffa
baseline version:
ovmf 462a3eba8feaf3716d294
>> In the Xen code I can still see:
>>
>> case ECS_PIRQ: {
>> struct pirq *pirq = pirq_info(d1, chn1->u.pirq.irq);
>>
>> if ( !pirq )
>> break;
>> if ( !is_hvm_domain(d1) )
>> pirq_guest_unbind(d1, pirq);
>>
>> which means that pirq_guest_unbind
flight 104099 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104099/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 104094
test-armhf-armhf-libvirt-xs
Signed-off-by: Doug Goldstein
---
Daniel,
Feel free to fold this in where it needs to go or break this up into
a patch (or patches) part of your series. This is what it took for me to
get it to boot on one of my Intel NUCs and to get into the dom0 kernel
booting on my other machines. There's sti
> diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
> index ebc768f..ebdfbee 100644
> --- a/drivers/xen/xenbus/xenbus_xs.c
> +++ b/drivers/xen/xenbus/xenbus_xs.c
> -
> -static struct xs_handle xs_state;
> +/*
> + * Framework to protect suspend/resume handling against
flight 104102 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104102/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 462a3eba8feaf3716d294111725742ff5aa08488
baseline version:
ovmf 363dc42226a1d8ae02c73
On Tue, Jan 10, 2017 at 4:32 PM, wy11 wrote:
> Thank you very much for your explanation.
>
> To me, it seems to be an accounting problem because even if the time is
> accounted immediately a VCPU wake up or sleeps, the problem remains if the
> time is recorded in microseconds or million seconds be
Hi,
This is v7 of the patches to add CONFIG_DEBUG_VIRTUAL for arm64. This is
a simple reordering of patches from v6 per request of Will Deacon for ease
of merging support for arm which depends on this series.
Laura Abbott (11):
lib/Kconfig.debug: Add ARCH_HAS_DEBUG_VIRTUAL
mm/cma: Cleanup hig
On Tue, Jan 10, 2017 at 2:03 PM, Stefano Stabellini
wrote:
> On Tue, 10 Jan 2017, Dan Streetman wrote:
>> On Tue, Jan 10, 2017 at 10:57 AM, Dan Streetman wrote:
>> > On Mon, Jan 9, 2017 at 2:30 PM, Stefano Stabellini
>> > wrote:
>> >> On Mon, 9 Jan 2017, Konrad Rzeszutek Wilk wrote:
>> >>> On Mo
Thank you very much for your explanation.
To me, it seems to be an accounting problem because even if the time
is accounted immediately a VCPU wake up or sleeps, the problem remains
if the time is recorded in microseconds or million seconds because a
VCPU can run for less than a unit so tha
This run is configured for baseline tests only.
flight 68353 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68353/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 363dc42226a1d8ae02c73f9dd81da65af91b5fdd
baseline v
On 1/9/17 7:37 PM, Doug Goldstein wrote:
> On 12/5/16 4:25 PM, Daniel Kiper wrote:
>> diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
>> index 62c010e..dc857d8 100644
>> --- a/xen/arch/x86/efi/efi-boot.h
>> +++ b/xen/arch/x86/efi/efi-boot.h
>> @@ -146,6 +146,8 @@ static void
flight 104101 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104101/
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 1
These are the minutes I took during the call:
Xen PV Drivers Lifecycle document ready to be committed.
Common Pitfalls for new PV protocols:
- 32 vs 64 fields
- not Linux centric
- missing version fields and feature flags
Full list of outstanding PV protocols:
pvcalls, xen-9pfs, multitouch event
On Thu, Dec 08, 2016 at 03:33:39PM +, Anthony PERARD wrote:
> This "device" use XenIoMmioLib to reserve some space to be use by grant
> tables. It's use 0xfc00, which might not be a good choice...
Perhaps parse the E820 and find an E820_RSV region and use that?
And obviously don't use the
> diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c
> b/drivers/xen/xenbus/xenbus_dev_frontend.c
> index e4b9847..4d343ee 100644
> --- a/drivers/xen/xenbus/xenbus_dev_frontend.c
> +++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
>
LGTM.
-boris
__
On Tue, 10 Jan 2017, Dan Streetman wrote:
> On Tue, Jan 10, 2017 at 10:57 AM, Dan Streetman wrote:
> > On Mon, Jan 9, 2017 at 2:30 PM, Stefano Stabellini
> > wrote:
> >> On Mon, 9 Jan 2017, Konrad Rzeszutek Wilk wrote:
> >>> On Mon, Jan 09, 2017 at 10:42:41AM -0500, Dan Streetman wrote:
> >>> > O
On Tue, Jan 10, 2017 at 05:54:49PM +0100, Laszlo Ersek wrote:
> On 01/10/17 17:18, Anthony PERARD wrote:
> > On Thu, Jan 05, 2017 at 11:30:32AM +0100, Laszlo Ersek wrote:
> >> On 12/08/16 16:33, Anthony PERARD wrote:
> >>> diff --git a/OvmfPkg/XenPlatformPei/Platform.c
> >>> b/OvmfPkg/XenPlatformP
On Tue, Jan 10, 2017 at 06:44:25PM +0200, Andrii Anisov wrote:
> From: Andrii Anisov
>
> Some drivers need additional dma ops to be provided by xen swiotlb. Because
> common operations implementation came from x86 world and does not suite ARM
> needs.
>
> dma_mmap patch is a port of an antique a
On Tue, Jan 10, 2017 at 10:57 AM, Dan Streetman wrote:
> On Mon, Jan 9, 2017 at 2:30 PM, Stefano Stabellini
> wrote:
>> On Mon, 9 Jan 2017, Konrad Rzeszutek Wilk wrote:
>>> On Mon, Jan 09, 2017 at 10:42:41AM -0500, Dan Streetman wrote:
>>> > On Mon, Jan 9, 2017 at 9:59 AM, Boris Ostrovsky
>>> >
On 01/10/2017 06:40 PM, Tamas K Lengyel wrote:
> > (replying to all): I'm not in favor of this patch mainly because it is
> > not stealthy. A malicious kernel could easily track what events are
> > being sent on the ring. With DRAKVUF I could work around this using
> > altp2m pfn-re
On 01/10/17 17:18, Anthony PERARD wrote:
> On Thu, Jan 05, 2017 at 11:30:32AM +0100, Laszlo Ersek wrote:
>> On 12/08/16 16:33, Anthony PERARD wrote:
>>> - learn about memory size from the E820
>>> - ignore error if host bridge devid is 0x, PVH does not have PCI and
>>> reading from unexisting
From: Andrii Anisov
Some drivers need additional dma ops to be provided by xen swiotlb. Because
common operations implementation came from x86 world and does not suite ARM
needs.
dma_mmap patch is a port of an antique and lost patch discussed here:
http://marc.info/?l=xen-devel&m=139695901430667
From: Stefano Stabellini
This function creates userspace mapping for the DMA-coherent memory.
Signed-off-by: Stefano Stabellini
Signed-off-by: Oleksandr Dmytryshyn
Signed-off-by: Andrii Anisov
---
arch/arm/xen/mm.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/
From: Andrii Anisov
Signed-off-by: Andrii Anisov
---
arch/arm/xen/mm.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 050cf34..4061dd0 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -176,6 +176,16 @@ static int xen_swiotlb
On 10/01/17 17:36, Boris Ostrovsky wrote:
>
+static int process_msg(void)
+{
+ static struct xs_thread_state_read state;
+ struct xb_req_data *req;
+ int err;
+ unsigned int len;
+
+ if (!state.in_msg) {
+ state.in_msg = true;
+
On Tue, Jan 10, 2017 at 9:34 AM, Razvan Cojocaru
wrote:
> On 01/10/2017 06:29 PM, Tamas K Lengyel wrote:
> >
> >
> > On Tue, Jan 10, 2017 at 8:35 AM, Razvan Cojocaru
> > mailto:rcojoc...@bitdefender.com>> wrote:
> >
> > >>> What I meant was taking out this call:
> > >>>
> > >>> /*
>> /*
>> * xs_response_mutex is locked as long as we are processing one
>> * message. state.in_msg will be true as long as we are holding the
>> * lock in process_msg().
>
> Then in_msg is the same as mutex_is_locked(&xs_response_mutex). And if
> so, do we really need it?
Nevermind this. The
>>> +static int process_msg(void)
>>> +{
>>> + static struct xs_thread_state_read state;
>>> + struct xb_req_data *req;
>>> + int err;
>>> + unsigned int len;
>>> +
>>> + if (!state.in_msg) {
>>> + state.in_msg = true;
>>> + state.in_hdr = true;
>>> + state.
On 01/10/2017 06:29 PM, Tamas K Lengyel wrote:
>
>
> On Tue, Jan 10, 2017 at 8:35 AM, Razvan Cojocaru
> mailto:rcojoc...@bitdefender.com>> wrote:
>
> >>> What I meant was taking out this call:
> >>>
> >>> /* Remove the ring_pfn from the guest's physmap */
> >>> rc1 = xc_d
flight 104098 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104098/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 104086
test-armhf-armhf-libvirt
On Thu, Jan 05, 2017 at 11:30:32AM +0100, Laszlo Ersek wrote:
> On 12/08/16 16:33, Anthony PERARD wrote:
> > - learn about memory size from the E820
> > - ignore error if host bridge devid is 0x, PVH does not have PCI and
> > reading from unexisting device return -1.
> >
> > Contributed-unde
On Tue, Jan 10, 2017 at 8:35 AM, Razvan Cojocaru
wrote:
> >>> What I meant was taking out this call:
> >>>
> >>> /* Remove the ring_pfn from the guest's physmap */
> >>> rc1 = xc_domain_decrease_reservation_exact(xch, domain_id, 1, 0,
> >>> &ring_pfn);
> >>> if ( rc1 != 0 )
> >>>
On 1/10/17 21:26, Andrew Cooper wrote:
On 10/01/17 14:15, Andrew Cooper wrote:
On 10/01/17 14:03, Suravee Suthikulpanit wrote:
The order of destroy function calls in hvm_vcpu_destroy() should be
the reverse of init calls in hvm_vcpu_initialise().
Signed-off-by: Suravee Suthikulpanit
Reviewe
On Thu, Jan 05, 2017 at 10:59:24AM +0100, Laszlo Ersek wrote:
> On 12/08/16 16:33, Anthony PERARD wrote:
> > A copy of OvmfPkg/PlatformPei without some of QEMU specific
> > initialization, Xen does not support QemuFwCfg.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-of
flight 68350 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68350/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-amd64-weekly-netinst-pygrub 9 debian-di-install fail like
68308
test-armhf-
Today xenstored tries to open a tdb data base file on disk when it is
started. As this is problematic in most cases the scripts used to start
xenstored ensure xenstored won't find such a file in order to start
with an empty xenstore.
A tdb data base file can't be used to restore all Xenstore state
As xenstored now is always starting with an empty tdb data base there
is no need any longer to remove the file before starting xenstored.
A rerun of autogen.sh is required.
Signed-off-by: Juergen Gross
---
tools/hotplug/Linux/launch-xenstore.in | 1 -
1 file changed, 1 deletion(-)
diff --git a
Today xenstored tries to open an existing tdb file when started. As
this is known to be problematic the start script of xenstored is
deleting any old tdb file.
This can be made easier and less error prone by letting xenstored use
a new file.
Juergen Gross (2):
tools/xenstore: start with empty d
On Wed, Jan 04, 2017 at 08:49:15PM +0100, Laszlo Ersek wrote:
> > diff --git a/OvmfPkg/XenResetVector/Ia32/PageTables64.asm
> > b/OvmfPkg/XenResetVector/Ia32/PageTables64.asm
> > new file mode 100644
> > index 000..b5a4cf8
> > --- /dev/null
> > +++ b/OvmfPkg/XenResetVector/Ia32/PageTables64.as
On Mon, Jan 9, 2017 at 2:30 PM, Stefano Stabellini
wrote:
> On Mon, 9 Jan 2017, Konrad Rzeszutek Wilk wrote:
>> On Mon, Jan 09, 2017 at 10:42:41AM -0500, Dan Streetman wrote:
>> > On Mon, Jan 9, 2017 at 9:59 AM, Boris Ostrovsky
>> > wrote:
>> > > On 01/06/2017 08:06 PM, Konrad Rzeszutek Wilk wrot
On 12/22/2016 03:41 PM, Dr. Greg Wettstein wrote:
> Functionality of the xen-tpmfront driver was lost secondary to
> the introduction of xenbus multi-page support in the following
> commit:
>
> ccc9d90a9a8b5c4ad7e9708ec41f75ff9e98d61d
>
> xenbus_client: Extend interface to support multi-page ring
>
>>> What I meant was taking out this call:
>>>
>>> /* Remove the ring_pfn from the guest's physmap */
>>> rc1 = xc_domain_decrease_reservation_exact(xch, domain_id, 1, 0,
>>> &ring_pfn);
>>> if ( rc1 != 0 )
>>> PERROR("Failed to remove ring page from guest physmap");
>>>
>>> To
On 10/01/17 15:02, Razvan Cojocaru wrote:
> On 01/10/2017 04:13 PM, Andrew Cooper wrote:
>> On 10/01/17 09:06, Razvan Cojocaru wrote:
>>> On 01/09/2017 02:54 PM, Andrew Cooper wrote:
On 09/01/17 11:36, Razvan Cojocaru wrote:
> Hello,
>
> We've come across a weird phenomenon: an Ubu
On 1/10/17 2:38 AM, Jan Beulich wrote:
On 10.01.17 at 02:21, wrote:
>> On 12/5/16 4:25 PM, Daniel Kiper wrote:
>>> +/* Flags set in the 'flags' member of the multiboot header. */
>>> +#define MULTIBOOT2_TAG_TYPE_END0
>>> +#define MULTIBOOT2_TAG_TYPE_CMDLINE
>>> On 14.12.16 at 05:07, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -186,6 +186,9 @@ struct feat_ops {
> unsigned int (*exceeds_cos_max)(const uint64_t val[],
> const struct feat_node *feat,
> un
>>> On 14.12.16 at 05:07, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -169,6 +169,23 @@ struct feat_ops {
> */
> int (*compare_val)(const uint64_t val[], const struct feat_node *feat,
> unsigned int cos, bool *found);
> +/*
> + * ex
On 10/01/17 15:53, Boris Ostrovsky wrote:
> On 01/10/2017 08:32 AM, Juergen Gross wrote:
>> The default for the number of tx/rx queues of one interface is the
>> number of vcpus of the system today. As each queue pair reserves 512
>> grant pages this default consumes a ridiculous number of grants f
On 01/10/2017 04:13 PM, Andrew Cooper wrote:
> On 10/01/17 09:06, Razvan Cojocaru wrote:
>> On 01/09/2017 02:54 PM, Andrew Cooper wrote:
>>> On 09/01/17 11:36, Razvan Cojocaru wrote:
Hello,
We've come across a weird phenomenon: an Ubuntu 16.04.1 LTS HVM guest
running kernel 4.4.
On Wed, Jan 04, 2017 at 08:52:00PM +0100, Laszlo Ersek wrote:
> On 12/08/16 16:33, Anthony PERARD wrote:
> > Hi,
> >
> > I've started to create a Xen specifig plaform, in OvmfPkg/XenOvmf.dsc
> > with the goal to make it work on both Xen HVM and Xen PVHv2
>
> Does this mean we can ultimately move
On 01/10/2017 08:32 AM, Juergen Gross wrote:
> The default for the number of tx/rx queues of one interface is the
> number of vcpus of the system today. As each queue pair reserves 512
> grant pages this default consumes a ridiculous number of grants for
> large guests.
>
> Limit the queue number t
>>> On 14.12.16 at 05:07, wrote:
> Continue with previous patch, we can try to find if there is a
Please take into consideration that a series may be applied in small
steps. References such as "previous patch" are thus possibly
meaningless. Please instead refer to the patch by title. Also I think
>>> On 10.01.17 at 15:26, wrote:
> On 10/01/17 14:15, Andrew Cooper wrote:
>> On 10/01/17 14:03, Suravee Suthikulpanit wrote:
>>> The order of destroy function calls in hvm_vcpu_destroy() should be
>>> the reverse of init calls in hvm_vcpu_initialise().
>>>
>>> Signed-off-by: Suravee Suthikulpanit
>>> On 14.12.16 at 05:07, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -121,6 +121,35 @@ struct feat_ops {
> /* get_val is used to get feature COS register value. */
> bool (*get_val)(const struct feat_node *feat, unsigned int cos,
> enum cbm_type
On 10/01/17 14:15, Andrew Cooper wrote:
> On 10/01/17 14:03, Suravee Suthikulpanit wrote:
>> The order of destroy function calls in hvm_vcpu_destroy() should be
>> the reverse of init calls in hvm_vcpu_initialise().
>>
>> Signed-off-by: Suravee Suthikulpanit
>> Reviewed-by: Konrad Rzeszutek Wilk
On 10/01/17 14:03, Suravee Suthikulpanit wrote:
> The order of destroy function calls in hvm_vcpu_destroy() should be
> the reverse of init calls in hvm_vcpu_initialise().
>
> Signed-off-by: Suravee Suthikulpanit
> Reviewed-by: Konrad Rzeszutek Wilk
> Reviewed-by: Kevin Tian
> Cc: Jan Beulich
>
On 10/01/17 09:06, Razvan Cojocaru wrote:
> On 01/09/2017 02:54 PM, Andrew Cooper wrote:
>> On 09/01/17 11:36, Razvan Cojocaru wrote:
>>> Hello,
>>>
>>> We've come across a weird phenomenon: an Ubuntu 16.04.1 LTS HVM guest
>>> running kernel 4.4.0 installed via XenCenter in XenServer Dundee seems
>
> To make the set value flow be general and can support multiple features
> at same time, it includes below steps:
> 1. Get COS ID of current domain using.
> 2. Assemble a value array to store all features current value
>in it and replace the current value of the feature which is
>being set
The order of destroy function calls in hvm_vcpu_destroy() should be
the reverse of init calls in hvm_vcpu_initialise().
Signed-off-by: Suravee Suthikulpanit
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Kevin Tian
Cc: Jan Beulich
Cc: Boris Ostrovsky
---
Note: I separate this out from the pr
On Tue, Jan 10, 2017 at 02:32:50PM +0100, Juergen Gross wrote:
> The Xen network frontend/backend supports multiple tx/rx queues for one
> virtual interface. The number of queues supported by the backend is
> set to the number of cpus of the backend driver domain (usually dom0)
> and the number of
>>> On 14.12.16 at 05:07, wrote:
> This patch implements get value flow including L3 CAT callback
> function.
>
> It also changes domctl interface to make it more general.
>
> With this patch, 'psr-cat-show' can work for L3 CAT.
How about CDP? You don't implement anything for it here, and looki
>>> On 14.12.16 at 05:07, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -115,6 +115,9 @@ struct feat_ops {
> struct psr_socket_info *info);
> /* get_max_cos_max is used to get feature's cos_max. */
> unsigned int (*get_max_cos_max)(const stru
>>> On 14.12.16 at 05:07, wrote:
> @@ -358,11 +366,32 @@ void psr_free_rmid(struct domain *d)
> d->arch.psr_rmid = 0;
> }
>
> +static inline unsigned int get_max_cos_max(const struct psr_socket_info
> *info)
> +{
> +const struct feat_node *feat_tmp;
Same remark as on the earlier patc
The Xen network frontend/backend supports multiple tx/rx queues for one
virtual interface. The number of queues supported by the backend is
set to the number of cpus of the backend driver domain (usually dom0)
and the number of queues requested by the frontend is limited by the
number of vcpus of t
The default for the maximum number of tx/rx queues of one interface is
the number of cpus of the system today. As each queue pair reserves 512
grant pages this default consumes a ridiculous number of grants for
large guests.
Limit the queue number to 8 as default. This value can be modified
via a
The default for the number of tx/rx queues of one interface is the
number of vcpus of the system today. As each queue pair reserves 512
grant pages this default consumes a ridiculous number of grants for
large guests.
Limit the queue number to 8 as default. This value can be modified
via a module
This run is configured for baseline tests only.
flight 68351 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68351/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf fca422890777a02c027061fbceee454c9f117870
baseline v
>>> On 10.01.17 at 12:59, wrote:
> On 10/01/17 09:06, Jan Beulich wrote:
>> - don't accept LOCK for DR accesses (it's undefined in the manuals)
>> - only accept LOCK for CR accesses when the respective feature flag is
>> set (which would not normally be the case for Intel)
>> - add (rather than
flight 104097 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104097/
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 1
1 - 100 of 145 matches
Mail list logo
