Mediated access to the RTC was provided for PVHv1 dom0 using the PV
code paths (guest_io_{write/read}), but those accesses where never
implemented for PVHv2 dom0. This patch provides such mediated accesses
to the RTC for PVH dom0, just like it's provided for a classic PV
dom0.
Pull out some of the
On Mon, 8 Jun 2020 at 17:00, Philippe Mathieu-Daudé wrote:
>
> Based on today's IRC chat, this is a trivial RFC series
> to anotate pre-qdev/QOM devices so developers using them
> without knowing they are not QOM'ified yet can realize
> it and convert them if they have time.
What mechanism did yo
On Mon, 8 Jun 2020, CodeWiz2280 wrote:
> It actually shows only 1 interrupt for any of the devices in that list
> (e.g. spi, ttyS0, ethernet) so you're probably right on the money with
> it being an interrupt acknowledge issue. Any help you can provide is
> greatly appreciated.
>
> On Mon, Jun
On 6/8/20 6:14 PM, Peter Maydell wrote:
> On Mon, 8 Jun 2020 at 17:00, Philippe Mathieu-Daudé wrote:
>>
>> Based on today's IRC chat, this is a trivial RFC series
>> to anotate pre-qdev/QOM devices so developers using them
>> without knowing they are not QOM'ified yet can realize
>> it and convert
flight 150918 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150918/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-rtds broken
Tests which are fail
> -Original Message-
> From: Xen-devel On Behalf Of Roger
> Pau Monne
> Sent: 08 June 2020 17:14
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Roger Pau Monne
> ; Wei Liu
> ; Jan Beulich ; p...@xen.org
> Subject: [PATCH for-4.14 v4] x86/rtc: provide mediated access to RTC fo
Hi all,
Xen 4.14 RC1 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.14.0-rc1
For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.14.0-rc1/xen-4.14.0-rc1.tar.gz
And the signature is at:
https://downloads.xenproject.org/
> -Original Message-
> From: Philippe Mathieu-Daudé
> Sent: 08 June 2020 17:00
> To: qemu-de...@nongnu.org
> Cc: qemu-...@nongnu.org; Markus Armbruster ; Max Filippov
> ;
> Marcel Apfelbaum ; Peter Maydell
> ; Michael Walle
> ; Edgar E. Iglesias ; Aurelien
> Jarno
> ; Gerd Hoffmann ; St
Don't use "set -x" for the figs rule. It doesn't take effect in the recursive
make environment.
Turn the HTML manpage comments into makefile comments, not shell comments.
This saves 3x shell invocations per manpage.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Be
On Sun, 7 Jun 2020, Julien Grall wrote:
> From: Julien Grall
>
> xen_pt_next_level() will retrieve the MFN from the entry right after the
> page-table has been unmapped.
>
> After calling xen_unmap_table(), there is no guarantee the mapping will
> still be valid. Depending on the implementation,
On 6/8/20 6:54 PM, Paul Durrant wrote:
>> -Original Message-
>> From: Philippe Mathieu-Daudé
>>
>> This code hasn't been QOM'ified yet. Warn the user.
>
> "Based on today's IRC chat, this is a trivial RFC series
> to anotate pre-qdev/QOM devices so developers using them
> without knowing
libxl: remove usage of strncpy from libxl__prepare_sockaddr_un
The runtime check for the length of path already prevents malfunction.
But gcc does not detect this runtime check and reports incorrect
usage of strncpy. Remove the usage of strncpy and work directly with
the calculated path length.
I
On 6/8/20 12:52 PM, Anchal Agarwal wrote:
>
> +void xen_hvm_map_shared_info(void)
> +{
> + xen_hvm_init_shared_info();
> + if (shared_info_pfn)
> + HYPERVISOR_shared_info = __va(PFN_PHYS(shared_info_pfn));
> +}
> +
AFAICT it is only called once s
flight 150926 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150926/
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
Am Mon, 8 Jun 2020 18:00:31 +0200
schrieb Philippe Mathieu-Daudé :
> This code hasn't been QOM'ified yet. Warn the user.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/m68k/mcf5206.c | 5 +
> hw/m68k/mcf5208.c | 3 +++
> 2 files changed, 8 insertions(+)
>
> diff --git a/hw/m68k/mcf5
On Mon, Jun 8, 2020 at 12:58 PM Razvan Cojocaru
wrote:
>
> On 6/8/20 6:55 PM, Jan Beulich wrote:
> > On 03.06.2020 17:07, Roger Pau Monné wrote:
> >> On Wed, Jun 03, 2020 at 06:52:37AM -0600, Tamas K Lengyel wrote:
> >>> For the last couple years we have received numerous reports from users of
> >
On Mon, Jun 8, 2020 at 10:41 AM Paul Durrant wrote:
>
> Hi all,
>
> Xen 4.14 RC1 is tagged. You can check that out from xen.git:
>
> git://xenbits.xen.org/xen.git 4.14.0-rc1
>
> For your convenience there is also a tarball at:
> https://downloads.xenproject.org/release/xen/4.14.0-rc1/xen-4.14.0-rc
Just like the alternatives infrastructure, the livepatch infrastructure
disables CR0.WP to perform patching, which is not permitted with CET active.
Modify arch_livepatch_{quiesce,revive}() to disable CET before disabling WP,
and reset the dirty bits on all virtual regions before re-enabling CET.
Struct 'kdd_hdr' already has a member named 'payload[]' to easily
refer to the data after the header. Remove the payload member from
'kdd_pkt' and always use 'kdd_hdr' to fix the following compile error:
kdd.c: In function 'kdd_tx':
kdd.c:746:30: error: array subscript 65534 is outside the bounds
On Mon, Jun 8, 2020 at 2:14 PM Razvan Cojocaru
wrote:
>
> On 6/8/20 10:54 PM, Tamas K Lengyel wrote:
> > On Mon, Jun 8, 2020 at 12:58 PM Razvan Cojocaru
> >> And last but not least, the proper sequence is: 1. unsubscribe from
> >> register write events, 2. process all events "still in the chamber"
On Fri, Jun 05, 2020 at 05:39:54PM -0400, Boris Ostrovsky wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you can confirm the sender and know the
> content is safe.
>
>
>
> On 6/4/20 7:03 PM, Anchal Agarwal wrote:
> > On
flight 150923 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150923/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 broken
test-amd64-amd64-xl-multivcpu
flight 150929 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150929/
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 Mon, Jun 8, 2020 at 3:16 PM Razvan Cojocaru
wrote:
>
> On 6/8/20 11:44 PM, Tamas K Lengyel wrote:
> > On Mon, Jun 8, 2020 at 2:14 PM Razvan Cojocaru
> > wrote:
> >>
> >> On 6/8/20 10:54 PM, Tamas K Lengyel wrote:
> >>> On Mon, Jun 8, 2020 at 12:58 PM Razvan Cojocaru
> And last but not lea
Hi Christoph,
Thanks you for the review.
On Mon, 8 Jun 2020, Christoph Hellwig wrote:
> Well, this isn't just RPi4, but basically any ARM or ARM64 system
> with non-coherent DMA (which is most of them).
Well... yes :-)
> > + struct page *pg;
>
> Please spell out page.
OK
> >
> > i
On Mon, 8 Jun 2020, Christoph Hellwig wrote:
> On Wed, Jun 03, 2020 at 03:22:39PM -0700, Stefano Stabellini wrote:
> > From: Stefano Stabellini
> >
> > The parameter is unused in this patch.
> > No functional changes.
>
> This looks weird. I'm pretty sure you are going to use it later, but
> wh
On Mon, 8 Jun 2020, Christoph Hellwig wrote:
> On Wed, Jun 03, 2020 at 03:22:44PM -0700, Stefano Stabellini wrote:
> > From: Stefano Stabellini
> >
> > With some devices physical addresses are different than dma addresses.
> > To be able to deal with these cases, we need to call phys_to_dma on
>
From: Borislav Petkov
commit a9a3ed1eff3601b63aea4fb462d8b3b92c7c1e7e upstream.
... or the odyssey of trying to disable the stack protector for the
function which generates the stack canary value.
The whole story started with Sergei reporting a boot crash with a kernel
built with gcc-10:
Ker
On Mon, Jun 8, 2020 at 5:14 PM Razvan Cojocaru
wrote:
>
> On 6/9/20 1:50 AM, Tamas K Lengyel wrote:
> > On Mon, Jun 8, 2020 at 3:16 PM Razvan Cojocaru
> > wrote:
> >> 1. A security application that is unable to _prevent_ things being done
> >> to a system is not doing a very good job, since in th
flight 150925 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150925/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl broken in 150920
test-amd64
On Mon, 8 Jun 2020, Christoph Hellwig wrote:
> On Wed, Jun 03, 2020 at 03:22:46PM -0700, Stefano Stabellini wrote:
> > From: Stefano Stabellini
> >
> > xen_dma_sync_for_cpu, xen_dma_sync_for_device, xen_arch_need_swiotlb are
> > getting called passing dma addresses. On some platforms dma addresse
On Mon, 8 Jun 2020, Stefano Stabellini wrote:
> On Mon, 8 Jun 2020, Christoph Hellwig wrote:
> > On Wed, Jun 03, 2020 at 03:22:44PM -0700, Stefano Stabellini wrote:
> > > From: Stefano Stabellini
> > >
> > > With some devices physical addresses are different than dma addresses.
> > > To be able t
On 6/9/20 1:50 AM, Tamas K Lengyel wrote:
> On Mon, Jun 8, 2020 at 3:16 PM Razvan Cojocaru
> wrote:
>> 1. A security application that is unable to _prevent_ things being done
>> to a system is not doing a very good job, since in that case you can
>> only collect stats and not veto anything. I woul
On 6/8/20 6:55 PM, Jan Beulich wrote:
> On 03.06.2020 17:07, Roger Pau Monné wrote:
>> On Wed, Jun 03, 2020 at 06:52:37AM -0600, Tamas K Lengyel wrote:
>>> For the last couple years we have received numerous reports from users of
>>> monitor vm_events of spurious guest crashes when using events. In
On 6/8/20 10:54 PM, Tamas K Lengyel wrote:
> On Mon, Jun 8, 2020 at 12:58 PM Razvan Cojocaru
>> And last but not least, the proper sequence is: 1. unsubscribe from
>> register write events, 2. process all events "still in the chamber"
>> (keep checking the ring buffer for a while), 3. detach from t
On 6/8/20 11:44 PM, Tamas K Lengyel wrote:
> On Mon, Jun 8, 2020 at 2:14 PM Razvan Cojocaru
> wrote:
>>
>> On 6/8/20 10:54 PM, Tamas K Lengyel wrote:
>>> On Mon, Jun 8, 2020 at 12:58 PM Razvan Cojocaru
And last but not least, the proper sequence is: 1. unsubscribe from
register write eve
On Mon, Jun 08, 2020 at 04:06:57PM -0700, Stefano Stabellini wrote:
> I understand what you are suggesting about having something like:
>
> xen_phys_to_dma(...)
> {
> phys_addr_t phys = xen_phys_to_bus(dev, paddr)
> return phys_to_dma(phys);
> }
>
> I thought about it
On Mon, Jun 08, 2020 at 05:38:28PM -0700, Stefano Stabellini wrote:
> Yeah, the pfn_valid check is a bit weird by definition because we are
> using it to understand whether the address belong to us or to another
> VM. To do the pfn_valid check we need to translate the dma address into
> something t
On Mon, Jun 08, 2020 at 10:38:02PM -0700, Christoph Hellwig wrote:
> On Mon, Jun 08, 2020 at 05:38:28PM -0700, Stefano Stabellini wrote:
> > Yeah, the pfn_valid check is a bit weird by definition because we are
> > using it to understand whether the address belong to us or to another
> > VM. To do
On 08.06.2020 20:58, Razvan Cojocaru wrote:
> On 6/8/20 6:55 PM, Jan Beulich wrote:
>> On 03.06.2020 17:07, Roger Pau Monné wrote:
>>> On Wed, Jun 03, 2020 at 06:52:37AM -0600, Tamas K Lengyel wrote:
For the last couple years we have received numerous reports from users of
monitor vm_even
flight 150928 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150928/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-buildfail REGR. vs. 150918
Tests which did no
101 - 141 of 141 matches
Mail list logo
