This run is configured for baseline tests only.
flight 74726 xen-4.8-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74726/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 6 xen-install
flight 122884 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122884/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-shadow 12 guest-start fail REGR. vs. 122565
test-amd64-i386-xl-q
flight 122887 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122887/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-xsm 12 guest-start fail REGR. vs. 122801
test-amd64-amd64-libvir
On Tue, 24 Apr 2018, Julien Grall wrote:
> Hi,
>
> On 04/24/2018 03:18 PM, Andrii Anisov wrote:
> >
> > > Can you quantify what would be the cost of keeping that code around for
> > > IOMMU-less platform?
> > I'm not sure I understand your question. Do you mean a number of loc of the
> > passthro
flight 122885 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122885/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3f34e36d04a8de4992a696f738643b5a11261469
baseline version:
ovmf 0edb7ec5ced0a28b93bf8
Thank you, Lars.
On Fri, 18 May 2018, Lars Kurth wrote:
> Hi Stefano,
> what we also need for the project proposal are
>
> Sponsor: A sponsor can be a member of the project leadership team of a mature
> project, a member of the advisory board or the
> community manager. This ensures that a disti
On 2/9/2018 4:02 AM, Roger Pau Monné wrote:
> On Fri, Feb 09, 2018 at 10:51:01AM +, Julien Grall wrote:
>> Hi,
>>
>> On 02/09/2018 10:43 AM, Roger Pau Monné wrote:
+unsigned int type;
+};
+
+#define resource_size(res) ((res)->size)
+
+#define platform_device
On 2/13/2018 2:46 AM, Jan Beulich wrote:
On 09.02.18 at 11:47, wrote:
>> On Fri, Feb 09, 2018 at 10:45:25AM +, Julien Grall wrote:
>>> Hi,
>>>
>>> On 02/09/2018 10:29 AM, Roger Pau Monné wrote:
On Thu, Feb 08, 2018 at 08:10:49PM -0700, Sameer Goel wrote:
> diff --git a/xen/incl
On 3/10/2018 10:53 AM, Manish Jaggi wrote:
> Hi Sameer,
>
>
> On 02/09/2018 08:40 AM, Sameer Goel wrote:
>> This driver follows an approach similar to smmu driver. The intent here
>> is to reuse as much Linux code as possible.
>> - Glue code has been introduced to bridge the API calls.
>> - Calle
flight 122959 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122959/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> drivers/xen/grant-table.c | 49 +++
> include/xen/grant_table.h | 7 ++
> 2 files changed, 56 insertions(+)
>
> diff
On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
A commit message would be useful.
>
> Signed-off-by: Oleksandr Andrushchenko
>
> for (i = 0; i < nr_pages; i++) {
> - page = alloc_page(gfp);
> - if (page == NULL) {
> -
flight 122876 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122876/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail in 122659
REGR. vs. 122512
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 122944 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122944/
Failures :
Am Fri, 18 May 2018 18:01:42 +0100
schrieb Wei Liu :
> You don't need to test if the guest is HVM anymore. You only need to
> know if QEMU upstream is running.
libxl__domain_suspend_device_model handles qemu-xen and qemu-xen-trad.
That function can not be called unconditionally I think.
Perhaps I
On 05/18/2018 06:30 PM, Jan Beulich wrote:
On 11.05.18 at 13:11, wrote:
>> This patch adds access rights for the NPT pages. The access rights are
>> saved in bits 59:56 of pte that are manipulated through p2m_set_access()
>> and p2m_get_access() functions.
>
> You don't give any rationale fo
On 05/18/2018 07:00 PM, Tamas K Lengyel wrote:
> On Fri, May 18, 2018 at 9:32 AM, Jan Beulich wrote:
> On 11.05.18 at 13:11, wrote:
>>> Signed-off-by: Alexandru Isaila
>>
>> It would be helpful to know whether this patch depends on patch 1 in any way.
>> If it doesn't, with Tamas'es ack this
On Sat, May 19, 2018 at 01:55:53AM +1000, Steven Haigh wrote:
> Hi Lars,
>
> I think this is an excellent start.
>
> A specific concern that I have is when we get into a state between releases
> and XSAs where you cannot take the current release and then apply all
> released
> / embargo'ed XSA
Sorry - it appears I mess the CC list up here. CC'ing "The Rest" for
this combined fixup and cleanup patch for livepatch.markdown, for
inclusion into 4.11
~Andrew
On 08/05/18 10:55, Andrew Cooper wrote:
> From: Juergen Gross
>
> "make -C docs all" fails due to incorrect markdown syntax in
> liv
Cc Anthony.
On Thu, May 17, 2018 at 05:51:08PM +0200, Olaf Hering wrote:
> If a domU has a qemu-xen instance attached, it is required to call qemus
> "xen-save-devices-state" method. Without it, the receiving side of a PV
> migration may be unable to lock the image:
>
> xen be: qdisk-51712: xen b
On Fri, May 18, 2018 at 09:25:07AM +0200, Juergen Gross wrote:
> On 17/05/18 17:51, Olaf Hering wrote:
> > If a domU has a qemu-xen instance attached, it is required to call qemus
> > "xen-save-devices-state" method. Without it, the receiving side of a PV
> > migration may be unable to lock the ima
On Fri, May 18, 2018 at 05:17:54PM +0100, Anthony PERARD wrote:
> This tag includes two build fixes:
> - dump: Fix build with newer gcc
> Fix build with GCC-8
> - Fix libusb-1.0.22 deprecated libusb_set_debug with libusb_set_option
>
> Signed-off-by: Anthony PERARD
Applied.
flight 74725 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74725/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-armhf-jessie-netboot-pygrub 10 debian-di-install fail like
74707
baseline version:
fl
On Fri, May 18, 2018 at 09:54:37AM -0600, Jan Beulich wrote:
> >>> On 18.05.18 at 17:33, wrote:
> > Yes, I'm happy to help with that. As I've said, the basic test is very
> > simple (rtcwake command) and already very useful. The fact that it is(?)
> > broken on staging doesn't make it easier,
>
>
This tag includes two build fixes:
- dump: Fix build with newer gcc
Fix build with GCC-8
- Fix libusb-1.0.22 deprecated libusb_set_debug with libusb_set_option
Signed-off-by: Anthony PERARD
---
FYI, I've already ask with this mail:
> QEMU build fixes for Xen-4.11
> <20180510135438.gb2...@pera
On Fri, May 18, 2018 at 9:32 AM, Jan Beulich wrote:
On 11.05.18 at 13:11, wrote:
>> Signed-off-by: Alexandru Isaila
>
> It would be helpful to know whether this patch depends on patch 1 in any way.
> If it doesn't, with Tamas'es ack this could go in independent of the other
> one.
> For co
Hi Lars,
I think this is an excellent start.
A specific concern that I have is when we get into a state between releases
and XSAs where you cannot take the current release and then apply all released
/ embargo'ed XSA patches.
The current reasoning for this is that XSA patches are developed on
>>> On 18.05.18 at 17:33, wrote:
> Yes, I'm happy to help with that. As I've said, the basic test is very
> simple (rtcwake command) and already very useful. The fact that it is(?)
> broken on staging doesn't make it easier,
Details on the breakage would be appreciated (on a separate thread),
unl
>>> On 15.05.18 at 20:22, wrote:
> @@ -95,13 +97,17 @@ static void rombios_load_roms(void)
> etherboot_phys_addr = VGABIOS_PHYSICAL_ADDRESS + vgabios_sz;
> if ( etherboot_phys_addr < OPTIONROM_PHYSICAL_ADDRESS )
> etherboot_phys_addr = OPTIONROM_PHYSICAL_ADDRESS;
> -etherboo
On Thu, May 17, 2018 at 08:00:38PM +0200, Sander Eikelenboom wrote:
> Marek / Ian,
>
> Nice to see PCI-passthrough getting some attention again.
>
> On 17/05/18 17:12, Ian Jackson wrote:
> > Marek Marczykowski-Górecki writes ("Re: Test for osstest, features used in
> > Qubes OS"):
> >> On Thu, M
This run is configured for baseline tests only.
flight 74724 qemu-upstream-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74724/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 12 guest-start
>>> On 15.05.18 at 20:22, wrote:
> --- a/tools/firmware/etherboot/Makefile
> +++ b/tools/firmware/etherboot/Makefile
> @@ -18,11 +18,15 @@ D=ipxe
> T=ipxe.tar.gz
>
> ROMS = $(addprefix $D/src/bin/, $(addsuffix .rom, $(ETHERBOOT_NICS)))
> +ROM = $D/src/bin/ipxe.bin
>
> .NOTPARALLEL:
>
> .
On Thu, May 17, 2018 at 04:12:09PM +0100, Ian Jackson wrote:
> Marek Marczykowski-Górecki writes ("Re: Test for osstest, features used in
> Qubes OS"):
> > On Thu, May 17, 2018 at 01:26:30PM +0100, Ian Jackson wrote:
> > > Is it likely that this will depend on non-buggy host firmware ? If so
> >
>>> On 11.05.18 at 13:11, wrote:
> Signed-off-by: Alexandru Isaila
It would be helpful to know whether this patch depends on patch 1 in any way.
If it doesn't, with Tamas'es ack this could go in independent of the other one.
For conveying such information a cover letter is usually helpful.
Jan
On Fri, May 18, 2018 at 03:38:30PM +0100, Paul Durrant wrote:
> This patch removes the current hackery where IOREQ_TYPE_PCI_CONFIG
> requests are handled by faking PIO to 0xcf8 and 0xcfc and replaces it
> with direct calls to pci_host_config_read/write_common().
> Doing so necessitates mapping BDFs
>>> On 11.05.18 at 13:11, wrote:
> This patch adds access rights for the NPT pages. The access rights are
> saved in bits 59:56 of pte that are manipulated through p2m_set_access()
> and p2m_get_access() functions.
You don't give any rationale for the choice of bits. Right now p2m-pt.c still
assu
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 122925 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122925/
Failures :
>>> On 17.05.18 at 18:04, wrote:
On 07.05.18 at 10:24, wrote:
>> --- a/xen/arch/x86/cpu/mcheck/vmce.c
>> +++ b/xen/arch/x86/cpu/mcheck/vmce.c
>> @@ -357,20 +357,14 @@ void vmce_save_vcpu_ctxt_one(struct vcpu *v, struct
>> hvm_vmce_vcpu *ctxt)
>> ctxt->mcg_ext_ctl = v->arch.vmce.mcg_ext
Hi all,
Xen 4.11 rc5 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.11.0-rc5
For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.11.0-rc5/xen-4.11.0-rc5.tar.gz
And the signature is at:
https://downloads.xenproject.org/
>>> On 18.05.18 at 16:36, wrote:
> BTW, what do you think about the following:
>
> Another question is second_max_freq. As I understand, it is highest
> non-turbo frequency calculated by framework to limit target frequency
> when turbo mode "is disabled". And Xen assumes that second_max_freq is
>
From: Oleksandr Grytsov
Add config parser for virtual sound devices
Signed-off-by: Oleksandr Grytsov
Acked-by: Wei Liu
---
tools/xl/xl_parse.c | 246
tools/xl/xl_parse.h | 1 +
2 files changed, 247 insertions(+)
diff --git a/tools/xl/xl_parse.c
From: Oleksandr Grytsov
Add CLI commands to attach, detach and list virtual sound devices
Signed-off-by: Oleksandr Grytsov
Acked-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl.h | 3 +
tools/xl/xl_cmdtable.c | 15 +++
tools/xl/xl_vsnd.c | 203
From: Oleksandr Grytsov
This patch set adds PV sound device support to xl.cfg and xl.
See sndif.h for protocol implementation details.
Changes since initial:
* rebase to current staging
* use libxl__realloc instead of realloc
Oleksandr Grytsov (5):
libxl: add PV sound device
libxl: add v
From: Oleksandr Grytsov
Add getting vsnd list amd info API
Signed-off-by: Oleksandr Grytsov
---
tools/libxl/libxl.h | 10 +
tools/libxl/libxl_types.idl | 19 ++
tools/libxl/libxl_utils.h | 3 +
tools/libxl/libxl_vsnd.c| 374 +++-
4 files change
This patch removes the current hackery where IOREQ_TYPE_PCI_CONFIG
requests are handled by faking PIO to 0xcf8 and 0xcfc and replaces it
with direct calls to pci_host_config_read/write_common().
Doing so necessitates mapping BDFs to PCIDevices but maintaining a simple
QLIST in xen_device_realize/un
From: Oleksandr Grytsov
Update documentation with virtual sound device
Signed-off-by: Oleksandr Grytsov
Acked-by: Wei Liu
---
docs/man/xl.cfg.pod.5.in | 149 +++
docs/man/xl.pod.1.in | 30
2 files changed, 179 insertions(+)
diff --git a/docs/
From: Oleksandr Grytsov
Add PV sound device described in sndif.h
Signed-off-by: Oleksandr Grytsov
Acked-by: Wei Liu
---
tools/libxl/Makefile | 2 +-
tools/libxl/libxl.h | 14 ++
tools/libxl/libxl_create.c | 1 +
tools/libxl/libxl_internal.h
Hi, Jan.
Sorry for the late response.
On Mon, May 7, 2018 at 6:39 PM, Jan Beulich wrote:
On 09.11.17 at 18:09, wrote:
>> --- a/xen/drivers/cpufreq/Kconfig
>> +++ b/xen/drivers/cpufreq/Kconfig
>> @@ -1,3 +1,6 @@
>>
>> config HAS_CPUFREQ
>> bool
>> +
>> +config HAS_CPU_TURBO
>> +
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 18 May 2018 15:28
> To: qemu-de...@nongnu.org; xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Stefano Stabellini
> ; Anthony Perard ;
> Michael S. Tsirkin ; Marcel Apfelbaum
> ; Paolo Bonzini ; Richard
>
Sorry for top posting.
Due to a bug in the test used to verify this patch
I need to make two more changes, please see inline.
Please ignore this patch for now, I will send v5 soon.
Sorry for inconvenience,
Oleksandr
On 05/18/2018 12:59 PM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrus
This patch removes the current hackery where IOREQ_TYPE_PCI_CONFIG
requests are handled by faking PIO to 0xcf8 and 0xcfc and replaces it
with direct calls to pci_host_config_read/write_common().
Doing so necessitates mapping BDFs to PCIDevices but maintaining a simple
QLIST in xen_device_realize/un
Jan Beulich writes ("Re: [Xen-devel] [xen-unstable-smoke baseline test] 122919:
tolerable all pass"):
> On 18.05.18 at 15:48, wrote:
> > But in globbing, ! inside [ ] is a character class complement, not a
> > literal. The result is that mg-adjust-flight-makexrefs would
> > generally replace job
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 18 May 2018 15:16
> To: Paul Durrant
> Cc: Anthony Perard ; Roger Pau Monne
> ; Stefano Stabellini ; xen-
> devel ; qemu-de...@nongnu.org;
> ehabk...@redhat.com; mar...@redhat.com; m...@redhat.com; Paolo
> Bonzini
>>> On 18.05.18 at 16:13, wrote:
> Hi,
>
> On Fri, May 18, 2018 at 2:35 PM, Jan Beulich wrote:
> On 18.05.18 at 13:14, wrote:
>>> On Mon, May 7, 2018 at 6:36 PM, Jan Beulich wrote:
>>> On 09.11.17 at 18:09, wrote:
> +int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32
On 18/05/2018, 15:07, "Wei Liu" wrote:
On Fri, May 18, 2018 at 07:16:24AM -0600, Jan Beulich wrote:
> >>> On 18.05.18 at 12:13, wrote:
>
> 2.2.4.A
>
> We've discussed the option of different support life times before (and
iirc more
> than once). Personally I con
>>> On 18.05.18 at 15:48, wrote:
> osstest service owner writes ("[xen-unstable-smoke baseline test] 122919:
> tolerable all pass"):
>> "Old" tested version had not actually been tested; therefore in this
>> flight we test it, rather than a new candidate. The baseline, if
>> any, is the most rec
>>> On 18.05.18 at 15:51, wrote:
>> Sent: 18 May 2018 14:34
>> To: Paul Durrant
>> >>> On 18.05.18 at 15:00, wrote:
>> > +QLIST_FOREACH(xendev, &state->dev_list, entry) {
>> > +unsigned int i;
>> > +uint32_t tmp;
>> > +
>> > +if (xendev->sbdf != sbdf) {
>> > +
Hi,
On Fri, May 18, 2018 at 2:35 PM, Jan Beulich wrote:
On 18.05.18 at 13:14, wrote:
>> On Mon, May 7, 2018 at 6:36 PM, Jan Beulich wrote:
>> On 09.11.17 at 18:09, wrote:
+int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32) pdc)
+{
+u32 bits[3];
+
>>> On 18.05.18 at 15:23, wrote:
> On 18/05/18 13:37, Jan Beulich wrote:
> On 18.05.18 at 14:21, wrote:
>>> On 17/05/18 13:23, Jan Beulich wrote:
>>> On 16.05.18 at 19:27, wrote:
> c/s 62b187969 "x86: further CPUID handling adjustments" make some
> adjustments.
> However, it
On Fri, May 18, 2018 at 07:16:24AM -0600, Jan Beulich wrote:
> >>> On 18.05.18 at 12:13, wrote:
>
> 2.2.4.A
>
> We've discussed the option of different support life times before (and iirc
> more
> than once). Personally I continue to think that all releases should be equal.
>
> I also continue
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 18 May 2018 14:34
> To: Paul Durrant
> Cc: Anthony Perard ; Roger Pau Monne
> ; Stefano Stabellini ; xen-
> devel ; qemu-de...@nongnu.org;
> ehabk...@redhat.com; mar...@redhat.com; m...@redhat.com; Paolo
> Bonzini
osstest service owner writes ("[xen-unstable-smoke baseline test] 122919:
tolerable all pass"):
> "Old" tested version had not actually been tested; therefore in this
> flight we test it, rather than a new candidate. The baseline, if
> any, is the most recent actually tested revision.
This is a
>>> On 18.05.18 at 15:00, wrote:
> @@ -903,6 +926,80 @@ static void cpu_ioreq_move(ioreq_t *req)
> }
> }
>
> +static void rw_config_req_item(XenPciDevice *xendev, ioreq_t *req,
It looks to me as if both parameters could be constified.
> + uint32_t i, uint32_
> On May 18, 2018, at 06:13, Lars Kurth wrote:
>
> Dear Community Members,
>
> just under 3 months ago, we started a community consultation titled "Xen
> Security Process Consultation: is there a case to change anything?" (see
> https://lists.xenproject.org/archives/html/xen-announce/2018-02/m
On 18/05/18 13:37, Jan Beulich wrote:
On 18.05.18 at 14:21, wrote:
>> On 17/05/18 13:23, Jan Beulich wrote:
>> On 16.05.18 at 19:27, wrote:
c/s 62b187969 "x86: further CPUID handling adjustments" make some
adjustments.
However, it breaks levelling of guests, making it imp
>>> On 18.05.18 at 12:13, wrote:
2.2.4.A
We've discussed the option of different support life times before (and iirc more
than once). Personally I continue to think that all releases should be equal.
I also continue to think that it was a mistake to shorten the release cadence to
6 months, for
osstest service owner writes ("[xen-unstable test] 122715: trouble:
broken/fail/pass"):
> flight 122715 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/122715/
>
> Failures and problems with tests :-(
>
> Tests which did not succeed and are blocking,
> including tests
This patch removes the current hackery where IOREQ_TYPE_PCI_CONFIG
requests are handled by faking PIO to 0xcf8 and 0xcfc and replaces it
with direct calls to pci_host_config_read/write_common().
Doing so necessitates mapping BDFs to PCIDevices but maintaining a simple
QLIST in xen_device_realize/un
>>> On 18.05.18 at 14:21, wrote:
> On 17/05/18 13:23, Jan Beulich wrote:
> On 16.05.18 at 19:27, wrote:
>>> c/s 62b187969 "x86: further CPUID handling adjustments" make some
>>> adjustments.
>>> However, it breaks levelling of guests, making it impossible for the
>>> toolstack
>>> to hide S
On 17/05/18 13:23, Jan Beulich wrote:
On 16.05.18 at 19:27, wrote:
>> c/s 62b187969 "x86: further CPUID handling adjustments" make some
>> adjustments.
>> However, it breaks levelling of guests, making it impossible for the
>> toolstack
>> to hide STIBP or IBPB from guests on hardware with
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 122919 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122919/
Failures :
flight 122866 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122866/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail in 122771
pass in 122866
test-amd64-i38
All,
this should go out in a week or two. Please point out backport candidates you
find missing from its staging branch, but which you consider relevant.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailm
>>> On 18.05.18 at 13:14, wrote:
> On Mon, May 7, 2018 at 6:36 PM, Jan Beulich wrote:
> On 09.11.17 at 18:09, wrote:
>>> +int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32) pdc)
>>> +{
>>> +u32 bits[3];
>>> +int ret;
>>> +
>>> +if ( copy_from_guest(bits, pdc, 2) )
On 16/05/2018 22:27, Maran Wilson wrote:
> Friendly ping. I am hopeful one of the x86 and/or KVM maintainers has a
> few cycles to spare to look this over.
>
> And thanks to everyone who has helped thus far by providing valuable
> feedback and reviewing.
>
> https://lkml.org/lkml/2018/4/16/100
On 18/05/18 11:59, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> This is the sync up with the canonical definition of the keyboard
> protocol in Xen:
> 1. Add missing string constants for {feature|request}-raw-pointer
>to align with the rest of the interface file.
>
> 2.
Hi, Jan.
Sorry for the late response.
On Mon, May 7, 2018 at 6:36 PM, Jan Beulich wrote:
On 09.11.17 at 18:09, wrote:
>> From: Oleksandr Dmytryshyn
>>
>> Cpufreq driver should be more generalizable (not ACPI-specific).
>> Thus this file should be placed to more convenient location.
>>
>>
Hi Stefano,
what we also need for the project proposal are
Sponsor: A sponsor can be a member of the project leadership team of a mature
project, a member of the advisory board or the community manager. This ensures
that a distinguished community member supports the idea behind the project.
I w
On Thu, May 17, 2018 at 04:35:54PM +0100, Paul Durrant wrote:
> Not all Xen environments support the xengnttab_grant_copy() operation.
> E.g. where the OS is FreeBSD or Xen is older than 4.8.0.
>
> This patch introduces an emulation of that operation using
> xengnttab_map_domain_grant_refs() and m
On Thu, May 17, 2018 at 04:35:51PM +0100, Paul Durrant wrote:
> This patch adds grant table helper functions to the xen_backend code to
> localize error reporting and use of xen_domid.
>
> The patch also defers the call to xengnttab_open() until just before the
> initialise method in XenDevOps is
On Thu, May 17, 2018 at 04:35:50PM +0100, Paul Durrant wrote:
> Currently the xen_disk source has to carry #ifdef exclusions to compile
> against Xen older then 4.8. This is a bit messy so this patch lifts the
> definition of struct xengnttab_grant_copy_segment and adds it into the
> pre-4.8 compat
On Tue, May 15, 2018 at 05:40:53PM +0100, Paul Durrant wrote:
> Xen 4.11 has a new API to directly map guest resources. Among the resources
> that can be mapped using this API are ioreq pages.
>
> This patch modifies QEMU to attempt to use the new API should it exist,
> falling back to the previou
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 122914 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122914/
Failures :
On 17/05/18 16:31, Wei Liu wrote:
> On Thu, May 17, 2018 at 04:25:58PM +0200, Olaf Hering wrote:
>> Am Tue, 3 Apr 2018 13:14:11 +0200
>> schrieb Olaf Hering :
>>
>>> The exact value of cpu_khz can only be obtained via 'xl dmesg', and
>>> therefore can be lost after some time. 'xl info' truncates t
From: Oleksandr Andrushchenko
This is the sync up with the canonical definition of the keyboard
protocol in Xen:
1. Add missing string constants for {feature|request}-raw-pointer
to align with the rest of the interface file.
2. Add new XenStore feature fields, so it is possible to individuall
From: Oleksandr Andrushchenko
It is now only possible to control if multi-touch virtual device
is created or not (via the corresponding XenStore entries),
but keyboard and pointer devices are always created.
In some cases this is not desirable. For example, if virtual
keyboard device is exposed t
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 17 May 2018 17:31
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; qemu-de...@nongnu.org; Stefano
> Stabellini ; Michael S. Tsirkin ;
> Marcel Apfelbaum ; Paolo Bonzini
> ; Richard Henderson ; Ed
There is a couple of assembly functions, which are invoked only locally
in the file they are defined. In C, we mark them "static". In assembly,
annotate them using SYM_{FUNC,CODE}_START_LOCAL (and switch their
ENDPROC to SYM_{FUNC,CODE}_END too). Whether we use FUNC or CODE,
depends on whether ENDP
All these are functions which are invoked from elsewhere, but they are
not typical C functions. So we annotate them using the new
SYM_CODE_START. All these were not balanced with any END, so mark their
ends by SYM_CODE_END, appropriatelly.
Signed-off-by: Jiri Slaby
Reviewed-by: Boris Ostrovsky [
_key_expansion_128 is an alias to _key_expansion_256a, __memcpy to
memcpy, xen_syscall32_target to xen_sysenter_target, and so on. Annotate
them all using the new SYM_FUNC_START_ALIAS, SYM_FUNC_START_LOCAL_ALIAS,
and SYM_FUNC_END_ALIAS. This will make the tools generating the
debuginfo happy.
Sign
Here, we change all assembly code which is marked using END (and not
ENDPROC). We switch all these to appropriate new markings SYM_CODE_START
and SYM_CODE_END.
Signed-off-by: Jiri Slaby
Reviewed-by: Boris Ostrovsky [xen bits]
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@k
These are all functions which are invoked from elsewhere, so we annotate
them as global using the new SYM_FUNC_START. And their ENDPROC's by
SYM_FUNC_END.
And make sure ENTRY/ENDPROC is not defined on X86_64, given these were
the last users.
Signed-off-by: Jiri Slaby
Reviewed-by: Rafael J. Wysoc
Introduce new C macros for annotations of functions and data in
assembly. There is a long-standing mess in macros like ENTRY, END,
ENDPROC and similar. They are used in different manners and sometimes
incorrectly.
So introduce macros with clear use to annotate assembly as follows:
a) Support macr
All these are functions which are invoked from elsewhere, but they are
not typical C functions. So we annotate them using the new
SYM_CODE_START. All these were not balanced with any END, so mark their
ends by SYM_CODE_END appropriatelly too.
Signed-off-by: Jiri Slaby
Reviewed-by: Boris Ostrovsky
Use the new SYM_DATA_START_LOCAL, and SYM_DATA_END* macros to have:
8 OBJECT LOCAL DEFAULT6 gdt
000832 OBJECT LOCAL DEFAULT6 gdt_start
0028 0 OBJECT LOCAL DEFAULT6 gdt_end
0028 256 OBJECT LOCAL DEFAULT6 early_stack
0128 0 OBJECT LOCAL DEFAU
On Thu, May 17, 2018 at 04:29:57PM +0200, Olaf Hering wrote:
> Use error code from libxl namespace, a plain -1 is not valid in this context.
>
> Signed-off-by: Olaf Hering
While this function doesn't have libxl prefix, its return value does get
returned directly by various libxl functions. Inste
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 122913 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122913/
Failures :
Am Fri, 18 May 2018 09:25:07 +0200
schrieb Juergen Gross :
> debianhvm
The patch is for non-HVM, so perhaps these failures are something else.
To me it was not clear from the faillog what exactly failed.
Olaf
pgpY2ULaICJiC.pgp
Description: Digitale Signatur von OpenPGP
___
>>> On 17.05.18 at 19:47, wrote:
> On 05/17/2018 11:02 AM, Jan Beulich wrote:
> On 17.05.18 at 16:47, wrote:
>>> @@ -64,6 +67,9 @@ ENTRY(pvh_start_xen)
>>> mov %eax,%es
>>> mov %eax,%ss
>>>
>>> + mov $PVH_CANARY_SEL,%eax
>>> + mov %eax,%gs
>> I doubt this is needed for 64-bit (y
On Wed, May 16, 2018 at 07:46:48AM -0600, Jan Beulich wrote:
On 16.05.18 at 15:25, wrote:
>> On 16/05/18 14:10, Jan Beulich wrote:
+static int do_microcode_update(void *_info)
+{
+struct microcode_info *info = _info;
+unsigned int cpu = smp_processor_id();
+
1 - 100 of 102 matches
Mail list logo
